Breșe de securitate descoperite în serviciile de VPN oferite de mulți furnizori

Anul acesta, pe 30 Iunie, în cadrul celui de-al 15-lea Privacy Enhancing Technologies Symposium, o echipă de cercetători de la Universitatea Sapienza din Roma și Universitatea Queen Mary din Londra au prezentat o lucrare care atrage atenția asupra unor probleme serioase de securitate descoperite la multe dintre serviciile de VPN disponibile pe piață.

Foarte generic, un VPN (Virtual Private Network – Rețea Virtuală Privată) este o metodă de a extinde o rețea privată folosind tunele criptate care traversează o rețea publică. La originea acestui concept au stat companiile care doreau să permită angajaților să se conecteze de acasă sau de pe teren la rețeaua privată a companiei și să poată face acest lucru fără a compromite securitatea rețelei private. Tehnic, conceptul este foarte simplu. Continuând exemplul clasic al companiei cu angajații care lucrează de acasă sau de pe teren, compania are un server de VPN care creează și gestionează tunele criptate la cererea clienților, angajatul are un client de VPN care se conectează la serverul de VPN al companiei și cere să-i fie creat un tunel criptat. După ce clientul și serverul stabilesc conexiunea, clientul își modifică tabela de rutare și lista de servere de rezoluție de nume (DNS) în mod corespunzător pentru ca toate, sau o parte din, conexiunile către Internet să fie direcționate prin tunelul criptat.

În ziua de astăzi, VPN-urile nu mai sunt folosite doar pentru conectarea de acasă sau de pe teren la rețeaua firmei, sau a facultății, sau a institutului etc., ci și ca metodă de securizare a conexiunii la Internet împotriva diverselor tipuri de adversari. În speță, cineva poate sa aibă un server de VPN acasă astfel încât să aibă acces la rețeaua privată de acasă chiar și când nu este acasă. Cineva poate să aibă un server de VPN acasă ca să poată să acceseze diverse servicii online în siguranță, prin conexiunea de acasă, chiar și dintr-un aeroport sau hotel care pune la dispoziție doar conexiuni nesecurizate. Cineva poate că nu este în măsură să își instaleze sau administreze singur un server de VPN, așa că poate să cumpere acest serviciu de la un furnizor de servicii de VPN în care are încredere. Cineva poate să apeleze la servicii de VPN pentru a-și anonimiza traficul de date atunci când consideră că îi este pusă în pericol siguranța dacă anumiți adversari i-ar afla diverse interese, cum ar fi păreri politice sau orientări sexuale care nu sunt agreate în locul unde trăiește. Cineva poate folosi VPN-uri pentru a putea accesa conținut audio-vizual care este restricționat din punct de vedere geografic. Un exemplu halucinant, în acest caz, este cel al Netflix, care nu este disponibil în Australia și peste 200000 de clienți bun-platnici ai serviciului au nevoie să folosească servicii de VPN pentru a putea accesa Netflix-ul. Acestea sunt doar câteva exemple, dar într-o lume în care avem de a face cu supravegherea generalizată a Internetului de către diverse state și profilarea comportamentală a utilizatorilor de către diverse firme, folosirea unui VPN se transformă dintr-o curiozitate într-un lucru firesc.

Ca orice altă tehnologie, nici VPN-urile nu sunt perfecte, iar dacă sunt făcute greșeli ori de către furnizorul de servicii, ori de către client, ori de către ambele părți, atunci potențialele beneficii ale folosirii unui VPN nu vor fi realizate.

Lucrarea menționată prezintă două mari clase de probleme descoperite și care pot cauza scurgerea de informații în afara VPN-ului. Cele două clase de probleme sunt scurgerile de IPv6 (IPv6 leakage) și deturnarea de DNS (DNS hijacking).

Scurgeri de IPv6 (IPv6 leakage)

