De la traducător și TL;DR
-
TL; DR:
Se pare că VoLTE s-a dovedit a fi și mai prost protejat decât primii clienți Wi-Fi cu WEP. O greșeală de calcul exclusiv arhitecturală, care vă permite să XOR puțin traficul și să restabiliți cheia. Un atac este posibil dacă sunteți aproape de apelant și acesta face apeluri frecvent.
-
Mulțumesc pentru pont și TL;DR
-
Cercetătorii au creat o aplicație pentru a determina dacă operatorul dvs. este vulnerabil, citiți mai multe . Distribuie rezultatele în comentarii, VoLTE este dezactivat în regiunea mea pe Megafon.
Despre autor
Matthew Green.
Sunt criptograf și profesor la Universitatea Johns Hopkins. Am proiectat și analizat sisteme criptografice utilizate în rețele wireless, sisteme de plată și platforme de securitate a conținutului digital. În cercetarea mea, mă uit la diferite moduri de a folosi criptografia pentru a îmbunătăți confidențialitatea utilizatorilor.
A trecut ceva timp de când am scris un format de postare , și m-a supărat. Nu pentru că nu au existat atacuri, ci mai ales pentru că nu a existat un atac la ceva suficient de folosit pentru a mă scoate din blocajul scriitorului.
Dar azi am dat peste numit ReVoLTE pentru protocoalele de care sunt deosebit de încântat de hacking, și anume protocoalele LTE pentru rețelele celulare (voice over). Sunt încântat de aceste protocoale specifice – și de acest nou atac – pentru că este foarte rar să vezi protocoale și implementări reale ale rețelei celulare piratate. În principal pentru că aceste standarde au fost dezvoltate în camere pline de fum și documentate în documente de 12000 de pagini pe care nu orice cercetător le poate gestiona. Mai mult, implementarea acestor atacuri obligă cercetătorii să folosească protocoale radio complexe.
Astfel, vulnerabilitățile criptografice grave s-ar putea răspândi în întreaga lume, poate doar pentru a fi exploatate de guverne, înainte ca vreun cercetător să ia seama. Dar din când în când există și excepții, iar atacul de astăzi este unul dintre ele.
Autori Colaboratori: David Rupprecht, Katharina Kohls, Thorsten Holz și Christina Pöpper de la Ruhr-University Bochum și New York University Abu Dhabi. Acesta este un atac grozav pentru a reinstala cheia în protocolul vocal pe care probabil îl utilizați deja (presupunând că sunteți dintr-o generație mai veche care încă efectuează apeluri telefonice folosind un telefon mobil).
Pentru început, o scurtă excursie istorică.
Ce sunt LTE și VoLTE?
Baza standardelor noastre moderne de telefonie celulară a fost pusă în Europa în anii 80 de către standard (Sistemul global pentru comunicații mobile). GSM a fost primul standard major de telefonie celulară digitală, care a introdus o serie de caracteristici revoluționare, cum ar fi utilizarea pentru a proteja apelurile telefonice. GSM timpuriu a fost conceput în primul rând pentru comunicații vocale, deși banii ar putea fi .
Pe măsură ce transmisia de date a devenit mai importantă în comunicațiile celulare, standardele Long Term Evolution (LTE) au fost dezvoltate pentru a eficientiza acest tip de comunicare. LTE se bazează pe un grup de standarde mai vechi, cum ar fi GSM, и și este conceput pentru a crește viteza de schimb de date. Există mult branding și dar TL;DR este că LTE este un sistem de transmisie de date care servește drept punte între protocoalele mai vechi de date sub formă de pachete și viitoarele tehnologii de date celulare. .
Desigur, istoria ne spune că odată ce există suficientă lățime de bandă (IP) disponibilă, concepte precum „voce” și „date” vor începe să se estompeze. Același lucru este valabil și pentru protocoalele celulare moderne. Pentru a face această tranziție mai ușoară, standardele LTE definesc (VoLTE), care este un standard IP pentru efectuarea apelurilor vocale direct pe planul de date LTE, ocolind complet porțiunea de linie telefonică a rețelei celulare. Ca și în cazul standardului ,Apelurile VoLTE pot fi terminate de către operatorul de telefonie mobilă și conectate la rețeaua telefonică obișnuită. Sau (cum devine din ce în ce mai obișnuit) ei direct de la un client celular la altul și chiar între diferiți furnizori.
La fel ca VoIP standard, VoLTE se bazează pe două protocoale populare bazate pe IP: Protocolul de inițiere a sesiunii (Session Initiation Protocol) ( – SIP) pentru configurarea apelurilor și protocolul de transport în timp real (, care ar trebui să se numească RTTP, dar se numește de fapt RTP) pentru procesarea datelor vocale. VoLTE adaugă și câteva optimizări suplimentare ale lățimii de bandă, cum ar fi compresia antetului.
Bine, ce legătură are asta cu criptarea?
LTE, cum ar fi , are un set standard de protocoale criptografice pentru criptarea pachetelor pe măsură ce acestea sunt transmise prin aer. Acestea sunt concepute în principal pentru a vă proteja datele pe măsură ce acestea circulă între telefon (numit echipament utilizator sau UE) și turnul celular (sau oriunde furnizorul dvs. decide să încheie conexiunea). Acest lucru se datorează faptului că furnizorii de telefonie mobilă văd dispozitivele externe de interceptare ca pe inamici. Ei bine, desigur.
(Cu toate acestea, faptul că conexiunile VoLTE pot apărea direct între clienții din rețele de furnizori diferiți înseamnă că protocolul VoLTE în sine are unele protocoale de criptare suplimentare și opționale care pot apărea la nivelurile superioare ale rețelei. Acest lucru nu este relevant pentru articolul actual, cu excepția faptului că pot strica totul (vom vorbi pe scurt despre ele în continuare).
Din punct de vedere istoric, criptarea în GSM a fost : rău , protocoale în care doar telefonul a fost autentificat la turn (adică un atacator ar putea uzurpa identitatea turnului, generând ) și așa mai departe. LTE a corectat multe dintre erorile evidente, menținând în același timp o mare parte din aceeași structură.
Să începem cu criptarea în sine. Presupunând că crearea cheii a avut loc deja - și vom vorbi despre asta într-un minut - atunci fiecare pachet de date este criptat folosind criptarea fluxului folosind ceva numit „EEA” (care în practică poate fi implementat folosind lucruri precum AES ). În esență, mecanismul de criptare este aici ca mai jos:
Algoritmul principal de criptare pentru pachetele VoLTE (sursa: ). EEA este un cifr, „COUNT” este un contor de 32 de biți, „BEARER” este un identificator unic de sesiune care separă conexiunile VoLTE de traficul obișnuit de internet. „DIRECTION” indică în ce direcție circulă traficul - de la UE către turn sau invers.
Deoarece algoritmul de criptare în sine (EEA) poate fi implementat folosind un cifr puternic precum AES, este puțin probabil să existe vreun atac direct asupra cifrului în sine, ca acesta. . Cu toate acestea, este clar că, chiar și cu un cifru puternic, această schemă de criptare este o modalitate excelentă de a te împușca în picior.
În special: standardul LTE folosește un cifr de flux (neautentificat) cu un mod care va fi extrem de vulnerabil dacă contorul - și alte intrări precum "purtător" și "direcție" - sunt vreodată reutilizate. În limbajul modern, termenul pentru acest concept este „atac fără reutilizare”, dar riscurile potențiale aici nu sunt ceva modern. Sunt celebri și străvechi, datând din vremea glam metalului și chiar a discoteca.
Atacurile la reutilizarea nonce în modul CTR au existat chiar și atunci când Poison a devenit cunoscut
Pentru a fi corect, standardele LTE spun: „Vă rugăm să nu reutilizați aceste contoare”. Dar standardele LTE au o lungime de aproximativ 7000 de pagini și, în orice caz, este ca și cum i-ar cere copiilor să nu se joace cu pistolul. Se vor întâmpla în mod inevitabil și se vor întâmpla lucruri groaznice. Arma de tragere în acest caz este un atac de reutilizare a fluxului de cheie, în care două mesaje confidențiale diferite XOR aceiași octeți de flux de cheie. Se stie ca aceasta .
Ce este ReVoLTE?
Atacul ReVoLTE demonstrează că, în practică, acest design de criptare foarte vulnerabil este folosit greșit de hardware-ul din lumea reală. Mai exact, autorii analizează apelurile VoLTE reale efectuate folosind echipamente comerciale și arată că pot folosi ceva numit „atac de reinstalare a cheilor”. (Mult credit pentru găsirea acestei probleme îi revine (Raza & Lu), care au fost primii care au subliniat potențiala vulnerabilitate. Dar cercetarea ReVoLTE îl transformă într-un atac practic).
Permiteți-mi să vă arăt pe scurt esența atacului, deși ar trebui să vă uitați și .
S-ar putea presupune că odată ce LTE stabilește o conexiune de pachete de date, sarcina de voce prin LTE devine doar o chestiune de direcționare a pachetelor de voce prin acea conexiune împreună cu tot restul traficului. Cu alte cuvinte, VoLTE va fi un concept care există doar peste [Modele OSI – aproximativ]. Acest lucru nu este în întregime adevărat.
De fapt, stratul de legătură LTE introduce conceptul de „purtător”. Purtătorii sunt identificatori de sesiune separați care separă diferite tipuri de trafic de pachete. Traficul obișnuit de internet (Twitter-ul și Snapchat) trece printr-un singur purtător. Semnalizarea SIP pentru VoIP trece printr-un altul, iar pachetele de trafic vocal sunt procesate printr-un al treilea. Nu cunosc prea multe informații despre mecanismele de rutare a rețelei și radio LTE, dar cred că se procedează astfel, deoarece rețelele LTE doresc să impună mecanisme QoS (calitatea serviciului), astfel încât fluxurile de pachete diferite să fie procesate la diferite niveluri de prioritate: de ex. a ta de mâna a doua Conexiunile TCP la Facebook pot avea o prioritate mai mică decât apelurile dvs. vocale în timp real.
În general, aceasta nu este o problemă, dar consecințele sunt următoarele. Cheile pentru criptarea LTE sunt create separat de fiecare dată când este instalat un nou „purtător”. Practic, acest lucru ar trebui să se întâmple din nou de fiecare dată când efectuați un nou apel telefonic. Acest lucru va duce la utilizarea unei chei de criptare diferite pentru fiecare apel, eliminând posibilitatea de a reutiliza aceeași cheie pentru a cripta două seturi diferite de pachete de apeluri vocale. Într-adevăr, standardul LTE spune ceva de genul „ar trebui să utilizați o cheie diferită de fiecare dată când instalați un purtător nou pentru a gestiona un nou apel telefonic”. Dar asta nu înseamnă că acest lucru se întâmplă cu adevărat.
De fapt, în implementările din viața reală, două apeluri diferite care apar în proximitate temporală vor folosi aceeași cheie - în ciuda faptului că noi purtători cu același nume sunt configurați între ei. Singura modificare practică care are loc între aceste apeluri este că contorul de criptare este resetat la zero. În literatură, aceasta este uneori numită . S-ar putea argumenta că aceasta este în esență o eroare de implementare, deși în acest caz riscurile par să provină în mare parte din standardul însuși.
În practică, acest atac are ca rezultat reutilizarea fluxului de chei, unde atacatorul poate obține pachetele criptate $inline$C_1 = M_1 oplus KS$inline$ și $inline$C_2 = M_2 oplus KS$inline$, permițând calculul $inline$ C_1 oplus C_2 = M_1 oplus M_2$inline$. Și mai bine, dacă atacatorul cunoaște unul dintre $inline$M_1$inline$ sau $inline$M_2$inline$, atunci îl poate recupera imediat pe celălalt. Acest lucru îi oferă un stimulent puternic aflați una dintre cele două componente necriptate.
Acest lucru ne duce la scenariul de atac complet și cel mai eficient. Luați în considerare un atacator care poate intercepta traficul radio între un telefon țintă și un turn mobil și care are cumva norocul să înregistreze două apeluri diferite, al doilea având loc imediat după primul. Acum imaginați-vă că ar putea ghici cumva conținutul necriptat al unuia dintre apeluri. Cu asa noroc atacatorul nostru poate decripta complet primul apel folosind un simplu XOR între cele două seturi de pachete.
Desigur, norocul nu are nimic de-a face cu asta. Deoarece telefoanele sunt concepute pentru a primi apeluri, un atacator care poate auzi primul apel va putea iniția un al doilea apel exact în momentul în care primul se încheie. Acest al doilea apel, dacă aceeași cheie de criptare este utilizată din nou cu contorul resetat la zero, va permite recuperarea datelor necriptate. Mai mult decât atât, deoarece atacatorul nostru controlează de fapt datele în timpul celui de-al doilea apel, el poate recupera conținutul primului apel - datorită multor implementate special Lucruri mărunte, jucând de partea lui.
Iată o imagine a planului general de atac preluat din :
Privire de ansamblu asupra atacurilor de la . Această schemă presupune că două apeluri diferite sunt efectuate folosind aceeași tastă. Atacatorul controlează snifferul pasiv (stânga sus), precum și un al doilea telefon, cu ajutorul căruia poate efectua un al doilea apel către telefonul victimei.
Deci atacul funcționează cu adevărat?
Pe de o parte, aceasta este într-adevăr întrebarea principală pentru articolul despre ReVoLTE. Toate ideile de mai sus sunt grozave în teorie, dar lasă o mulțime de întrebări. Ca:
- Este posibil (pentru cercetătorii academicieni) să intercepteze efectiv o conexiune VoLTE?
- Sistemele LTE reale reintroduc de fapt cheia?
- Puteți iniția un al doilea apel rapid și suficient de fiabil pentru ca telefonul și turnul să refolosească cheia?
- Chiar dacă sistemele reintroduce cheia, puteți cunoaște de fapt conținutul necriptat al celui de-al doilea apel - având în vedere că lucruri precum codec-urile și transcodarea pot schimba complet conținutul (bit cu bit) al celui de-al doilea apel, chiar dacă aveți acces la „biți " provenind de la telefonul tău de atac?
Munca ReVoLTE răspunde afirmativ la unele dintre aceste întrebări. Autorii folosesc un sniffer de flux radio reconfigurabil de software comercial numit pentru a intercepta un apel VoLTE din partea downlink. (Cred că doar să mă înțeleg cu software-ul și să ne facem o idee aproximativă despre cum funcționează acesta a luat luni de zile din viața studenților săraci absolvenți - ceea ce este tipic pentru acest tip de cercetare academică).
Cercetătorii au descoperit că pentru ca reutilizarea cheii să funcționeze, al doilea apel trebuia să aibă loc suficient de repede după ce primul s-a încheiat, dar nu prea repede - aproximativ zece secunde pentru operatorii cu care au experimentat. Din fericire, nu contează dacă utilizatorul răspunde la apel în acest interval de timp - „soneria”, adică. Conexiunea SIP în sine forțează operatorul să refolosească aceeași cheie.
Astfel, multe dintre cele mai proaste probleme gravitează în jurul problemei (4) - primirea de biți din conținutul necriptat al unui apel inițiat de un atacator. Acest lucru se datorează faptului că se pot întâmpla multe cu conținutul dvs., pe măsură ce se deplasează de la telefonul atacatorului la telefonul victimei prin rețeaua celulară. De exemplu, astfel de trucuri murdare precum re-codificarea unui flux audio codificat, care lasă sunetul la fel, dar îi schimbă complet reprezentarea binară. Rețelele LTE utilizează, de asemenea, compresia antetului RTP, care poate schimba semnificativ o mare parte din pachetul RTP.
În cele din urmă, pachetele trimise de atacator ar trebui să fie aproximativ în concordanță cu pachetele trimise în timpul primului apel telefonic. Acest lucru poate fi problematic deoarece modificarea tăcerii în timpul unui apel telefonic are ca rezultat mesaje mai scurte (aka zgomot de confort) care s-ar putea să nu se potrivească bine cu apelul inițial.
Merită citit în detaliu. Acesta abordează multe dintre problemele de mai sus - în special, autorii au descoperit că unele codecuri nu sunt recodificate și că aproximativ 89% din reprezentarea binară a apelului țintă poate fi recuperată. Acest lucru este valabil pentru cel puțin doi operatori europeni care au fost testați.
Aceasta este o rată de succes surprinzător de mare și, sincer, mult mai mare decât mă așteptam când am început să lucrez la acest document.
Deci, ce putem face pentru a o remedia?
Răspunsul imediat la această întrebare este foarte simplu: deoarece esența vulnerabilității este un atac de reutilizare (reinstalare) cheie, pur și simplu remediați problema. Asigurați-vă că este obținută o cheie nouă pentru fiecare apel telefonic și nu permiteți niciodată contorului de pachete să reseta contorul la zero folosind aceeași cheie. Problema rezolvata!
Sau poate nu. Acest lucru va necesita modernizarea multor echipamente și, sincer vorbind, o astfel de remediere în sine nu este foarte fiabilă. Ar fi bine dacă standardele ar putea găsi o modalitate mai sigură de a-și implementa modurile de criptare care să nu fie implicit vulnerabilă catastrofal la astfel de probleme de reutilizare a cheilor.
O opțiune posibilă este utilizarea . Acest lucru poate fi prea scump pentru unele hardware-uri actuale, dar este cu siguranță o zonă la care designerii ar trebui să se gândească în viitor, mai ales că standardele 5G sunt pe cale să cuprindă lumea.
Acest nou studiu ridică și întrebarea generală de ce , dintre care multe folosesc modele și protocoale foarte similare. Când vă confruntați cu problema reinstalării aceleiași chei pe mai multe protocoale utilizate pe scară largă precum WPA2, nu credeți că ar fi timpul să vă faceți specificațiile și procedurile de testare mai robuste? Nu mai tratați implementatorii standardelor ca pe niște parteneri atenți, atenți la avertismentele dvs. Tratează-i ca niște adversari (neintenționați) care inevitabil vor greși lucrurile.
Sau, alternativ, putem face ceea ce fac din ce în ce mai multe companii precum Facebook și Apple: facem ca criptarea apelurilor vocale să se întâmple la un nivel superior al stivei de rețea OSI, fără a ne baza pe producătorii de echipamente celulare. Am putea chiar să insistăm pentru criptarea end-to-end a apelurilor vocale, așa cum face WhatsApp cu Signal și FaceTime, presupunând că guvernul SUA se oprește. . Apoi (cu excepția unor metadate) multe dintre aceste probleme ar dispărea pur și simplu. Această soluție este deosebit de relevantă într-o lume în care .
Sau pur și simplu putem face ceea ce copiii noștri au făcut deja: nu mai răspundem la acele apeluri vocale enervante.
Sursa: www.habr.com