Dal traduttore e TL;DR
TL;DR:
Sembra che VoLTE sia stato compromesso ancora peggio rispetto ai primi client Wi-Fi con WEP. Una pura svista architettonica che consente di fare un po' di XOR sul traffico e recuperare la chiave. L'attacco è possibile se ci si trova vicino a chi sta facendo una chiamata e questa persona effettua chiamate frequenti.
Grazie per la segnalazione e TL;DR
I ricercatori hanno sviluppato un'applicazione per determinare se il tuo operatore è vulnerabile, maggiori dettagli . Condividi nei commenti i risultati, nella mia zona VoLTE è disattivato su MegaFon.
All'autore
Matthew Green.
Sono un crittografo e professore all'Università Johns Hopkins. Ho progettato e analizzato sistemi crittografici utilizzati nelle reti wireless, nei sistemi di pagamento e nelle piattaforme di protezione dei contenuti digitali. Nelle mie ricerche esamino vari modi di utilizzare la crittografia per aumentare il livello di privacy degli utenti.
È da un po' che non scrivo un post del formato , e questo mi dispiace. Non perché non ci siano stati attacchi, ma principalmente perché non c'è stato un attacco a qualcosa di abbastanza ampliamente utilizzato da tirarmi fuori dalla crisi creativa.
Ma oggi mi sono imbattuto in chiamato ReVoLTE su protocolli, la cui compromissione mi rende particolarmente felice, cioè, i protocolli delle reti cellulari (voice over) LTE. Sono entusiasta di questi protocolli e di questo nuovo attacco perché è molto raro osservare il compromesso di protocolli reali e implementazioni delle reti cellulari. Principalmente perché questi standard sono stati sviluppati in stanze piene di fumo e redatti in documenti di 12000 pagine, che non ogni ricercatore è in grado di comprendere. Inoltre, l'implementazione di questi attacchi costringe i ricercatori a utilizzare protocolli radio complessi.
Pertanto, gravi vulnerabilità crittografiche possono diffondersi in tutto il mondo e potrebbero essere utilizzate solo dai governi, prima che qualche ricercatore presti loro attenzione. Ma di tanto in tanto ci sono eccezioni, e l'attacco di oggi è una di esse.
Autori : David Rupprecht, Katharina Kohls, Thorsten Holz e Christina Pöpper dell'Università della Ruhr di Bochum e dell'Università di New York ad Abu Dhabi. Questo è un'ottima critica alla reinstallazione della chiave nel protocollo vocale che probabilmente già utilizzate (se si presume che apparteniate alla generazione più anziana che effettua ancora chiamate telefoniche tramite cellulare).
Per cominciare – una breve escursione storica.
Che cos'è LTE e VoLTE?
Le basi dei nostri moderni standard di telefonia mobile sono state gettate in Europa negli anni '80 con lo standard (Sistema Globale di Comunicazione Mobile). Il GSM è stato il primo standard principale per la telefonia mobile digitale, che ha introdotto una serie di funzioni rivoluzionarie, come l'uso di per proteggere le chiamate telefoniche. Il primo GSM è stato progettato principalmente per la comunicazione vocale, sebbene fosse possibile .
Con l'aumento dell'importanza della trasmissione di dati nelle comunicazioni mobili, sono stati sviluppati gli standard Long Term Evolution (LTE) per razionalizzare questo tipo di connessione. L'LTE si basa su un insieme di standard più vecchi, come GSM, e ed è destinato a migliorare la velocità dello scambio di dati. In questo campo c'è molta branding e , ma TL;DR consiste nel fatto che LTE è un sistema di trasmissione dati che funge da ponte tra i vecchi protocolli di trasmissione dati e le future tecnologie di trasmissione cellulare. .
Naturalmente, la storia ci dice che, non appena ci sarà sufficiente larghezza di banda (IP), concetti come «voce» e «dati» inizieranno a sfumarsi. Lo stesso vale per i protocolli cellulari moderni. Per rendere questa transizione più fluida, gli standard LTE definiscono (VoLTE), che è uno standard IP per la trasmissione di chiamate vocali direttamente attraverso il piano di trasmissione dati del sistema LTE, bypassando completamente la parte commutata della rete cellulare. Come nel caso delle le chiamate VoLTE possono essere terminate dall'operatore di telefonia mobile e collegate alla normale rete telefonica. Oppure (cosa sempre più comune) possono direttamente da un cliente cellulare all'altro, e persino tra diversi fornitori.
Come la VoIP standard, VoLTE si basa su due protocolli IP popolari: il protocollo di inizio sessione ( – SIP) per stabilire la chiamata e il protocollo di trasporto in tempo reale (, che dovrebbe essere chiamato RTTP, ma in realtà si chiama RTP) per la gestione dei dati vocali. VoLTE aggiunge anche alcune ulteriori ottimizzazioni della larghezza di banda, come la compressione degli header.
Bene, che relazione ha questo con la crittografia?
LTE, proprio come , ha un set standard di protocolli crittografici per crittografare i pacchetti durante la loro trasmissione attraverso l'aria. Sono principalmente progettati per proteggere i tuoi dati mentre si spostano tra il telefono (chiamato 'equipment utente', o UE) e la torre cellulare (o ovunque il tuo fornitore decida di terminare la connessione). Ciò avviene perché i fornitori di servizi cellulari considerano i dispositivi esterni di ascolto come nemici. Ovviamente.
(Tuttavia, il fatto che le connessioni VoLTE possano avvenire direttamente tra clienti in diverse reti di fornitori significa che il protocollo VoLTE stesso ha alcuni protocolli di crittografia aggiuntivi e opzionali che possono avvenire a livelli di rete più elevati. Questo non si riferisce all'articolo attuale, se non per il fatto che possono rovinare tutto. Ne parleremo brevemente più avanti).
Storicamente, la crittografia in GSM ha avuto : scarsi , protocolli in cui solo il telefono si autenticava sulla torre (questo significa che un malintenzionato poteva spacciarsi per la torre, creando ) e così via. LTE ha corretto molti degli errori evidenti, mantenendo comunque gran parte della struttura precedente.
Iniziamo con la crittografia stessa. Se si presume che la generazione della chiave sia già avvenuta - e ne parleremo tra un momento - ogni pacchetto di dati viene crittografato utilizzando un metodo di crittografia in modalità stream con un certo algoritmo chiamato 'EEA' (che nella pratica può essere realizzato con cose come AES). Fondamentalmente, qui il meccanismo di crittografia è , come mostrato di seguito:
L'algoritmo principale di crittografia dei pacchetti VoLTE (fonte: ). EEA – cifrario, «COUNT» – contatore a 32 bit, «BEARER» – identificatore unico della sessione che separa le connessioni VoLTE dal traffico internet normale. «DIRECTION» indica in quale direzione si muove il traffico – dall'UE alla torre o viceversa.
Poiché l'algoritmo di crittografia stesso (EEA) può essere implementato utilizzando un cifrario forte tipo AES, è poco probabile che ci sia un attacco diretto al cifrario stesso, come avveniva Tuttavia, è chiaro che anche con un cifrario forte, questo schema di crittografia rappresenta un ottimo modo per colpirsi la propria gamba.
In particolare: nel standard LTE viene utilizzato un cifrario a flusso (non autenticato) con modalità, che sarà estremamente vulnerabile se il contatore e altri ingressi come «bearer» e «direction» verranno riutilizzati. Nel linguaggio moderno, il termine per questo concetto è "attacco di riutilizzo del nonce", ma i rischi potenziali qui non sono nulla di nuovo. Sono conosciuti e antichi, risalenti ai tempi del glam metal e persino della disco.
Gli attacchi al riutilizzo del nonce nella modalità CTR esistevano già quando i Poison divennero famosi.
A dire il vero, negli standard LTE è scritto: "Non riutilizzate questi contatori, per favore". Ma gli standard LTE occupano circa 7000 pagine, e in ogni caso, è come pregare i bambini di non giocare con una pistola. Inevitabilmente lo faranno, e succederanno cose terribili. In questo caso, la pistola che spara è l'attacco di riutilizzo del flusso di chiavi, dove due messaggi confidenziali diversi vengono XORati con gli stessi byte del flusso di chiavi. È noto che questo .
Che cos'è ReVoLTE?
L'attacco ReVoLTE dimostra che nella pratica questa struttura di crittografia molto vulnerabile è utilizzata in modo errato dall'hardware reale. In particolare, gli autori analizzano vere chiamate VoLTE effettuate utilizzando attrezzature commerciali e mostrano che possono utilizzare qualcosa chiamato "attacco di reinstallazione della chiave". (Un grande merito per la scoperta di questo problema va a (Raza & Lu), che per primi hanno evidenziato una potenziale vulnerabilità. Ma le ricerche di ReVoLTE la trasformano in un attacco pratico).
Lasciate che vi mostri brevemente il significato dell'attacco, anche se dovreste dare un'occhiata anche al .
Si può supporre che non appena LTE stabilisce una connessione per il trasferimento di dati, il compito di trasferire voce su LTE diventi solo una questione di instradamento dei pacchetti vocali attraverso questa connessione insieme a tutto il resto del vostro traffico. In altre parole, VoLTE sarà un concetto che esiste solo sopra [modello OSI – esempio per.]. Non è proprio così.
In effetti, il livello di collegamento LTE introduce il concetto di «bearer». Un bearer è un identificatore di sessione separato che separa diversi tipi di traffico a pacchetto. Il traffico Internet normale (il vostro Twitter e Snapchat) passa attraverso un bearer. La segnalazione SIP per VoIP passa attraverso un altro, mentre i pacchetti di traffico vocale vengono gestiti su un terzo. Non sono molto esperto nei meccanismi dei canali radio e dell'instradamento della rete LTE, ma suppongo che sia fatto in questo modo perché le reti LTE vogliono garantire che i meccanismi di QoS (qualità del servizio) funzionino, in modo che diversi flussi di pacchetti vengano trattati con diversi livelli di priorità: ad esempio, le vostre connessioni TCP di seconda classe con Facebook potrebbero avere una priorità più bassa rispetto alle vostre chiamate vocali in tempo reale.
Questo in generale non è un problema, ma le conseguenze sono le seguenti. Le chiavi per la crittografia LTE vengono generate separatamente ogni volta che si stabilisce un nuovo «bearer». In linea di principio, questo dovrebbe accadere di nuovo ogni volta che effettuate una nuova chiamata telefonica. Questo porterà ad utilizzare una chiave di crittografia diversa per ogni chiamata, escludendo la possibilità di riutilizzare la stessa chiave per crittografare due diversi set di pacchetti di chiamate vocali. Infatti, lo standard LTE afferma qualcosa come «dovete utilizzare chiavi diverse ogni volta che stabilite un nuovo bearer per gestire una nuova chiamata telefonica». Ma questo non significa che accada effettivamente in questo modo.
In realtà, nelle implementazioni reali, due diverse chiamate che avvengono in stretta prossimità temporale utilizzeranno la stessa chiave, nonostante vengano configurati nuovi bearer (con lo stesso nome) tra di esse. L'unica modifica pratica che avviene tra queste chiamate è che il contatore di crittografia viene azzerato. In letteratura, questo viene talvolta chiamato . Si può sostenere che, in sostanza, si tratta di un errore di implementazione, anche se in questo caso i rischi sembrano derivare in gran parte dallo standard stesso.
In pratica, questo attacco porta alla riutilizzazione del flusso di chiavi, dove un attaccante può ottenere pacchetti crittografati $inline$C_1 = M_1 oplus KS$inline$ e $inline$C_2 = M_2 oplus KS$inline$, il che consente di calcolare $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. Ancora meglio, se l'attaccante conosce uno dei $inline$M_1$inline$ o $inline$M_2$inline$, può immediatamente recuperare l'altro. Questo gli fornisce un forte incentivo a scoprire uno dei due componenti non crittografati.
Questo ci porta a uno scenario di attacco completo e altamente efficace. Consideriamo un attaccante che può intercettare il traffico radio tra il telefono di destinazione e la cella, e che per qualche motivo astuto è riuscito a registrare due diverse telefonate, dove la seconda avviene immediatamente dopo la prima. Immaginate ora che riesca a indovinare il contenuto in chiaro di una delle chiamate. Con una tale fortuna casuale il nostro attaccante può completamente decifrare la prima chiamata utilizzando un semplice XOR tra due set di pacchetti.
Naturalmente, la fortuna non c'entra nulla. Poiché i telefoni sono progettati per ricevere chiamate, un attaccante che può spiare la prima chiamata sarà in grado di iniziare anche la seconda chiamata proprio nel momento in cui finisce la prima. Questa seconda chiamata, nel caso di riutilizzo della stessa chiave di crittografia con il contatore azzerato, permetterà di recuperare i dati non crittografati. Inoltre, poiché il nostro attaccante controlla effettivamente i dati durante la seconda chiamata, può recuperare il contenuto della prima chiamata grazie a una serie di dettagli specificamente implementati che giocano a suo favore.Ecco un'immagine del piano generale dell'attacco, tratta da
Ecco un'immagine del piano generale dell'attacco, tratta da :
Panoramica dell'attacco da . Questo schema presuppone che avvengano due chiamate diverse utilizzando la stessa chiave. L'attaccante controlla uno sniffatore passivo (in alto a sinistra), così come un secondo telefono attraverso il quale può effettuare una seconda chiamata al telefono della vittima.
Quindi, funziona davvero l'attacco?
Da un lato, questa è davvero la domanda principale per l'articolo su ReVoLTE. Teoricamente, tutte le idee sopra menzionate sono fantastiche, ma lasciano molte domande. Come ad esempio:
- È possibile (per i ricercatori accademici) intercettare realmente una connessione VoLTE?
- Le reali reti LTE rigenerano davvero le chiavi?
- Puoi effettivamente avviare una seconda chiamata in modo sufficientemente rapido e affidabile affinché il telefono e la torre riutilizzino la chiave?
- Anche se i sistemi rigenerano le chiavi, puoi effettivamente identificare il contenuto non cifrato della seconda chiamata, considerando che fattori come codec e ricodifica possono cambiare completamente il contenuto (a livello di bit) di quella seconda chiamata, anche se hai accesso ai "bit" provenienti dal tuo telefono attaccante?
A alcune di queste domande, il lavoro di ReVoLTE risponde affermativamente. Gli autori utilizzano uno sniffatore commerciale di flussi radio riconfigurabile chiamato per intercettare la chiamata VoLTE dal lato discendente. (Penso che appropriarsi semplicemente del software e avere una comprensione approssimativa di come funzioni abbia sottratto mesi di vita ai poveri dottorandi - il che è tipico di tali ricerche accademiche).
I ricercatori hanno scoperto che affinché il riutilizzo della chiave abbia effetto, la seconda chiamata deve avvenire abbastanza rapidamente dopo il completamento della prima, ma non troppo – circa dieci secondi per gli operatori con cui hanno sperimentato. Fortunatamente, non importa se l'utente risponde alla chiamata in quel intervallo – la "chiamata", ossia la connessione SIP stessa, costringe l'operatore a riutilizzare la stessa chiave.
Pertanto, molti dei problemi più gravi ruotano attorno al problema (4) – il recupero dei bit del contenuto della chiamata non crittografato, avviato da un attaccante. Questo accade perché il tuo contenuto può subire molteplici alterazioni mentre passa dal telefono dell'aggressore a quello della vittima attraverso la rete mobile. Ad esempio, ci sono attività come la ricodifica di uno stream audio codificato, che mantiene il suono invariato ma altera completamente la sua rappresentazione binaria. Nelle reti LTE viene inoltre utilizzata la compressione delle intestazioni RTP, che può modificare notevolmente gran parte del pacchetto RTP.
Infine, i pacchetti inviati dall'aggressore devono allinearsi più o meno ai pacchetti inviati durante la prima telefonata. Questo può essere problematico, poiché la modifica del silenzio durante una telefonata porta a messaggi più brevi (il cosiddetto rumore di comfort), che possono non combaciare bene con la chiamata originale.
vale la pena leggerlo in dettaglio. Esamina molti dei problemi sopra citati: in particolare, gli autori hanno scoperto che alcuni codec non sono ricodificati e che circa l'89% della rappresentazione binaria della chiamata target può essere recuperato. Ciò è rilevante almeno per due operatori europei che sono stati testati.
È un livello di successo sorprendentemente alto e, a dire il vero, molto più alto di quanto mi aspettassi quando ho iniziato a lavorare su questo documento.
Quindi, cosa possiamo fare per risolvere il problema?
La risposta urgente a questo problema è estremamente semplice: poiché la vulnerabilità consiste in un attacco alla riutilizzazione (reinstallazione) della chiave, è sufficiente correggere questo problema. Assicurati che venga generata una nuova chiave per ogni telefonata e non permettere mai al contatore dei pacchetti di resettarsi a zero utilizzando la stessa chiave. Problema risolto!
Forse no. Ci vorrebbe una modernizzazione di un grande quantitativo di attrezzature e, a dire il vero, un tale fissaggio non è super affidabile da solo. Sarebbe utile se gli standard potessero trovare un modo più sicuro di implementare i loro metodi di crittografia, che non sia di default catastroficamente vulnerabile a problemi di riutilizzo delle chiavi.
Una delle possibili soluzioni è l'uso di . Questo potrebbe essere troppo costoso per alcune moderne attrezzature, ma è sicuramente una direzione che i progettisti dovrebbero considerare in futuro, specialmente considerando che gli standard 5G stanno per dominare il mondo.
Questa nuova ricerca solleva anche la questione generale del perché , molti dei quali utilizzano strutture e protocolli molto simili. Quando ti trovi ad affrontare il problema del reinserimento della stessa chiave in diversi protocolli ampiamente diffusi come WPA2, non ti sembra che sia ora di rendere le tue specifiche e procedure di test più affidabili? Basta considerare gli implementatori di standard come partner riflessivi, attenti ai tuoi avvertimenti. Trattali come (involontari) avversari, che inevitabilmente si apprestano a implementare tutto in modo errato.
Oppure, come alternativa, possiamo fare ciò che aziende come Facebook e Apple stanno facendo sempre più spesso: fare in modo che la crittografia delle chiamate vocali avvenga a un livello più alto dello stack di rete OSI, senza fare affidamento sui produttori di attrezzature per la telefonia mobile. Possiamo anche promuovere la crittografia end-to-end delle chiamate vocali, come fa WhatsApp con Signal e FaceTime, assumendo che il governo degli Stati Uniti semplicemente smetta di . Allora (eccetto alcune metadata) molti di questi problemi semplicemente svanirebbero. Questa soluzione è particolarmente rilevante in un mondo in cui .
Oppure possiamo semplicemente fare ciò che hanno già fatto i nostri figli: smettere di rispondere a queste noiose chiamate vocali.
Fonte: habr.com