Schema de adresare clasică folosită de cele mai multe ori pe Internet este cea a protocolului fundamental al Internetului, numit Internet Protocol, versiunea 4 (pe scurt IPv4). Problema cu spațiul de adrese IPv4 este că este prea mic în comparație cu cerințele Internetului din ziua de astăzi. Pentru a veni în întâmpinarea acestei probleme, a fost dezvoltat Internet Protocol, versiunea 6 (pe scurt IPv6). Pentru a facilita utilizarea IPv6, toate sistemele de operare moderne au implementat suport pentru IPv6. Windows-ul are suport de IPv6 începând cu Windows XP SP2, Mac OS de la OS X 10.2. Toate distribuțiile majore de GNU/Linux, cât și distribuțiile derivate din acestea, au suport pentru IPv6. La fel și toate sistemele de operare mobile, cum ar fi iOS și Android. Mai mult decât atât, cu excepția unor versiuni vechi ale acestor sisteme de operare, toate versiunile recente nu doar că au suport pentru IPv6, dar chiar au IPv6-ul activat din start. Atunci când sunt activate ambele și există opțiunea de a folosi ori IPv4 ori IPv6 pentru a se conecta la un serviciu, sistemul de operare va alege întotdeauna IPv6. Aici apare prima problemă.

Atunci când este activat și IPv4 și IPv6 iar clientul de VPN, atunci când creează tunelul, nu modifică decât tabela de rutare de IPv4 astfel încât traficul să plece mereu prin tunel, nu și pe cea de IPv6, rezultatul este că orice potențial trafic de IPv6, în loc să plece spre Internet prin tunelul criptat al VPN-ului, va pleca prin conexiunea nesecurizată. Aceasta devine o problemă reală în cazul accesării anumitor servicii/site-uri care oferă suport și pentru IPv4 și pentru IPv6. În cazul serviciilor/site-urilor care nu oferă suport pentru IPv6, nu există o problemă. În cazul celor care oferă, sistemul de operare, după cum spuneam mai sus, va prefera întotdeauna IPv6 și va trimite traficul folosind rutele de IPv6… care nu îndreaptă traficul prin tunelul de VPN ci pe lângă el. Rezultatul este că pot fi dezvăluite de la informații de adresare (de exemplu ce site-uri/servicii a accesat clientul) și până la conținut (de exemplu comentarii puse pe diverse site-uri, în cazul site-urilor care nu folosesc HTTPS).

Existența acestei probleme depinde, în primul rând de furnizorul de servicii, dar și de utilizator. În primul rând, furnizorii de servicii de VPN oferă, de obicei, două alternative: ori folosirea de către utilizator a unui client de VPN propriu respectivului furnizor, ori furnizorul pune la dispoziția utilizatorului ori un fișier de configurare, ori instrucțiuni de configurare a unuia sau mai multor clienți de VPN standard. În cazul folosirii unui client personalizat, responsabilitatea care în principal pe umerii furnizorului pentru a avea grijă ca configurația de bază a clientului să prevină această problemă. În cazul folosirii unui client generic, responsabilitatea se împarte între furnizor și utilizator. Pe de o parte, furnizorul are datoria să își configureze serverul corect pentru a preveni această problemă și de a furniza fișiere de configurare și instrucțiuni de configurare adecvate, dar și utilizatorul are responsabilitatea de a avea grijă să își configureze clientul generic în mod corect în concordanță cu instrucțiunile primite de la furnizor.

Există variații în amploarea problemei și în funcție de sistemul de operare. În particular, în cazul sistemelor de operare mobile, a fost observat faptul că toate serviciile de VPN testate au fost imune la scurgeri de IPv6 pe iOS, IPv6-ul fiind dezactivat complet cât timp tunelul de VPN este activ. La polul opus, s-a aflat sistemul de operare mobil Android, pe care absolut toate serviciile de VPN au avut scurgeri de IPv6, indiferent de configurările furnizorilor.

Cu toate acestea, problema poate fi rezolvată foarte ușor în câteva moduri:
1. Dezactivarea IPv6-ului din sistemul de operare, dacă nu este necesar în mod explicit pentru altceva, sau
2. Blocarea folosind un firewall al traficului de IPv6, mai exact:
2.1. Blocarea întregului trafic de IPv6, dacă nu este necesar în mod explicit pentru altceva, sau
2.2. La conectarea la VPN, blocarea întregului trafic de IPv6 care nu iese prin gateway-ul VPN-ului. De fapt, acest lucru poate fi făcut, pentru siguranță, chiar și cu traficul de IPv4. Mai exact: la stabilirea tunelului între client și server, este creată o interfață virtuală prin care ar trebui să fie rutat întreg traficul. Dar, fizic, pachetele de date care trec prin tunel, și cele care sunt folosite pentru crearea tunelului în sine, trec prin interfața fizică a dispozitivului, toate având ca destinație adresa IP a serverului de VPN. Așadar, trebuie să ne legam de interfața fizică atunci când facem filtrarea. Filtrul va fi foarte simplu: pe interfața fizica nu au voie să iasă decât pachete care au ca destinație adresa IP a serverului de VPN. Orice pachet care încearcă să iasă prin interfață fizică către orice altă destinație va fi blocat, iar singurele pachete care vor putea ieși, o vor face prin tunel.

Pe un calculator personal, acestea sunt operații relativ ușor de realizat, chiar și pentru utilizatori neexperimentați. Pe un telefon mobil, în funcție de sistemul de operare, acestea s-ar putea să fie mult mai dificil, dacă nu chiar imposibil de realizat. Aici ar putea fi deschisă o discuție mai amplă vis-a-vis de dezavantajele și vulnerabilitățile create de sistemele de operare mobile prin împiedicarea utilizatorilor acestora de la a avea acces nerestricționat la hardware-ul dispozitivelor.

Deturnarea de DNS (DNS hijacking)

DNS (Domain Name System) este un sistem care este folosit pentru a asocia nume (numite nume de domeniu sau domenii) ușor de ținut minte adreselor IP (nu este relevant în cazul de față daca vorbim de IPv4 sau IPv6 pentru că DNS-ul funcționează pentru ambele tipuri de adrese). Rețelele de calculatoare care formează Internetul și sistemele de operare comunică folosind adresele IP. Pentru a transforma numele de domeniu folosite de oameni și aplicații în adresele IP necesare sistemului de operare pentru a comunica cu alte dispozitive, este folosit sistemul DNS. Sistemele de operare au implementați clienți de DNS care se conectează la servere de DNS pentru a transforma nume de domenii în adrese IP. Problema apare în momentul în care un atacator înlocuiește un server de DNS legitim cu un server de DNS compromis care, atunci când primește cereri de transformare a numelor de domeniu în adrese IP, adresele IP returnate clientului sunt niște adrese false, făcând, astfel, ca clientul să transmită date, potențial sensibile, către un calculator aflat sub controlul atacatorului în loc să le trimită către destinația corectă. Atacatorul, de cele mai multe ori va trimite datele mai departe, devenind un intermediar care vede întreg traficul victimei, astfel încât victima poate să nici nu își dea seama că secretul comunicațiilor sale a fost compromis.

Deturnarea de DNS, în manifestarea sa cea mai simplă, este o problemă particulară sistemelor de operare din familia Windows. Motivul pentru aceasta este că sistemele de operare din familia Windows au configurații de DNS separate pentru fiecare interfață, spre deosebire de restul sistemelor de operare care au configurații de DNS globale. Totuși, vulnerabilitățile descoperite și prezentate în lucrarea menționată pot fi implementate pentru a ataca orice sistem de operare.

Complexitatea atacurilor variază în funcție de modul în care furnizorul de VPN tratează problema serverelor de DNS, dacă la stabilirea tuelului:
1. clientul de VPN nu primește de la serverul de VPN și, în consecință, nu își schimbă, serverele de DNS – în acest caz, atacul este trivial, pentru că atacatorul nu are de făcut nimic decât să furnizeze prin DHCP, la conectarea la rețeaua locală, orice servere de DNS compromise dorește;
2. clientul de VPN își schimbă serverele de DNS, dar acestea sunt server de DNS publice, cum ar fi cele de la OpenDNS sau Google DNS;
3. clientul de VPN își schimbă serverele de DNS și acestea sunt servere de DNS private, administrate de furnizorul de servicii VPN.

