zbeng Posted May 28, 2006 Report Posted May 28, 2006 1. Disclaimer (inspirat cu nerusinare din The Phrack Magazine) Autorul (denumit in continuare ``EU'') a scris articolul acesta in scopuri pur informative. Toate informatiile prezentate in acest articol sunt (din cate stiu eu) adevarate si exacte. Pe cat posibil am incercat sa verific tot ceea ce am scris. Cu toate acestea, nu sunt omniscient (nu sunt nici macar platit). E foarte posibil ca ceva sa fie incorect intr-un fel sau altul, caz in care EU va roaga sa-i trimiteti un email ca sa-si poata corecta greseala. De asemenea, EU nu am nici o responsabilitate pentru lucrurile stupide (sau ilegale) pe care unii oameni le-ar putea face cu informatiile prezentate. 2. CopyrightArticolul asta e copyright © 1999 Petru Paler (ppetru@coltronix.com). Poate fi redistribuit prin orice mijloace, cu conditia sa ramana nemodificat. Parti din el pot fi folosite in alte publicatii, cu conditia mentionarii sursei originale. De asemenea m-as bucura (deci nu e obligatoriu) sa aud critici/opinii/sugestii pe tema articolului. 3. AvertismentAm incercat sa prezint pe scurt unele dintre notiunile folosite. Cu toate astea, s-ar putea ca articolul sa fie un pic cam prea dificil. Asta e. Keep tryin' Era sa uit. Sunt sysadmin/programator, in nici un caz scriitor. Asa ca scuze pentru stilul mai putin literar. 4. Ce e de fapt portscanning-ul ?Portscanning-ul este o metoda prin care se poate afla (in scopuri informative, desigur) ce servicii ruleaza pe un calculator conectat la Internet. 5. Cum functioneaza ?[ explicatie despre TCP UDP porturi servicii IP id][ o sa apara in numarul viitor mai pe larg ]6. Care e problema ?Metodele "clasice" de scanning (care vor fi probabil prezentate in numerele viitoare ale serialului) pot fi detectate destul de simplu (un program care face asta foarte bine este Abacus PortSentry[1]) dupa adresa sursa din conexiunile TCP. 7. Ce este un "spoof-scan" ?"to spoof" inseamna in engleza a falsifica, a schimba. La prima vedere am putea crede ca e posibil sa schimbam adresa sursa din pachetele TCP si ca va merge. Din pacate (sau din fericire) lucrurile nu stau tocmai asa. Ca sa vedem daca un anumit port este deschis trebuie sa primim un raspuns de la sistemul victima. Cum tocmai am schimbat adresa sursa, raspunsul nu va mai ajunge la noi niciodata. Situatia parea fara iesire, pana cand, pe 15 decembrie 1998, un tip numit antirez[5] a anuntat[2] pe lista Bugtraq ca a inventat o metoda de spoof-scan care functioneaza.8. Cum functioneaza ?Metoda se bazeaza pe 3 "probleme" de implementare ale protocolului TCP/IP, probleme care apar in majoritatea sistemelor de operare existente: a) la primirea unui pachet SYN se raspunde cu SYN|ACK daca portul e deschis sau cu RST|ACK daca portul e inchis algoritmul de generare a IP id-ului este usor de ghicit (dupa cum am spus in sectiunea 5)c) la primirea unui SYN|ACK (care nu are cum sa apara daca nu a fost trimis in prealabil un SYN) se raspunde cu RST, iar la primirea unui RST nu se raspunde cu nimic.9. Descrierea metodeiLa scan participa 3 calculatoare: A, calculatorul care "ataca" B, calculatorul care va *parea* ca scaneaza (deci a carui adresa va fi folosita drept sursa). B trebuie ales cu grija, deoarece trebuie sa indeplineasca o conditie foarte importanta: sa nu trimita/primeasca pachete in timp ce se desfasoara scanarea. Astfel de calculatoare "tacute" sunt foarte usor de gasit. In plus, orice are o adresa de IP si nu are activitate in acel moment poate fi folosit: imprimante de retea, switch-uri si hub-uri "inteligente", routere etc. C, victima. Singura conditie este sa fie vulnerabila la SYN scan (mai multe despre asta intr-un articol viitor).Metoda: A monitorizeaza cu atentie numarul de pachete trimise de B, folosind IP id-ul. Din cauza faptului ca B nu primeste/trimite alte pachete in afara de cele de la A, id-ul creste cu 1 pentru fiecare pachet. In paralel, A trimite un pachet SYN catre C (pe portul X care trebuie verificat) cu adresa lui B in loc de sursa (astfel incat C nu isi poate da seama ca pachetul vine de fapt de la A). Apar doua situatii posibile: a) portul X de pe C este inchis, caz in care C va trimite un RST catre B, care il va ignora (vezi 8.c). B nu a trimis nici un pachet, lucru care poate fi observat prin monitorizarea IP id-ului. portul X de pe C este deschis. C va incerca sa continue procedura "3-way" de stabilire a conexiunii TCP si ii va trimite lui B un pachet SYN|ACK. B stie ca nu a trimis nici o cerere de conectare la C, asa ca raspunde cu RST. C vede RST-ul si renunta la conectare. Totul pare ok, *dar* B a trimis un pachet, lucru pe care A il observa (diferenta dintre ID-urile pachetelor este mai mare decat 1)10. Cum se face practic ?Probabil ca sectiunea 9 nu e foarte explicita, asa ca sa vedem cu se face in practica. Materiale necesare:hping2[3] (sau hping > 0.67, dar hping2 este recomandat) doua console virtuale pe un calculator ruland Linux atentie si rabdare Mod de lucru: pe prima consola se monitorizeaza calculatorul B folosind comanda: # hping B -r (B este adresa IP a lui rezultatul va fi ceva de gen:eth0 default routing interface selected (according to /proc)HPING B (eth0 192.168.4.3): NO FLAGS are set, 40 headers + 0 data bytes50 bytes from 192.168.4.3: flags=RA seq=0 ttl=128 id=48498 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=4 ttl=128 id=+1 win=0 rtt=0.2 ms....Lasand primul hping pornit, trecem pe a doua consola si ii trimitem pachete false lui C: # hping C -a B -S -p X (C si B sunt adresele lui C si B, iar X este portul scanat) rezultatul nu va fi foarte interesant: eth0 default routing interface selected (according to /proc)HPING C (eth0 192.168.4.1): S set, 40 headers + 0 data bytesNu vom primi nici un pachet inapoi, fiindca C discuta cu B. Revenind insa la prima consola, observam ca diferenta dintre doua ID-uri consecutiva s-a modificat (cu cat anume depinde de timpul de propagare intre A, B si C): ...50 bytes from 192.168.4.3: flags=RA seq=221 ttl=128 id=+2 win=0 rtt=0.4 ms50 bytes from 192.168.4.3: flags=RA seq=222 ttl=128 id=+3 win=0 rtt=0.4 ms50 bytes from 192.168.4.3: flags=RA seq=223 ttl=128 id=+2 win=0 rtt=1.4 ms50 bytes from 192.168.4.3: flags=RA seq=224 ttl=128 id=+5 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=225 ttl=128 id=+4 win=0 rtt=0.4 ms...Asta bineinteles in cazul in care portul X este deschis. Daca nu e, diferenta intre ID-urile consecutive ramane aceeasi. Cam asta ar fi ideea. Dupa ce veti intelege cum functioneaza metoda si dupa ce veti face cateva teste o sa fie totul mult mai clar. 11. Tema si variatiuniAcum ca tot am inteles cum se face, hai sa ne folosim imaginatia. Putem incepe (de exemplu) prin citirea manualului de la hping si prin folosirea altor flag-uri. Sau putem folosi ceva care sa ne mai reduca din munca, de exemplu idlescan[4]. Putem sa scanam linistiti serverul unui ISP in timp ce adminul disperat vede in loguri ca scanul vine de la calculatorul secretarei 12. Observatii importantea) da, hping are nevoie de drepturi de root pentru executie calculatoarele ruland windows pun octetii invers in campul ID al pachetelor IP, asa ca trebuie folosita optiunea -W la hping pentru a vedea rezultatele corecte. Exemplu:# hping windows -reth0 default routing interface selected (according to /proc)HPING windows (eth0 192.168.4.3): NO FLAGS are set, 40 headers + 0 data bytes50 bytes from 192.168.4.3: flags=RA seq=0 ttl=128 id=25026 win=0 rtt=0.4 ms50 bytes from 192.168.4.3: flags=RA seq=1 ttl=128 id=+256 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=2 ttl=128 id=+256 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=3 ttl=128 id=+256 win=0 rtt=0.2 ms...E destul de putin probabil ca respectivul host sa trimita exact 256 de pachete la fiecare secunda. Sa incercam: # hping windows -r -Weth0 default routing interface selected (according to /proc)HPING windows (eth0 192.168.4.3): NO FLAGS are set, 40 headers + 0 data bytes50 bytes from 192.168.4.3: flags=RA seq=0 ttl=128 id=49765 win=0 rtt=0.3 ms50 bytes from 192.168.4.3: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=4 ttl=128 id=+1 win=0 rtt=0.2 ms50 bytes from 192.168.4.3: flags=RA seq=5 ttl=128 id=+1 win=0 rtt=0.2 ms...Asa mai merge Aceasta particularitate a windows-ului poate fi folosita (bineinteles) si la determinarea sistemului de operare. c) In sectiunea 9 am spus ca B nu trebuie sa trimita si sa primeasca nici un pachet. Ei bine, am mintit B poate sa aiba activitate, cu conditia sa ne dam seama *cata*. Tot ce avem de facut este sa trimitem un pic mai repede (folosind optiunea -i de la hping)(ati citit manualul hping, nu-i asa ? pachetele SYN catre C. Vom observa clar cum diferenta dintre ID-urile primite de la B creste de la (spre exemplu) 5-6 la 30-40 pachete/secunda. Quote
