Leaderboard

Scapy is an incredible tool when it comes to playing with the network. As it is written on its official website, Scapy can replace a majority of network tools such as nmap, hping and tcpdump. One of the features offered by Scapy is to sniff the network packets passing through a computer’s NIC. Below is a small example: from scapy.all import * interface = "eth0" def print_packet(packet): ip_layer = packet.getlayer(IP) print("[!] New Packet: {src} -> {dst}".format(src=ip_layer.src, dst=ip_layer.dst)) print("[*] Start sniffing...") sniff(iface=interface, filter="ip", prn=print_packet) print("[*] Stop sniffing") This little sniffer displays the source and the destination of all packets having an IP layer: $ sudo python3 sniff_main_thread.py [*] Start sniffing... [!] New Packet: 10.137.2.30 -> 10.137.2.1 [!] New Packet: 10.137.2.30 -> 10.137.2.1 [!] New Packet: 10.137.2.1 -> 10.137.2.30 [!] New Packet: 10.137.2.1 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 ^C[*] Stop sniffing It will continue to sniff network packets until it receives a keyboard interruption (CTRL+C). Now, let’s look at a new example: from scapy.all import * from threading import Thread from time import sleep class Sniffer(Thread): def __init__(self, interface="eth0"): super().__init__() self.interface = interface def run(self): sniff(iface=self.interface, filter="ip", prn=self.print_packet) def print_packet(self, packet): ip_layer = packet.getlayer(IP) print("[!] New Packet: {src} -> {dst}".format(src=ip_layer.src, dst=ip_layer.dst)) sniffer = Sniffer() print("[*] Start sniffing...") sniffer.start() try: while True: sleep(100) except KeyboardInterrupt: print("[*] Stop sniffing") sniffer.join() This piece of code does exactly the same thing as the previous one except that this time the sniff function is executed inside a dedicated thread. Everything works well with this new version except when it comes to stopping the sniffer: $ sudo python3 sniff_thread_issue.py [*] Start sniffing... [!] New Packet: 10.137.2.30 -> 10.137.2.1 [!] New Packet: 10.137.2.30 -> 10.137.2.1 [!] New Packet: 10.137.2.1 -> 10.137.2.30 [!] New Packet: 10.137.2.1 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 10.137.2.30 -> 216.58.198.68 [!] New Packet: 216.58.198.68 -> 10.137.2.30 [!] New Packet: 10.137.2.30 -> 216.58.198.68 ^C[*] Stop sniffing ^CTraceback (most recent call last): File "sniff_thread_issue.py", line 25, in <module> sleep(100) KeyboardInterrupt During handling of the above exception, another exception occurred: Traceback (most recent call last): File "sniff_thread_issue.py", line 28, in <module> sniffer.join() File "/usr/lib/python3.5/threading.py", line 1054, in join self._wait_for_tstate_lock() File "/usr/lib/python3.5/threading.py", line 1070, in _wait_for_tstate_lock elif lock.acquire(block, timeout): KeyboardInterrupt ^CException ignored in: <module 'threading' from '/usr/lib/python3.5/threading.py'> Traceback (most recent call last): File "/usr/lib/python3.5/threading.py", line 1288, in _shutdown t.join() File "/usr/lib/python3.5/threading.py", line 1054, in join self._wait_for_tstate_lock() File "/usr/lib/python3.5/threading.py", line 1070, in _wait_for_tstate_lock elif lock.acquire(block, timeout): KeyboardInterrupt When CTRL+C is pressed, a SIGTERM signal is sent to the process executing the Python script, triggering its exit routine. However, as said in the official documentation about signals, only the main thread receives signals: As a result, when CTRL+C is pressed, only the main thread raises a KeyboardInterrupt exception. The sniffing thread will continue its infinite sniffing loop, blocking at the same time the call of sniffer.join(). So, how can the sniffing thread be stopped if not by signals? Let’s have a look at this next example: from scapy.all import * from threading import Thread, Event from time import sleep class Sniffer(Thread): def __init__(self, interface="eth0"): super().__init__() self.interface = interface self.stop_sniffer = Event() def run(self): sniff(iface=self.interface, filter="ip", prn=self.print_packet, stop_filter=self.should_stop_sniffer) def join(self, timeout=None): self.stop_sniffer.set() super().join(timeout) def should_stop_sniffer(self, packet): return self.stop_sniffer.isSet() def print_packet(self, packet): ip_layer = packet.getlayer(IP) print("[!] New Packet: {src} -> {dst}".format(src=ip_layer.src, dst=ip_layer.dst)) sniffer = Sniffer() print("[*] Start sniffing...") sniffer.start() try: while True: sleep(100) except KeyboardInterrupt: print("[*] Stop sniffing") sniffer.join() As you may have noticed, we are now using the stop_filter parameter in the sniff function call. This parameter expects to receive a function which will be called after each new packet to evaluate if the sniffer should continue its job or not. An Event object named stop_sniffer is used for that purpose. It is set to true when the join method is called to stop the thread. Is this the end of the story? Not really… $ sudo python3 sniff_thread_issue_2.py [*] Start sniffing... ^C[*] Stop sniffing [!] New Packet: 10.137.2.30 -> 10.137.2.1 One side effect remains. Because the should_stop_sniffer method is called only once after each new packet, if it returns false, the sniffer will continue its job, going back to its infinite sniffing loop. This is why the sniffer stopped one packet ahead of the keyboard interruption. A solution would be to force the sniffing thread to stop. As explained in the official documentation about threading, it is possible to flag a thread as a daemon thread for that purpose: However, even if this solution would work, the thread won’t release the resources it might hold: The sniff function uses a socket which is released just before exiting, after the sniffing loop: try: while sniff_sockets: // Sniffing loop except KeyboardInterrupt: pass if opened_socket is None: for s in sniff_sockets: s.close() return plist.PacketList(lst,"Sniffed") Therefore, the solution I suggest is to open the socket outside the sniff function and to give it to this last one as parameter. Consequently, it would be possible to force-stop the sniffing thread while closing its socket properly: from scapy.all import * from threading import Thread, Event from time import sleep class Sniffer(Thread): def __init__(self, interface="eth0"): super().__init__() self.daemon = True self.socket = None self.interface = interface self.stop_sniffer = Event() def run(self): self.socket = conf.L2listen( type=ETH_P_ALL, iface=self.interface, filter="ip" ) sniff( opened_socket=self.socket, prn=self.print_packet, stop_filter=self.should_stop_sniffer ) def join(self, timeout=None): self.stop_sniffer.set() super().join(timeout) def should_stop_sniffer(self, packet): return self.stop_sniffer.isSet() def print_packet(self, packet): ip_layer = packet.getlayer(IP) print("[!] New Packet: {src} -> {dst}".format(src=ip_layer.src, dst=ip_layer.dst)) sniffer = Sniffer() print("[*] Start sniffing...") sniffer.start() try: while True: sleep(100) except KeyboardInterrupt: print("[*] Stop sniffing") sniffer.join(2.0) if sniffer.isAlive(): sniffer.socket.close() Et voilà! The sniffing thread now waits for 2 seconds after having received a keyboard interrupt, letting the time to the sniff function to terminate its job by itself, after which the sniffing thread will be force-stopped and its socket properly closed from the main thread. Source

Daca ajungi sa fii monetizat. Te plateste pt orice vizualizare ee reclama, nu conteaza cu cate luni in urma ai postat. Te plateste in functie de tara in care e vazuta reclama si tipul de reclama. Daca ai vizualizari USA preturile reclamelor sunt la rata USA. Nu conteaza continutul, de unde uploadezi etc. Unele tari ca franta, USA, Canada mai au avantaje cu "Sponsor Youtube", "Youtube Red" etc. Ca sa prinzi avantajele astea trebuie sa ai cont din tara respectiva si sa ai adresa postala/Carte de identitate de acolo. In orice tara se plateste prost. Multe vizualizari sunt cu adblock. Nu e usor sa fii monetizat, se intampla sa fii demonetizat daca postezi chestii ciudate, inclusiv banat daca nu respecti copyright. Iti trebuie sute de mii de vizualizari ca sa faci ceva bani.

E in functie de unde sunt afisate reclamele, nu conteaza unde este facut contul. CPM-ul depinde de publicul tinta care te vizioneaza.

While hackers already hunt for ways to steal money, some vulnerabilities further allow them for successful crypto hacks. Recently, experts from Chinese cybersecurity firm Qihoo’s 360 Netlab revealed a massive theft of $20 Million worth of Ethereum by hackers. Apparently, a Geth vulnerability allowed the hackers to make this theft possible from unsafe clients. Geth Vulnerability Made Ethereum Clients Unsafe A few months ago, 360 Netlab, a Chinese cybersecurity company, told crypto traders about how a Geth vulnerability could let hackers steal money. The issue affected port 8545 which allowed for a hacker to access Geth clients. Now, the researchers confirm that their speculation was right. In fact, not only they confirmed the vulnerability, but they also proved its functionality. According to their recent tweet, hackers have already stolen Ethereum from unsecured Geth clients worth $20 million. Geth is a famous client meant for running full Ethereum nodes that enables the users to manage them remotely through JSON-RPC interface. According to 360 Netlab, Geth by default ‘listens on port 8545’. The hackers, thus, actively look for vulnerabilities in this 8545 port to steal cryptocurrency. Usually, this port is available only locally and is not open to the external internet. Therefore, anyone having this port open publicly is a target for being hacked. Securing Your Wallets From Hackers A quick scan of the hacker’s address will let you know the exact amount. When LHN looked over the hackers account (0x957cD4Ff9b3894FC78b5134A8DC72b032fFbC464), the amount stolen seems to have increased further, crossing the amount of Ether reported earlier (38,642.23856 ETH). At the time of writing this article, the hacker’s wallet shows 38,642.68624 ETH as available. This proves that the hackers are still actively stealing money from unsecured wallets. According to 360 Netlab, you can view these addresses in the payload. “If you’ve honeypot running on port 8545, you should be able to see the requests in the payload which has the wallet addresses. There are quite a few IPs scanning heavily on this port now.” The researchers have also disclosed some wallet addresses that supposedly belong to hackers. Users should only connect with Geth clients from local computers. They can also enable user-authorization for remote RPC connections. Via latesthackingnews.com

