Din câte știu, este acum în curs o schemă destul de bine cunoscută și simplă pentru interceptarea traficului în browsere (pentru modificarea și colectarea de informații). Schema deși populare, dar concentrat exclusiv pe anumite versiuni de browsere.
De exemplu, pentru IE, se utilizează o schemă cu interceptarea funcțiilor lui wininet. Apropo, există cel puțin două versiuni de logică: interceptarea, sincronizarea InternetReadFile (Ex) și interceptarea ortodoxă a callback-ului InternetStatusCallback și toate funcțiile auxiliare.
Cea de-a doua abordare are cu siguranță mai mult succes din punct de vedere arhitectural, deoarece toate operațiunile din IE apar asincron și nu există niciun decalaj. Asta este, după instalarea interceptărilor, Wininet rămâne asincron, așa cum a fost proiectat de dezvoltatorii microsoft. Din punctul de vedere al codului, această abordare este mult mai complicată decât prima (în special, folosită în Zeus și în clonele sale, cum ar fi cetatea și alte zguri).
În ceea ce privește restul browserelor, totul nu este atât de transparent. Pentru Chromium și Frax Fox utilizați interceptarea funcțiilor NSS (Network Security Services) și mai precis funcțiile PR_ReadPR_Write.
În Faer Fox, aceștia sunt exportați nspr4.dllnss3.dll (DLL depinde de versiune), în câmpurile cromate funcțiile sunt preluate din tabel, care este cel mai adesea căutat pentru semnături. În Opera, este absolut neclar ce și cum, din moment ce inversează memoria, motorul se schimbă în mod constant, iar deliciositatea ca PDB nu vine de la acesta. Deși putem presupune că Opera Next, construită pe Chromium, poate fi compromisă în același mod ca și cromul (căutarea funcțiilor nss3). În cele din urmă, avem o interceptare stabilă, poate doar în IE (pentru momentul citirii articolului, să presupunem că codul scris pentru aceste scopuri nu crash fundul și funcționează stabil).
Metoda de semnare nu poate fi considerată a priori ca stabilă, deoarece aceste două concepte sunt incompatibile. Mâine va fi o versiune nouă a browser-ului, care este scris într-un cod diferit, a adăugat o metodă de clasa, ceva undeva este mutat și semnătura va fi bătut în jos. Mai ales crom, care, probabil, va renunța în curând la NSS. Fare Fox a jucat recent, de asemenea, un rol activ în modernizarea codului vechi, care poate fi văzut cu ochiul liber din cușcă. Funcțiile de testare și certificatele de validare NSS înseamnă deja refuzată, înlocuind această parte a unui nou brand mozilla :: pkix (mulți sunt deja agățare nishtyaki pounding CODESA dezactiva funcțiile de validare). Totuși, probabil, perspectiva pe care am subliniat-o este prea pesimistă și codurile actuale vor funcționa încă 200 de ani.
Complexitatea tuturor acestor metode mi se pare, în netranspunerea universalitate, necesitatea de a monitoriza browsere de upgrade, munți interceptări, care sunt gata pentru a proteja alt tip de raport propulsoarele, necesitatea de a menține mai multe ramuri de cod, efectuarea unui obiectiv „simplu“ - pentru a interveni în utilizatorul sslhttp de trafic.
Asa cum mi se pare, cârligul pe legătura lipsită de ambiguitate spune "despre ceva, apoi despre asta". Mai neajutorat ar fi să hack NtDeviceIoControlFile. În monitor, dacă IoControlCode este IOCTL_AFD_CONNECT, atunci patch-uri nemilos InputBuffer. Acesta va avea structura AFD_CONNECT_INFO și în ea tot ce trebuie să știți pentru a schimba pentru redirecționarea conexiunii reușită. Detaliile implementării vor fi lăsate pe conștiința experimenților.
Trebuie remarcat faptul că structurile pentru NT5 și NT6 + sunt diferite. Dar, în acest moment, puteți să încercați să conectați procesul în care suntem.
Conectat la conexiune. Unde să-l trimiteți? Răspunsul la "localhost" pare evident. La localhost, vom ridica serverul https pentru a rezolva cererile și răspunsurile browserului. Хттп от хттпс este exprimată numai de stratul SSL, altfel, bineînțeles totul este același. https și în https. Acest moment îi poate speria realizarea non-banală, dar, de fapt, suntem în legătură cu teoria, hehe.
Restul este o chestiune de tehnică. Putem modifica atât cererea (înlocuirea datelor POST), cât și răspunsul, colectând un răspuns la buffer-ul temporar, pentru interogarea de care suntem interesați. Totul este destul de transparent, totul este simplu. Apropo, un parser excelent https este în libevent. Utilizează NGINX pentru propriile scopuri, este compact, depanat și stabil.
Să spunem că toate astea sunt făcute pentru noi. Începând cu acest moment, nu este dificil să interceptați traficul în HTTP. Singura sarcină "dificilă" va fi doar parsarea conținutului neregulat, cum ar fi codificarea chanked și gzip. Dar, în mod ideal, acest lucru se datorează conștiinței parserului xttp și zlib-ului conectat. În acest fel este mai dificil punct de vedere tehnic decât cel care este utilizat în răspunsurile parsing Zeus - interogări în FF, dar mai stabil și corect, ca browser-ul continuă să comunice cu serverul HTTP și nu-l forțeze pentru a obține un răspuns surogat și nu forțați browser-ul pentru a dezactiva gzip, interferând în truda lui în timp real.
Această abordare permite de asemenea să profite de toate avantajele HTTPS, cum ar fi pipelining, webcam, compresie, control transparent al utilizării proxy-ului https.
HTTPS. Iată câteva dificultăți. Dar totul este rezolvat. Să analizăm în detaliu Este greu să fiți distras de modul în care funcționează SSL, de ce este necesar să aveți un certificat valid și de ce nu vom putea interveni în browser dacă nu există un certificat. Dar nu avem un certificat valabil pentru niciun domeniu, astfel încât să puteți face acest lucru în mod diferit.
Prima abordare. verificarea certificatului de verificare. Metoda este dibioasă, recomandându-i cu succes inaplicabilitatea. Esența se reduce la, în scopul de a crea o conexiune cu un browser lokalhost sertiftkatom auto-semnat, dar capcane care introduc în interiorul CryptoAPI și în browsere (funcții de cele mai multe ori non-exportate browser-ul de audit intern), pentru a crea aparența că sertifkat normală. În plus, există numeroase efecte secundare:
1 - toate site-urile incep brusc sa utilizeze acelasi certificat. De exemplu, dacă mă duc la Google, acolo se eliberează certificatul "super co ltd". Dacă mergeți la Microsoft, atunci există același "super co ltd".
O persoană normală va suspecta imediat că ceva nu este în regulă. Și publicul țintă, desigur, nu este idioți.
2 - Instabilitatea metodei, deoarece funcția de verificare a browserului (excepția IE) nu se grăbește să marcheze ca exportată. Prin urmare, o mulțime de hemoroizi, cum ar fi faptul că funcțiile se schimbă, semnăturile lor se schimbă, numărul de parametri poate varia (fenomen normal în cazul cromului)
Cum de a face ca totul să fie bine? Evident, este necesar să nu atingeți certificatele sau să faceți ca nimeni să nu vadă diferența dintre prezent și fals. Trebuie să generăm un certificat pentru fiecare domeniu, duplicând complet toate intrările acestui certificat într-un certificat nou, fals. De exemplu, schema este următoarea:
1 - prinde conexiunea browser-ului către serverul de la distanță
2 - redirecționarea către localhost, pornind de acolo o nouă instanță a serverului TCP, o copie a căreia este legată de gazda unde browserul a fost inițial rulat
3 - În instanța serverului, așteptăm conexiunea browserului. Odată ce browserul este conectat, nu pornim o sesiune SSL, ci mergeți la gazda unde a venit inițial browserul. Modul în care va face Google.
4 - După inițializarea conexiunii SSL cu Google, obținem un certificat de la acesta, parsează toate câmpurile din acesta.
5 - creăm propriul nostru certificat, pe baza a tot ceea ce am reușit să ieșim din această biserică. Pentru zamylivaniya ochi suficient câmpuri CN, E, OU, etc câmpuri de bază x509
6 - convertiți instanța noastră a serverului TCP pe un server SSL, pornind mâna de la noul certificat generat.
Ca rezultat, avem o generație dinamică de biserici pentru fiecare domeniu. Rezultatul generării poate fi stocat în cache-urile locale, desigur. În acest fel, putem să vă asigurați că certificatele sunt cele de care aveți nevoie (prin compoziție). Pentru ca browser-ul să nu jure la faptul că barajul este auto-fabricat, este necesar să se facă astfel încât să nu fie făcut 🙂
Adică, trebuie să înceapă să genereze unele tsert inițiale, care dau dreptul de a semna sertifkaty (CertStrToName, CertCreateSelfSignCertificate), punând steagurile corespunzătoare la crearea certificatului:
Apoi, adăugați-l la Stocarea bisericilor de încredere Windows (CertAddCertificateContextT oStore). Apoi asociați-o cu cheia privată generată (CryptGenKey / CryptAcq uireCertificatePrivateKey). Asta e tot!
Acum, agloritm extinde faptul că pentru domeniu vom genera un certificat și îl vom semna cu rădăcina noastră.
Algoritmul browserului arată că cp este real, totul funcționează așa cum ar trebui, traficul este interceptat. Mai mult, nu mai puteți genera din nou un certificat, ci pur și simplu să îl semnați din nou pe cel care provine de la același Google.
Browserul va vedea șirul de caractere, va începe să dezvăluie lanțul de livrare, va cădea peste încrederea noastră, care este listată ca editor de certificate, asigurați-vă că certificatul este valid. Profit.
Ce se întâmplă în reziduul uscat?
1 - O interceptare, într-o funcție complet documentată și nicăieri divergentă în ntdll.
2 - Independența de platforma browserului (3264) și caracteristicile implementării mecanismelor sale de verificare a bisericilor și a altor rahaturi:
3 - lucrul la toate viespile este la fel de nedureros;
4 - Lucru complet invizibil pentru utilizator (totul funcționează rapid, deși depinde de parserul xtpp), toate certificatele rămân aceleași cum ar trebui să fie.
Vă mulțumesc pentru atenție!
Trimiteți-le prietenilor: