La colţ de... internet: Interceptarea şi analizarea datelor transmise prin HTTPS

duminică, 4 ianuarie 2015

Interceptarea şi analizarea datelor transmise prin HTTPS

Scris duminică, 4 ianuarie 2015 , 13:14 , de Ovidiu

Poate cel mai utilizat protocol de comunicare la ora actuală prin internet este HTTP, adică Hypertext Transfer Protocol, utilizat pentru transferul de pagini web şi fişiere. Protocoalele de comunicare reprezintă un seturi de reguli prin care două calculatoare să se înţeleagă unul cu celălalt. Există multiple protocoale de comunicare, fiecare adaptate anumitor scopuri: FTP pentru transferul de fişiere, IMAP pentru accesarea email-urilor, YMSG care este protocolul proprietar din spatele Yahoo! Messenger, etc.

1. Intro (teorie, teorie, teorie!)

Marea problemă a protocolului HTTP este faptul că acesta este nesecurizat. La fel ca în cazul telefonului fix când cineva poate să înţepe firul şi să asculte ce vorbiţi, în cazul protcolului HTTP cineva din reţeaua dumneavoastră sau care intermediază conexiunea dintre dumneavoastră şi serverul web poate să citească datele transmise, inclusiv conţinutul paginilor web pe care le vizitaţi, date de autentificare (inclusiv parole), sesiuni sau alte date pe care dumneavoastră le transmiteţi sau recepţionaţi prin acest protocol. Pentru ca acest lucru să nu se întâmple schimbul de date între client şi server poate fi criptat - în cazul HTTP-ului acest lucru se întâmplă prin criptarea datelor la nivel de sesiune, protocolul rezultat astfel fiind HTTPS. La nivel de aplicaţie nu există absolut nicio diferenţă între HTTP şi HTTPS, criptarea efectivă a datelor petrecându-se la un nivel inferior.

Scandalurile privind interceptarea datelor de către NSA şi alte agenţii guvernamentale a motivat cât mai mulţi webmasteri să folosească protocolul HTTPS. În felul acesta un atacator nu poate să vadă decât IP-ul şi portul la care vă conectaţi, fără să poată vedea nici măcar URL-ul, cookie-urile sau alte date specifice protocolului HTTP. Criptarea şi decriptarea datelor se face folosind o pereche de chei, una publică şi cealaltă privată. De asemenea validarea autenticităţii paginilor web pe care le vizitaţi se face prin intermediul unor certificate. Clientul (cel mai adesea un browser web) va avea cu el o listă de certificate pe care el le consideră de încredere şi va valida, cu ajutorul lor, faptul că facebook.com (de exemplu) e chiar facebook.com şi nu un site fals unde ai fost redirectat de un atacator dornic să pună mâna pe datele tale de autentificare. În cazul în care un site foloseşte un certificat invalid sau care nu se află şi în lista de certificate "de încredere" cu care vine echipat browser-ul atunci vom fi întâmpinaţi de un mesaj de avertisment prin care ni se va recomanda să nu accesăm site-ul. Putem însă forţa browser-ul să ignore faptul că certificatul nu este valid şi să continuăm navigarea însă în felul ăsta sunt şanse ca conexiunea dintre client şi server să fie compromisă.

2. Obiective

După cum spuneam criptarea traficului prin HTTPS (de fapt SSL sau TLS) ne asigură că nimeni nu va putea citi datele transmise între noi şi serverul la care suntem conectaţi. Totuşi acest lucru se poate întoarce împotriva noastră mai ales atunci când vrem să facem reverse-engineering şi să vedem ce date transmite o aplicaţie prin internet. Există, totuşi, o cale prin care putem să citim datele transmise prin HTTPS (care poate fi folosită chiar şi în scopuri maliţioase). Pentru acest lucru este nevoie să atingem câteva obiective:

să redirecţionăm conexiunea prin calculatorul nostru (în caz că datele sunt trimise de pe alt dispozitiv - în cazul meu a fost un telefon mobil)
să forţăm clientul (o aplicaţie de pe telefonul mobil, în cazul meu) să accepte şi să folosească un certificat oferit de noi
să interceptăm, efectiv, datele transmise

Pentru atingerea punctului 1 există mai multe căi: putem face ARP poisoning şi să păcălim celelalte dispozitive să ne transmită nouă datele destinate router-ului sau putem instala un proxy pe calculatorul nostru şi să configurăm dispozitivul să folosească acel proxy. Primul caz e singurul ce poate fi folosit în cazul unui atac informatic de vreme ce al doilea necesită intervenţia benevolă a ţintei. Pentru că nu am fost interesat decât să îmi monitorizez propriul meu telefon mobil varianta pe care am ales-o în cazul meu a fost cea de-a doua.

Punctul 2 are de-a face cu acea listă de certificate de încredere ale clientului. De vreme ce noi vom folosi un certificat propriu care nu există în acea listă va trebui să îi spunem clientului să ignore faptul că certificatul folosit e unul nerecunoscut ori să adăugăm certificatul în lista celor de încredere. În cazul unui browser va apare un avertisment de unde putem alege să continuăm navigarea în pofida pericolului de a fi interceptaţi. În cazul unei aplicaţii nu va mai apare niciun avertisment aşa că va trebui să adăugăm certificatul nostru în acea listă de încredere a telefonului.

Pentru punctul 3 vom folosi un server de proxy care ne va permite să analizăm datele ce trec prin intermediul acestuia.

3. Să trecem la practică!

După cum spuneam vom folosi un server de proxy instalat pe calculatorul nostru şi vom configura clientul (telefonul mobil, în cazul meu) să folosească acest proxy. Serverul în cauză este Charles Proxy, o aplicaţie scrisă în Java care poate fi descărcată în versiune de evaluare de aici. Cei ce folosesc Arch Linux vor găsi aplicaţia în AUR. După rularea aplicaţiei vom activa proxy-ul SOCKS de la meniul Proxy -> Proxy Settings şi de la tab-ul SSL vom activa (dacă nu e deja activat) Enable SSL proxying. Vom adăuga apoi un host pe care dorim să îl monitorizăm apăsând butonul Add. Introdu aici IP-ul sau domeniul host-ului iar mai apoi port-ul (care cel mai probabil va fi 443, în cazul HTTPS). În cazul în care vrei să monitorizezi absolut orice trece prin proxy poţi folosi * atât pentru host cât şi pentru port.

Vom configura apoi telefonul să se conecteze la proxy-ul nostru. Pe Android acest lucru se face de la setările pentru WiFi, ţinând lung apăsat pe reţeaua la care suntem conectaţi şi alegând Modify network. Bifând Show advanced options ni se dezvăluie setările pentru proxy. La selecţia opţiunii Manual ni se dezvăluie un lucru:

Aşadar aplicaţiile din telefon nu vor folosi neapărat setările introduse aici. Din păcate singura cale de a face aplicaţiile să se conecteze prin proxy-ul nostru este folosirea aplicaţiei ProxyDroid, care necesită root. Dacă aceasta nu e o problemă atunci instalaţi aplicaţia şi configuraţi-o să folosească un proxy de tip SOCKS5, la Host şi Port introducând adresa IP a calculatorului pe care rulează Charles şi portul pe care acesta ascultă (by default 8889). Activaţi proxy-ul de la Proxy Switch şi rulaţi aplicaţia pe care doriţi să o monitorizaţi (ca demonstraţie eu am ales aplicaţia oficială de la Facebook). Pe calculator e posibil să vă apară următorul dialog; apăsaţi Allow pentru a permite telefonului să folosească proxy-ul.