Acest atac se bazează pe faptul că un atacator care controlează rețeaua locala la care este conectată victima, ceea ce nu este un scenariu ieșit din comun absolut deloc, poate manipula funcționarea rețelei locale pentru a injecta rute fictive în tabela de rutare a dispozitivului atacat. La stabilirea tunelului către serverul de VPN, este modificată tabela de rutare astfel încât toate pachetele care se îndreaptă către adrese care nu sunt în rețeaua locală, să o ia prin tunel. Aici intervine problema: un atacator care știe care este adresa serverelor de DNS folosite de VPN-ul victimei, va putea să creeze o rețea locală fictiva care să conțină adresa serverului de DNS folosit de respectivul furnizor de servicii VPN. Acesta nu este un obstacol real pentru un atacator serios pentru că un astfel de atacator își poate crea o bibliotecă cu, cel puțin, adresele serverelor de DNS ale tuturor furnizorilor de servicii de VPN populari și cu cele mai populare servere de DNS publice. Această rețea fictivă, fiind locală, pachetele către ea nu vot fi trimise prin tunel, ci direct pe interfața fizică, conectată la rețeaua locală. Astfel, cererile care ar fi trebuit sa ajungă, în mod sigur, prin tunel, la serverele reale de DNS, vor ajunge la serverul fals de DNS al atacatorului. În momentul în care translația numelor de domeniu a fost compromisă, tot ce este transmis va putea fi capturat, chiar dacă pachetele sunt trimise, în primă instanță, prin tunelul de VPN.

O soluție la aceste atacuri care poate fi implementată de furnizorii de servicii de VPN ar fi să folosească servere de DNS private și că acestea să aibă aceeași adresă IP ca serverul de VPN, astfel încât dacă cererile către serverul de DNS sunt redirecționate, și adresa serverului de VPN să fie redirecționată, iar dacă aceasta este redirecționată, conexiunea nu va mai putea fi stabilită de către client, acesta dându-și astfel seama că ceva nu este în regulă.

Altă soluție, din partea clientului de această dată, este ca redirecționarea pachetelor către tunel să fie făcută prin reguli în firewall, nu prin rute în tabela de rutare, astfel încât injectarea de rute false să nu afecteze în nici un fel destinația pachetelor. Aceasta este soluția implementată în sistemul de operare mobil Android, începând cu versiunea Kit Kat (4.4.x). Soluția propusă mai devreme, la atacul precedent, prin care toate pachetele care ar încerca să iasă pe orice altă cale decât prin tunel să fie blocate, ar preveni deturnarea DNS-ului, dar ar și împiedica translația numelor în adrese IP, pierzându-se astfel din funcționalitate. Așadar, aceasta ar trebui îmbunătățită prin adăugarea unei reguli în firewall care, în mod explicit, să direcționeze prin interiorul tunelului toate pachetele către serverul de DNS folosit.

Alte probleme

O altă problemă observată, dar care care este o problemă veche și bine cunoscută, este folosirea de tehnologii nesigure pentru crearea VPN-urilor. În momentul de fața, cea mai sigură tehnologie este OpenVPN, dar nu toți furnizorii o folosesc, și chiar și printre cei care o folosesc, nu toți o folosesc în mod exclusiv, astfel că un utilizator neinformat s-ar putea să aleagă să folosească o tehnologie mai nesigură, cum ar fi PPTP sau L2TP pentru crearea tunelului. De exemplu, PPTP-ul folosește protocolul de autentificare MS-CHAPv2, care este bine știut ca fiind nesigur.

Proiectul "Protectia datelor personale este un drept fundamental!" este finanțat prin granturile SEE 2009-2014, în cadrul Fondului ONG în România. Conținutul acestui website nu reprezintă în mod necesar poziția oficială a granturilor SEE 2009-2014. Întreaga răspundere asupra corectitudinii și coerenței informațiilor prezentate revine inițiatorilor website-ului.

Pentru informații oficiale despre granturile SEE și norvegiene accesați http://www.eeagrants.org