De la translator și TL;DR
TL;DR:
Se pare că VoLTE a fost compromis și mai rău decât primele clienți Wi-Fi cu WEP. O eroare de arhitectură care permite XOR-ing-ul traficului și recuperarea cheii. Atacul este posibil dacă ești aproape de celui care sună și acesta face apeluri frecvent.
Mulțumesc pentru informație și TL;DR
Cercetătorii au realizat o aplicație pentru a determina dacă operatorul tău este vulnerabil, mai multe informații . Împărtășiți în comentarii rezultatele, în regiunea mea VoLTE este dezactivat la MegaFon.
Despre autor
Matthew Green.
Sunt criptograf și profesor la Universitatea Johns Hopkins. Am dezvoltat și analizat sisteme criptografice folosite în rețelele wireless, sistemele de plată și platformele de protecție a conținutului digital. În cercetările mele, explorez diverse moduri de utilizare a criptografiei pentru a spori confidențialitatea utilizatorilor.
A trecut ceva timp de când nu am scris un post de tip , și acest lucru m-a întristat. Nu pentru că nu au fost atacuri, ci mai ales pentru că nu a existat un atac asupra unei ceva suficient de folosit pentru a mă scoate din criza creativă.
Dar astăzi am dat peste numit ReVoLTE, asupra protocoalelor a căror compromitere mă bucură în mod special, și anume, protocoalele de rețea celulară (voice over) LTE. Sunt fascinat de aceste protocoale – și de acest nou atac – pentru că este foarte rar să observăm compromiterea protocoalelor și implementărilor reale ale rețelelor mobile. În principal pentru că aceste standarde sunt dezvoltate în camere umede și documentate în documente de 12000 de pagini, care nu sunt accesibile oricărui cercetător. Mai mult, implementarea acestor atacuri îi obligă pe cercetători să folosească protocoale radio complexe.
Astfel, vulnerabilitățile criptografice grave pot fi răspândite în întreaga lume și ar putea fi folosite doar de guverne, înainte ca vreun cercetător să le observe. Dar din când în când apar excepții, iar atacul de astăzi este unul dintre ele.
Autori : David Rupprecht, Katharina Kohls, Thorsten Holz și Christina Pöpper de la Universitatea Ruhr din Bochum și Universitatea New York din Abu Dhabi. Aceasta este o atacare excelentă a reîncărcării cheii în protocolul vocal, pe care probabil că îl utilizați deja (presupunând că faceți parte din generația mai în vârstă care încă mai efectuează apeluri telefonice cu telefonul mobil).
Pentru început – un scurt excurs istoric.
Ce este LTE și VoLTE?
Baza standardelor moderne de telefonie mobilă a fost pusă în Europa încă din anii '80 prin standardul ( Sistem global de comunicații mobile). GSM a fost primul standard major de telefonie mobilă digitală, care a introdus o serie de funcții revoluționare, de exemplu, utilizarea pentru protecția apelurilor telefonice. GSM-ul timpuriu a fost dezvoltat în principal pentru comunicații vocale, deși pentru o taxă se putea .
Pe măsură ce importanța transmiterii datelor în telecomunicații a crescut, au fost dezvoltate standarde Long Term Evolution (LTE) pentru a raționaliza acest tip de comunicație. LTE se bazează pe un grup de standarde mai vechi, precum GSM, și și este destinat creșterii vitezei de transfer de date. În acest domeniu, există mult branding și dar TL;DR este că LTE este un sistem de transmitere a datelor care servește ca un pod între protocoalele de transmisie de date mai vechi și viitoarele tehnologii de transmisie mobilă. .
Desigur, istoria ne spune că, odată ce există suficient lățime de bandă (IP), conceptele precum «voce» și «date» vor începe să se estompeze. Același lucru este valabil și pentru protocoalele mobile moderne. Pentru a face această tranziție mai fluidă, standardele LTE definesc (VoLTE), care este un standard IP pentru transmiterea apelurilor vocale direct prin planul de transfer de date al sistemului LTE, ocolind complet partea comutată a rețelei mobile. Ca în cazul apelurilor standard apelurile VoLTE pot fi terminate de operatorul de telefonie mobilă și conectate la rețeaua telefonică obișnuită. Sau (ceea ce devine din ce în ce mai comun) acestea directly from one cellular client to another, and even between different providers.
Like standard VoIP, VoLTE is based on two popular IP-based protocols: the Session Initiation Protocol ( ) for call setup, and the Real Time Transport Protocol (, which should be called RTTP but is actually referred to as RTP) for handling voice data. VoLTE also adds some additional bandwidth optimizations, such as header compression.
Okay, what does this have to do with encryption?
LTE, like , has a standard set of cryptographic protocols for encrypting packets during their transmission over the air. These are primarily intended to protect your data while it's moving between the phone (referred to as "user equipment," or UE) and the cell tower (or wherever your provider decides to terminate the connection). This is because cellular providers view external eavesdropping devices as threats. Well, of course.
(However, the fact that VoLTE connections can occur directly between clients in different provider networks means that the VoLTE protocol itself has some additional optional encryption protocols that can occur at higher network levels. This is not related to the current article, except for the fact that they can mess everything up. We will briefly discuss them later).
Historically, encryption in GSM had : weak , protocols where only the phone was authenticated at the tower (meaning an attacker could impersonate the tower, generating a ) and so on. LTE fixed many of the obvious mistakes, while still retaining much of the previous structure.
Let's start with the encryption itself. Assuming that key creation has already occurred — and we will talk about this in a minute — each data packet is encrypted using stream mode encryption with some cipher called "EEA" (which can practically be implemented using things like AES). Essentially, the encryption mechanism here is , as shown below:
Algoritmul principal de criptare a pachetelor VoLTE (sursa: ). EEA – criptare, „COUNT” – un contor de 32 de biți, „BEARER” — un identificator unic de sesiune, care separă conexiunile VoLTE de traficul obișnuit de internet. „DIRECTION” indică în ce direcție se desfășoară traficul – de la UE către turn sau viceversa.
Deoarece algoritmul de criptare (EEA) poate fi implementat folosind un algoritm puternic de tip AES, este puțin probabil să existe o atac direct asupra criptării în sine, așa cum . Cu toate acestea, este evident că, chiar și cu o criptare puternică, această schemă de criptare reprezintă un excelent mod de a-ți trasa singur un șut în picior.
În mod special: standardul LTE folosește un șir de criptare (neautentificat) cu un mod care va fi extrem de vulnerabil dacă contorul – și alte intrări, precum „bearer” și „direction” – vor fi utilizate vreodată din nou. În limbajul modern, termenul pentru acest concept este „atac prin reutilizarea nonce”, dar riscurile potențiale nu sunt ceva nou. Ele sunt bine cunoscute și vechi, care datează din epoca glam metalului și chiar disco.
Atacurile prin reutilizarea nonce în modul CTR existau încă din vremea în care Poison a devenit cunoscut
Pentru a fi corect, standardele LTE afirmă: „Nu reutilizați aceste contoare, vă rugăm”. Dar standardele LTE au aproximativ 7000 de pagini, iar în orice caz, este la fel cu a ruga copiii să nu se joace cu o armă. Ei vor face acest lucru inevitabil, iar lucruri îngrozitoare se vor întâmpla. În acest caz, arma descărcată este un atac prin reutilizarea fluxului cheie, în care două mesaje confidențiale diferite sunt XOR-ate cu aceleași biți ai fluxului cheie. Se știe că aceasta .
Ce este ReVoLTE?
Atacul ReVoLTE demonstrează că, în practică, această construcție de criptare foarte vulnerabilă este utilizată incorect de echipamentele reale. În special, autorii analizează apeluri VoLTE reale efectuate cu echipamente comerciale și arată că pot folosi ceva numit „atacul prin reinstalarea cheii”. (O mare parte din meritul pentru identificarea acestei probleme îi revine (Raza & Lu), care au fost primii care au indicat o potențială vulnerabilitate. Însă studiile ReVoLTE o transformă într-un atac practic).
Permiteți-mi să vă arăt pe scurt esența atacului, deși ar trebui să verificați și .
Se poate presupune că odată ce LTE stabilește o conexiune de transmitere a datelor, sarcina de a transmite voce prin LTE devine doar o chestiune de rutare a pachetelor vocale prin această conexiune împreună cu tot traficul dumneavoastră. Cu alte cuvinte, VoLTE va fi un concept care există doar deasupra [modelul OSI – ex. per.]. Asta nu este complet corect.
De fapt, nivelul de legătură LTE introduce conceptul de „bearer”. Bearer este un identificator separat de sesiune, care împarte diferitele tipuri de trafic de pachete. Traficul obișnuit de internet (Twitter-ul și Snapchat-ul dumneavoastră) trece printr-un bearer. Semnalizarea SIP pentru VoIP merge printr-un altul, iar pachetele de trafic vocal sunt procesate pe un al treilea. Nu mă pricep foarte bine la mecanismele de canal radio și la rutarea rețelei LTE, dar presupun că este făcut astfel pentru că rețelele LTE doresc să asigure funcționarea mecanismelor QoS (calitatea serviciului), astfel încât diferitele fluxuri de pachete să fie procesate cu niveluri diferite de prioritate: adică, conexiunile secundare TCP cu Facebook ar putea avea o prioritate mai mică decât apelurile dumneavoastră vocale în timp real.
Aceasta nu este în general o problemă, dar consecințele sunt următoarele. Cheile de criptare LTE sunt generate separat de fiecare dată când se stabilește un nou „bearer”. În principiu, aceasta ar trebui să se întâmple din nou de fiecare dată când efectuați un nou apel telefonic. Aceasta va duce la utilizarea unei chei de criptare diferite pentru fiecare apel, ceea ce exclude posibilitatea reutilizării aceleași chei pentru a cripta două seturi diferite de pachete de apeluri vocale. De fapt, standardul LTE afirmă ceva de genul „trebuie să folosiți chei diferite de fiecare dată când stabiliți un nou bearer pentru a gestiona un nou apel telefonic”. Dar asta nu înseamnă că se întâmplă așa în realitate.
În realitate, în implementările reale, două apeluri diferite care au loc în apropierea temporală vor folosi aceeași cheie — deși între ele se configurează noi bearer (cu același nume). Singura modificare practică care are loc între aceste apeluri este că contorul de criptare se resetează la zero. În literatura de specialitate, acest lucru este uneori numit . Se poate susține că, în esență, aceasta este o eroare de implementare, deși, în acest caz, riscurile par a decurge în mare măsură din standardul în sine.
În practică, acest atac conduce la reutilizarea fluxului de cheie, unde un atacator poate obține pachete criptate $inline$C_1 = M_1 oplus KS$inline$ și $inline$C_2 = M_2 oplus KS$inline$, ceea ce permite calcularea $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. Mai bine, dacă atacatorul știe unul dintre $inline$M_1$inline$ sau $inline$M_2$inline$, atunci el poate recupera imediat cealaltă. Acest lucru îi oferă un stimulent puternic de a afla unul dintre cele două componente necriptate.
Acest lucru ne conduce la scenariul complet și cel mai eficient de atac. Să luăm în considerare un atacator care poate intercepta traficul radio între telefonul țintă și turnul mobil, și care, printr-un mod ingenios, a reușit să înregistreze două apeluri diferite, unde al doilea are loc imediat după primul. Acum imaginați-vă că el poate ghici conținutul necriptat al unuia dintre apeluri. În cazul unei întâmplări fericite 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 aici. Deoarece telefoanele sunt destinate să primească apeluri, un atacator care poate asculta primul apel va putea iniția și al doilea apel exact în momentul în care se termină primul. Acest al doilea apel, în cazul reutilizării aceleași chei de criptare cu contorul resetat la zero, va permite recuperarea datelor necriptate. Mai mult, deoarece atacatorul nostru controlează efectiv datele în timpul celui de-al doilea apel, el poate recupera conținutul primului apel – datorită multor detalii specifice implementate care joacă în favoarea sa.Iată o imagine a planului general de atac, preluată din
Aceasta este o imagine de ansamblu a planului de atac, preluată din :
Revizuirea atacului din . Acest schemă presupune că au loc două apeluri diferite folosind aceeași cheie. Atacatorul controlează un sniffer pasiv (în colțul din stânga sus) și un al doilea telefon, cu ajutorul căruia poate face un al doilea apel către telefonul victimei.
Așadar, atacul chiar funcționează?
Pe de o parte, aceasta este cu adevărat întrebarea principală pentru articolul despre ReVoLTE. Teoretic, toate ideile menționate mai sus sunt excelente, dar lasă multe întrebări. De exemplu:
- Este posibil (pentru cercetătorii academici) să intercepteze cu adevărat o conexiune VoLTE?
- Oare sistemele reale LTE reînnoiesc cu adevărat cheile?
- Puteți de fapt să inițiați un al doilea apel destul de repede și fiabil, astfel încât telefonul și turnul să reutilizeze cheia?
- Chiar dacă sistemele reînnoiesc cheile, puteți cu adevărat să aflați conținutul necriptat al celui de-al doilea apel – având în vedere că lucruri precum codec-urile și recodificarea pot schimba complet (bit cu bit) conținutul acestui al doilea apel, chiar dacă aveți acces la "bitele" care provin de la telefonul dumneavoastră atacator?
La unele dintre aceste întrebări, munca ReVoLTE răspunde afirmativ. Autorii folosesc un sniffer de flux radio pentru configurare comercială numit pentru a intercepta apelul VoLTE din partea descendentă. (Cred că stăpânirea simplă a software-ului și înțelegerea aproximativă a modului în care funcționează a reprezentat luni întregi din viața studiilor postuniversitare - ceea ce este tipic pentru astfel de cercetări academice).
Cercetătorii au descoperit că pentru reactivarea reutilizării cheii, al doilea apel trebuie să aibă loc suficient de repede după finalizarea primului, 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 – "apelul", adică comunicarea SIP în sine forțează operatorul să reutilizeze aceeași cheie.
Astfel, multe dintre cele mai grave probleme se învârt în jurul problemei (4) – obținerea biților conținutului necriptat al apelului inițiat de atacator. Acest lucru se întâmplă deoarece conținutul tău poate suferi multe modificări pe măsură ce trece de la telefonul atacatorului la telefonul victimei prin rețeaua de telefonie mobilă. De exemplu, neplăcerile, cum ar fi recodificarea fluxului audio criptat, care lasă sunetul intact, dar îi modifică complet reprezentarea binară. În rețelele LTE se folosește, de asemenea, comprimarea antetelor RTP, care poate altera în mod semnificativ o mare parte din pachetul RTP.
În cele din urmă, pachetele trimise de atacator trebuie să se alinieze aproximativ cu pachetele trimise în timpul primului apel telefonic. Acest lucru poate fi problematic, deoarece modificarea tăcerii în timpul apelului telefonic duce la mesaje mai scurte (numit zgomot de confort), care pot să nu se potrivească bine cu apelul inițial.
merită citită în detaliu. Aceasta discută multe dintre problemele menționate anterior – în special, autorii au descoperit că unelecodecuri nu au fost recodificate și că aproximativ 89% din reprezentarea binară a apelului țintă poate fi recuperată. Acest lucru este relevant pentru cel puțin doi operatori europeni care au fost testați.
Este un nivel de succes extrem de ridicat și, sincer, mult mai ridicat decât mă așteptam atunci când am început lucrul la acest document.
Așadar, ce putem face pentru a rezolva?
Răspunsul imediat la această întrebare este extrem de simplu: deoarece esența vulnerabilității este atacul de reutilizare (reininstalare) a cheii, pur și simplu remediați această problemă. Asigurați-vă că pentru fiecare apel telefonic se obține o nouă cheie și nu permiteți niciodată contorului de pachete să reseteze contorul la zero cu aceeași cheie. Problema este rezolvată!
Poate că nu. Acest lucru ar necesita modernizarea unei cantități mari de echipamente și, sincer, o astfel de soluție nu este super sigură. Ar fi bine dacă standardele ar putea găsi o modalitate mai sigură de implementare a modurilor lor de criptare, care să nu fie în mod prestabilit catastrofal vulnerabilă la probleme de reutilizare a cheilor.
Una dintre opțiunile posibile este utilizarea . Acest lucru poate fi prea costisitor pentru unele echipamente moderne, dar este, fără îndoială, o direcție la care proiectanții ar trebui să se gândească în viitor, mai ales având în vedere că standardele 5G urmează să cucerească lumea.
Această nouă cercetare ridică, de asemenea, întrebarea generală de ce , multe dintre acestea utilizând construcții și protocoale foarte asemănătoare. Când te confrunți cu problema reinstalării aceleași chei în mai multe protocoale tot mai răspândite, cum ar fi WPA2, nu crezi că poate a sosit vremea să faci specificațiile și procedurile tale de testare mai fiabile? E suficient să tratezi implementatorii standardelor ca pe parteneri atenți la avertizările tale. Tratează-i ca pe (neintenționații) adversari care inevitabil vor implementa totul greșit.
Sau, ca alternativă, putem face ceea ce fac din ce în ce mai des companii precum Facebook și Apple: să facem ca criptarea apelurilor vocale să aibă loc la un nivel mai înalt al stivei de rețea OSI, fără a ne baza pe producătorii de echipamente mobile. Putem chiar promova criptarea end-to-end a apelurilor vocale, așa cum fac WhatsApp cu Signal și FaceTime, presupunând că guvernul SUA pur și simplu va înceta . Atunci (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 putem pur și simplu să facem ceea ce au făcut deja copiii noștri: să nu mai răspundem la aceste apeluri vocale enervante.
Sursa: habr.com