Din acest moment în Charles vor începe să apară date. Vom putea vedea acolo protocolul folosit, adresa IP sau domeniul şi portul la care s-a făcut conexiunea. Dacă vom face expand la un host cel mai probabil vom vedea multe X-uri roşii. Acestea arată că interceptarea datelor a eşuat. Dând click pe unul vom vedea şi de ce:

Aplicaţia a încercat să se conecteze prin HTTPS, a primit un certificat oferit de Charles însă telefonul nu a văzut acel certificat în lista sa de certificate de încredere aşa că l-a respins. Trebuie, deci, să instalăm certificatul în telefonul nostru. Pentru asta accesăm http://www.charlesproxy.com/charles.crt din browser-ul telefonului nostru mobil. Dăm un nume oarecare certificatului şi apăsăm OK. Încercăm din nou şi...

În cazul meu m-am logat pe contul de Facebook din aplicaţia de Android. După cum se vede în screenshot-ul de mai sus pot să văd datele transmise prin POST cât şi răspunsul primit (în tabul Response). După cum se vede în partea stângă conexiunea s-a făcut la b-api.facebook.com prin HTTPS, deci tocmai ne holbăm la ce se transmite printr-o conexiune securizată. Am încercat, de asemenea, să mă loghez pe contul de PayPal din browser-ul telefonului şi totul a decurs fără probleme şi fără măcar vreun avertisment din partea browser-ului (username-ul şi parola fiind interceptate de Charles):

Cine a făcut însă scandal, în mod surprinzător, a fost sistemul de operare care a ştiut că ceva nu miroase bine în privinţa certificatului de la Charles şi a afişat un avertisment:

De remarcat e că unele aplicaţii refuză, totuşi, să se conecteze folosind această metodă de monitorizare făcând, probabil, propria lor verificare în privinţa certificatului folosit pentru conectare. Această metodă funcţionează şi pe iPhone, odată setat proxy-ul şi instalat certificatul de la Charles (iOS afişează, însă, două avertismente privind instalarea certificatului).

4. Încheiere

Aşadar am putut citi datele transmise prin HTTPS, ba chiar de pe o altă maşină decât cea de pe care sunt transmise datele! Înseamnă oare asta că HTTPS nu asigură protecţia pe care ne-o promite?

În niciun caz. Dacă partea cu setarea unui proxy pe dispozitivul-ţintă se poate ocoli prin ARP poisoning tot mai e necesar să instalezi propriul tău certificat pe acesta. Desigur, cu puţin social engineering acest pas poate fi uşor aplicat însă prin social engineering se pot obţine mult mai multe lucruri cu mult mai puţin efort.

Ce poţi face ca utilizator normal pentru a te proteja? În primul rând nu instala niciun certificat în telefonul sau browser-ul tău decât doar dacă ai încredere 100% în sursa acestuia. Aşa arată un dialog de instalare a unui certificat pe Android şi pe iOS. În caz că acest dialog apare din senin: cancel, cancel, cancel!

Apoi mare atenţie la mesajele de avertisment pe care vi le dă browser-ul! Nu e normal ca pe un site mare cum e facebook.com, google.com sau paypal.com să apară un astfel de avertisment:

Acest mesaj mai apare uneori pe site-urile prost configurate, care folosesc un certificat propriu sau expirat, însă nu trebuie să apară pe site-urile mari. În cazul în care întâlniţi acest mesaj pe un site important verificaţi dacă data calculatorului este setată corect şi dacă da închideţi imediat conexiunea la internet şi investigaţi sursa problemei! Calculatorul face tot ce poate să vă avertizeze împotriva pericolului însă ignorarea avertismentului poate aduce consecinţe grave.

2 comentarii :

Anonim spunea...: FYI, mie mi-a mers cu proxy-ul din android, de la setarile wi-fi (telefonul nu e rootat)
(Nexus 5, android 4.4.4); 5 ianuarie 2015 la 16:14
Iulian spunea...: Interesanta metoda cu monitorizarea prin telefon. Cum ti-a venit ideea? :)); 2 iunie 2015 la 16:29