Domnul @Usr6 mi-a trasat sarcina sa scriu write-up-ul (modul in care am rezolvat problema). Asa ca hai sa incepem. Nivelul 0 Challenge-ul incepe cu o poza, jpeg: TheBodyguard.jpeg si cu un fisier script python (denumit de mine password_encoder.py) Mai intai analizam poza (eu am preferat binwalk) si observam ca are concatenat la sfarsit un fisier zip: Avand in vedere faptul ca avem si un script python ce pare sa codeze parola, putem presupune ca arhiva atasata este parolata. In mod normal binwalk incearca sa dezarhiveze/decomprime arhivele pe care le intalneste, dar in acest caz ne-ar incurca mai mult, asa ca vom rula binwalk --extract --carve TheBodyguard.jpg. Acum avem un dosar _TheBodyguard.jpg.extracted unde vom gasi un fisier 14757.zip (deoarece a fost gasit la offset-ul 0x14757). Daca vom incerca sa dezarhivam acest fisier zip, ne vom lovi de necesitatea unei parole. Nivelul 1 Acum vom analiza script-ul python, pentru a determina parola. La prima vedere pare cam complicat, asa ca vom incerca sa urmarim executia de la capat la inceput. Stim ca avem output-ul "You need this:201,203,165,195,165,191,205,187,181,191,173,187,173,187,193,199,", asa ca vom cauta codul ce genereaza aceasta linie; si il gasim pe ultimul rand al script-ului. Observam ca apeleaza functia enc2 cu avand ca prim parametru parola noastra, iar ca al 2-lea parametru rezultatul functiei enc2. Daca analizam corpul functiei enc2 observam ca aceasta functie concateneaza suma valorilor numerice a caracterelor de cele 2 string-uri primite ca parametrii (t1 si t2). Aici observam ca lungimea lui t1 trebuie sa fie mai mica sau egala cu lugimea lui t2. Altfel vom avea erori. Dar t2 este de fapt parola noastra codata cu enc1. Iar in enc1 observam ca facem ROT+3 (adica "a" devine "d", "b" devine "e", etc), doar daca este o litera mica; altfel sarim peste. Din datele de mai sus deducem ca parola este formata doar din litere mici, mai exact din 16 litere mici. Inarmati cu aceste date vom incerca o implementare in python (ipython mai exact): Mai intai extragem sumele de caractere ca un array de intregi (In [3] in ipython). Apoi generam toate sumele posibile ce pot rezulta din utilizarea functiei enc2 (ne intereseaza doar sumele ca valori numerice; argumentul functiei str din bucla for) si le stocam in dictionarul nostru (declarat in In [4]), impreuna cu literele aferente care au generat suma (o suma poate fi generata cu mai multe litere, cum poate fi observat in Out [8]). La sfarsit generam toate combinatiile posibile si obtinem 8 posibile parole, dar prima pare cea mai promitatoare. O utilizam si ne alegem cu un fisier prng, fara nici o extensie. Nivelul 2 Deoarece fisierul prng nu are nici o extensie, vom apela la utilitarul file pentru a identifica subiectul. Aflam ca este tot o arhiva de tip zip, asa ca il redenumim in prng.zip. In momentul in care incercam sa il dezarhivam, ne lovim de o parola si un indiciu sub forma altui script python: De aceasta data, scriptul se vrea un pseudo random number generator, ce isi genereaza seed-ul dintr-o structura python folosita pentru stocarea datei. Aceasta tip de date (named tuple) este strurata in felul urmator: pozitia 0: anul (accesabil si prin membrul tm_year) pozitia 1: luna (accesabil si prin membrul tm_mon) pozitia 2: ziua lunii (accesabil si prin membrul tm_day) pozitia 3: ora zile in format 24h (accesabil si prin membrul tm_hour) pozitia 4: minutele (accesabil si prin membrul tm_min) pozitia 5: secundele (accesabil si prin membrul tm_sec) pozitia 6: ziua saptamanii (accesabil si prin membrul tm_wday) pozitia 7: ziua din an (accesabil si prin membrul tm_yday) pozitia 8: decalajul aferent orei de vara (accesabil si prin membrul tm_isdst) Noi nu suntem interesati decat de pozitiile 0, 2, 3, 4, 5. Pe de alta parte, analizand functia password_gen, observam ca pozitiile pare din string-ul seed sunt pastrate (deci sunt cifre mereu) iar pozitiile impare sunt inlocuite cu litere din alfabet, aflate la pozitia respectiva (din punct de vedere lexicografic). De aici putem deduce ca parola noastra nu poate fi mai lunga de 27 de caractere (deoarece ultimul caracter poate fi o cifra). In continuare vom face niste supozitii legate de data folosita ca seed, si anume vom presupune ca este data crearii/modificarii fisierului din arhiva (sau foarte aproape). In fond si la urma urmei putem oricand sa facem brute-force pe parola cu un program asemanator John The Ripper, folosind ca masca pentru parola ?db?dc?df?dh?dj?dl?dn?dp?dr?dt?dv?dx?dz?d. Daca listam continutul arhivei (folosind unzip -l prng.zip) nu vom avea decat data, ora si minutele, nu si secundele. Ca atare vom face o listare mai completa a arhivei in speranta ca vom obtine o data completa, folosind comanda unzip -Z -l -v prng.zip: Inarmati cu aceste date, vom incerca un mic script python: Mai intai declaram o functie care va calcula acea variabila seed ce se afla la inceputul script-ului original, folosind un struct_time ca argument. Apoi copiem functia password_gen. In ultimul rand vom crea o variabila timestruct (de tip struct_time) ce va contine data fisierului, folosind functia strptime (adica vom aplica o functie de parsing pe string-ul cu data). Avand aceste detalii, apelam functia password_gen pentru a obtine seed-ul ce serveste ca parola. Din nefericire aceasta parola nu a functionat, dar putem presupune ca suntem pe aproape. Daca presupunem ca nu avem secundele corecte putem genera o lista de parole (unice) pentru fiecare secunda posibila: Incercand aceste variante, descoperim ca "2b1d3f2h" este parola potrivita, si obtimem un fisier ' .64'. Nivelul 3 Fisierul obtinut la pasul anterior nu pare prea darnic in a ne prezenta vre-un indiciu; utilitarul file nu ne poate spune decat ca avem de aface cu un fisier text ASCII cu terminatii de linie CRLF (adica Windows/DOS). La o analiza mai atenta, observam ca avem de aface cu un fisier cu mai multe linii, fiecare linie avand un numar diferit de spatii alble (caracterul ASCII 0x20). Din start am presupus ca avem de aface cu ceva base64 si ca numarul de spatii albe este relevant. Aici m-am blocat din cauza propriei prostii si neatentii, si am pierdut cam o saptamana (adica aproximativ 10 ore distribuite de-a lungul a 7 zile). Cand am inceput challange-ul, cel de-al 2-lea indiciu era deja postat. Asa ca m-am folosit de el. Indiciul decodat ne spune Inarmat cu aceste informatii, e timpul pentru niste experimente. Mai intai citim fisierul, si il spargem in linii de spatii si observam ca avem 12 linii. Acum sa vedem cate spatii albe avem pe fiecare linie (in poza In [5] si Out [6]). Deci nici un numar nu trece de valoarea 64, iar cum fisierul are extensia 64, indiciul a fost codat in base64 si ni s-a si precizat ca indiciul "este 2 indicii", probabil aceste numere sunt indecsii alfabetului base64. Construim o variabila (in poza este denumita alphabet la linia In [7]) in care vom stoca alfabetul base64 (vom folosi alfabetul clasic, A-Za-z0-9+/). Acum folosim sirul de numere de mai sus ca indecsi si... ne-am blocat. Obtinem S3+waDCjc4li, care decodat ne da urmatorul sir de bytes: Problema este extrem de simpla: noi avem niste lungimi de siruri de spatii albe, deci, pornesc de la 1, dar array-urile in python pornesc de la 0. Si asa am pierdul degeaba o saptamana, incercand tot felul de alfabete ezoterice, si cautand alte explicatii. Pana la urma l-am contactat pe @Usr6 care m-a trezit la realitate De indata ce corectam problema index-ului obtinem solutia.

salut. am descoperit cum se calculeaza Hash-ul: - de tip CRC16_AUG_CCITT. (Polynomial 0x1021, Init value: 0x1D0F, Final Xor value: 0x00) - se calculeaza pe toata zona - ultimii doi bytes (16+16+14) - CRC-ul calculat trebuie intors (LSB MSB) Craciun fericit. //swimm3r

le mai ai?