Attacco della settimana: chiamate vocali su LTE (ReVoLTE)

Dal traduttore e TL;DR

1. TL; DR:

   Sembra che VoLTE si sia rivelato ancora peggio protetto dei primi client Wi-Fi con WEP. Un errore di calcolo esclusivamente architetturale che permette di XORizzare un po' il traffico e ripristinare la chiave. Un attacco è possibile se sei vicino al chiamante e lui chiama frequentemente.

2. Grazie per il suggerimento e TL; DR Klukonin

3. I ricercatori hanno creato un'app per determinare se il tuo operatore è vulnerabile, leggi di più qui. Condividi i risultati nei commenti, VoLTE è disabilitato nella mia regione su Megafon.

Chi l'Autore

Matteo Verde.

Sono un crittografo e professore alla Johns Hopkins University. Ho progettato e analizzato sistemi crittografici utilizzati nelle reti wireless, nei sistemi di pagamento e nelle piattaforme di sicurezza dei contenuti digitali. Nella mia ricerca, esamino diversi modi di utilizzare la crittografia per migliorare la privacy degli utenti.

È da un po' che non scrivo un formato di post "attacco della settimana", e mi ha sconvolto. Non perché non ci fossero attacchi, ma soprattutto perché non c'era un attacco a qualcosa di abbastanza diffuso da farmi uscire dal blocco dello scrittore.

Ma oggi mi sono imbattuto attacco interessante chiamato ReVoLTE per i protocolli che sono particolarmente entusiasta dell'hacking, vale a dire i protocolli LTE della rete cellulare (voce fuori campo). Sono entusiasta di questi particolari protocolli e di questo nuovo attacco perché è molto raro vedere i protocolli e le implementazioni della rete cellulare effettivamente violati. Principalmente perché questi standard sono stati sviluppati in stanze piene di fumo e documentati in documenti di 12000 pagine che non tutti i ricercatori sono in grado di gestire. Inoltre, l’implementazione di questi attacchi costringe i ricercatori a utilizzare protocolli radio complessi.

Pertanto, gravi vulnerabilità crittografiche potrebbero diffondersi in tutto il mondo, forse solo per essere sfruttate dai governi, prima che qualsiasi ricercatore se ne accorga. Ma di tanto in tanto ci sono delle eccezioni e l'attacco di oggi è una di queste.

Autori атакиCollaboratori: David Rupprecht, Katharina Kohls, Thorsten Holz e Christina Pöpper dell'Università della Ruhr di Bochum e dell'Università di New York Abu Dhabi. Questo è un ottimo attacco per reinstallare la chiave nel protocollo vocale che probabilmente stai già utilizzando (supponendo che tu appartenga a una generazione precedente che effettua ancora chiamate utilizzando un telefono cellulare).

Per cominciare, una breve escursione storica.

Cosa sono LTE e VoLTE?

La base dei nostri moderni standard di telefonia cellulare è stata posta in Europa già negli anni '80 dallo standard Sistema globale per dispositivi mobili (Sistema globale per le comunicazioni mobili). Il GSM è stato il primo grande standard di telefonia cellulare digitale, che ha introdotto una serie di caratteristiche rivoluzionarie, come l'utilizzo crittografia per proteggere le telefonate. Il primo GSM era progettato principalmente per le comunicazioni vocali, anche se il denaro poteva esserlo trasmettere altri dati.

Poiché la trasmissione dei dati è diventata più importante nelle comunicazioni cellulari, sono stati sviluppati gli standard LTE (Long Term Evolution) per semplificare questo tipo di comunicazione. LTE si basa su un gruppo di standard più vecchi come GSM, BORDO и HSPA ed è progettato per aumentare la velocità di scambio dei dati. C'è molto marchio e fuorviante con designazioni erratema il TL;DR è che LTE è un sistema di trasmissione dati che funge da ponte tra i vecchi protocolli di dati a pacchetto e le future tecnologie di dati cellulari 5G.

Naturalmente, la storia ci dice che una volta che sarà disponibile una larghezza di banda (IP) sufficiente, concetti come “voce” e “dati” inizieranno a confondersi. Lo stesso vale per i moderni protocolli cellulari. Per rendere questa transizione più agevole, definiscono gli standard LTE Voice over LTE (VoLTE), che è uno standard IP per trasportare chiamate vocali direttamente sul piano dati di un sistema LTE, bypassando completamente la porzione di accesso remoto della rete cellulare. Come di serie Chiamate VoIP,Le chiamate VoLTE possono essere terminate dall'operatore cellulare e collegate alla normale rete telefonica. Oppure (come sta diventando sempre più comune) loro può essere instradato direttamente da un cliente cellulare all'altro e anche tra diversi fornitori.

Come il VoIP standard, VoLTE si basa su due popolari protocolli basati su IP: Session Initiation Protocol (Protocollo di Inizializzazione Sessione – SIP) per l'impostazione delle chiamate e il protocollo di trasporto in tempo reale (Protocollo di trasporto in tempo reale, che dovrebbe chiamarsi RTTP ma in realtà si chiama RTP) per l'elaborazione dei dati vocali. VoLTE aggiunge anche alcune ottimizzazioni aggiuntive della larghezza di banda, come la compressione dell'intestazione.

Ok, cosa c'entra questo con la crittografia?

LTE, come GSM, dispone di un set standard di protocolli crittografici per crittografare i pacchetti durante la trasmissione via etere. Sono progettati principalmente per proteggere i tuoi dati mentre viaggiano tra il telefono (chiamato apparecchiatura utente o UE) e il ripetitore del cellulare (o ovunque il tuo provider decida di terminare la connessione). Questo perché i provider di telefonia mobile considerano i dispositivi di intercettazione esterni come nemici. Beh, certo.

(Tuttavia, il fatto che le connessioni VoLTE possano avvenire direttamente tra client su reti di provider diversi significa che il protocollo VoLTE stesso ha alcuni protocolli di crittografia aggiuntivi e opzionali che possono verificarsi a livelli di rete più alti. Ciò non è rilevante per l'articolo corrente, tranne il fatto che possono rovinare tutto (ne parleremo brevemente dopo).

Storicamente, la crittografia nel GSM è stata molti punti deboli: Cattivo cifre, protocolli in cui solo il telefono veniva autenticato presso la torre (il che significa che un utente malintenzionato poteva impersonare la torre, generando "Stingray") e così via. LTE ha corretto molti dei bug evidenti mantenendo gran parte della stessa struttura.

Cominciamo con la crittografia stessa. Supponendo che la creazione della chiave sia già avvenuta - e ne parleremo tra un minuto - ogni pacchetto di dati viene crittografato utilizzando la crittografia del flusso utilizzando qualcosa chiamato "EEA" (che in pratica può essere implementato utilizzando cose come AES). In sostanza, il meccanismo di crittografia qui è CTRcome sotto:

Il principale algoritmo di crittografia per i pacchetti VoLTE (fonte: Rivolta). EEA è un codice, "COUNT" è un contatore a 32 bit, "BEARER" è un identificatore di sessione univoco che separa le connessioni VoLTE dal normale traffico Internet. "DIREZIONE" indica in quale direzione scorre il traffico: dall'UE alla torre o viceversa.

Poiché l'algoritmo di crittografia stesso (EEA) può essere implementato utilizzando un codice potente come AES, è improbabile che si verifichi un attacco diretto al codice stesso come questo è successo ai tempi del GSM. Tuttavia, è chiaro che anche con una cifratura forte, questo schema di crittografia è un ottimo modo per darsi la zappa sui piedi.

In particolare: lo standard LTE utilizza un codice a flusso (non autenticato) con una modalità che sarà estremamente vulnerabile se il contatore - e altri input come "portatore" e "direzione" - verranno mai riutilizzati. Nel linguaggio moderno, il termine per questo concetto è “nonce reuse attack”, ma i rischi potenziali qui non sono qualcosa di moderno. Sono famosi e antichi, risalenti ai tempi del glam metal e persino della discoteca.

Gli attacchi al riutilizzo del nonce in modalità CTR esistevano anche quando Poison divenne noto

Per essere onesti, gli standard LTE dicono: “Per favore, non riutilizzare questi contatori”. Ma gli standard LTE sono lunghi circa 7000 pagine e, in ogni caso, è come chiedere ai bambini di non giocare con una pistola. Lo faranno inevitabilmente e accadranno cose terribili. L'arma in questo caso è un attacco di riutilizzo del keystream, in cui due diversi messaggi riservati effettuano XOR sugli stessi byte del keystream. È noto che questo ha un effetto molto distruttivo sulla riservatezza delle comunicazioni.

Cos'è ReVoLTE?

L’attacco ReVoLTE dimostra che, in pratica, questo design di crittografia molto vulnerabile viene utilizzato in modo improprio dall’hardware del mondo reale. Nello specifico, gli autori analizzano le chiamate VoLTE reali effettuate utilizzando apparecchiature commerciali e dimostrano che possono utilizzare qualcosa chiamato "attacco di reinstallazione della chiave". (Gran parte del merito per aver individuato questo problema va a Reise e Lu (Raza & Lu), che per primi hanno segnalato la potenziale vulnerabilità. Ma la ricerca ReVoLTE lo trasforma in un attacco pratico).

Lascia che ti mostri brevemente l'essenza dell'attacco, anche se dovresti guardare e documento di origine.

Si potrebbe supporre che una volta che LTE stabilisce una connessione dati a pacchetto, il compito della voce su LTE diventa solo una questione di instradare i pacchetti vocali su quella connessione insieme a tutto il resto del traffico. In altre parole, VoLTE sarà un concetto che esisterà solo over 2 livello [Modelli OSI – ca.]. Questo non è del tutto vero.

Infatti, il livello di collegamento LTE introduce il concetto di "portante". I portatori sono identificatori di sessione separati che separano diversi tipi di traffico di pacchetti. Il traffico Internet regolare (Twitter e Snapchat) passa attraverso un portatore. La segnalazione SIP per VoIP passa attraverso un altro e i pacchetti di traffico vocale vengono elaborati attraverso un terzo. Non sono molto informato sulla radio LTE e sui meccanismi di routing della rete, ma credo che sia fatto in questo modo perché le reti LTE vogliono applicare i meccanismi QoS (qualità del servizio) in modo che diversi flussi di pacchetti vengano elaborati a diversi livelli di priorità: ad es. il tuo di second'ordine Le connessioni TCP a Facebook potrebbero avere una priorità inferiore rispetto alle chiamate vocali in tempo reale.

Questo generalmente non è un problema, ma le conseguenze sono le seguenti. Le chiavi per la crittografia LTE vengono create separatamente ogni volta che viene installato un nuovo "portatore". Fondamentalmente, questo dovrebbe ripetersi ogni volta che effettui una nuova telefonata. Ciò comporterà l'utilizzo di una chiave di crittografia diversa per ciascuna chiamata, eliminando la possibilità di riutilizzare la stessa chiave per crittografare due diversi set di pacchetti di chiamate vocali. In effetti, lo standard LTE dice qualcosa del tipo "dovresti usare una chiave diversa ogni volta che installi una nuova portante per gestire una nuova chiamata telefonica". Ma ciò non significa che ciò effettivamente accada.

Infatti, nelle implementazioni nella vita reale, due diverse chiamate che si verificano in stretta prossimità temporale utilizzeranno la stessa chiave, nonostante il fatto che tra di loro siano configurati nuovi portatori con lo stesso nome. L'unico cambiamento pratico che si verifica tra queste chiamate è che il contatore di crittografia viene reimpostato su zero. In letteratura questo viene talvolta chiamato attacco di reinstallazione della chiave. Si potrebbe sostenere che si tratti essenzialmente di un errore di implementazione, anche se in questo caso i rischi sembrano derivare in gran parte dalla norma stessa.

In pratica, questo attacco si traduce in un riutilizzo del flusso di chiavi, in cui l'aggressore può ottenere i pacchetti crittografati $inline$C_1 = M_1 oplus KS$inline$ e $inline$C_2 = M_2 oplus KS$inline$, consentendo il calcolo di $inline$ C_1 opiù C_2 = M_1 opiù M_2$in linea$. Ancora meglio, se l'aggressore conosce uno tra $inline$M_1$inline$ o $inline$M_2$inline$, può immediatamente recuperare l'altro. Questo gli dà un forte incentivo scoprire uno dei due componenti non crittografati.

Questo ci porta allo scenario di attacco completo e più efficace. Consideriamo un utente malintenzionato che possa intercettare il traffico radio tra un telefono preso di mira e un ripetitore cellulare e che in qualche modo abbia la fortuna di registrare due chiamate diverse, con la seconda che si verifica immediatamente dopo la prima. Ora immagina che possa in qualche modo indovinare il contenuto non crittografato di una delle chiamate. Con così serendipità il nostro aggressore può decriptare completamente la prima chiamata utilizzando un semplice XOR tra i due insiemi di pacchetti.

Naturalmente la fortuna non c’entra nulla. Poiché i telefoni sono progettati per ricevere chiamate, un utente malintenzionato che riesce a sentire la prima chiamata sarà in grado di avviarne una seconda nel momento esatto in cui termina la prima. Questa seconda chiamata, se si utilizza nuovamente la stessa chiave di crittografia con il contatore azzerato, consentirà il recupero dei dati non crittografati. Inoltre, poiché il nostro aggressore controlla effettivamente i dati durante la seconda chiamata, può recuperare il contenuto della prima chiamata, grazie a molti strumenti appositamente implementati piccole cose, giocando dalla sua parte.

Ecco un'immagine del piano di attacco generale tratta da documento originale:

Panoramica dell'attacco da Documento ReVoLTE. Questo schema presuppone che vengano effettuate due chiamate diverse utilizzando lo stesso tasto. L'aggressore controlla lo sniffer passivo (in alto a sinistra) e un secondo telefono con il quale può effettuare una seconda chiamata al telefono della vittima.

Quindi l’attacco funziona davvero?

Da un lato questa è davvero la domanda principale per l’articolo su ReVoLTE. Tutte le idee di cui sopra sono fantastiche in teoria, ma lasciano molte domande. Ad esempio:

1. È possibile (per i ricercatori accademici) intercettare effettivamente una connessione VoLTE?
2. I veri sistemi LTE sono effettivamente rekey?
3. Puoi effettivamente avviare una seconda chiamata in modo sufficientemente rapido e affidabile da consentire al telefono e alla torre di riutilizzare la chiave?
4. Anche se il sistema riprogramma, puoi effettivamente conoscere il contenuto non crittografato della seconda chiamata, dato che cose come i codec e la transcodifica possono modificare completamente il contenuto (bit per bit) di quella seconda chiamata, anche se hai accesso ai "bit" "proveniente dal tuo telefono d'attacco?

Il lavoro di ReVoLTE risponde affermativamente ad alcune di queste domande. Gli autori utilizzano uno sniffer di flusso radio riconfigurabile tramite software commerciale chiamato Aeroscopio per intercettare una chiamata VoLTE dal lato downlink. (Penso che solo prendere confidenza con il software e farsi un'idea approssimativa di come funziona abbia richiesto mesi di vita ai poveri studenti laureati, il che è tipico di questo tipo di ricerca accademica).

I ricercatori hanno scoperto che affinché il riutilizzo delle chiavi funzionasse, la seconda chiamata doveva avvenire abbastanza rapidamente dopo la fine della prima, ma non troppo rapidamente, circa dieci secondi per gli operatori con cui hanno sperimentato. Fortunatamente non ha importanza se l'utente risponde alla chiamata entro questo tempo, ovvero lo "squillo". La stessa connessione SIP obbliga l'operatore a riutilizzare la stessa chiave.

Pertanto, molti dei problemi più fastidiosi ruotano attorno al problema (4): ricevere frammenti del contenuto non crittografato di una chiamata avviata da un utente malintenzionato. Questo perché possono succedere molte cose ai tuoi contenuti mentre viaggiano dal telefono dell'aggressore a quello della vittima attraverso la rete cellulare. Ad esempio, trucchi sporchi come ricodificare un flusso audio codificato, lasciando il suono lo stesso, ma cambiando completamente la sua rappresentazione binaria. Le reti LTE utilizzano anche la compressione dell'intestazione RTP, che può modificare in modo significativo gran parte del pacchetto RTP.

Infine, i pacchetti inviati dall'aggressore dovrebbero essere più o meno in linea con i pacchetti inviati durante la prima telefonata. Ciò può essere problematico perché la modifica del silenzio durante una telefonata produce messaggi più brevi (noti anche come rumore di conforto) che potrebbero non adattarsi bene alla chiamata originale.

Sezione "Attacco nel mondo reale" Vale la pena leggerlo in dettaglio. Risolve molti dei problemi sopra menzionati: in particolare, gli autori hanno scoperto che alcuni codec non vengono ricodificati e che circa l'89% della rappresentazione binaria della chiamata di destinazione può essere recuperata. Questo è vero per almeno due operatori europei che sono stati testati.

Si tratta di un tasso di successo sorprendentemente alto e, francamente, molto più alto di quanto mi aspettassi quando ho iniziato a lavorare su questo documento.

Quindi cosa possiamo fare per risolverlo?

La risposta immediata a questa domanda è molto semplice: poiché l'essenza della vulnerabilità è un attacco di riutilizzo (reinstallazione) della chiave, è sufficiente risolvere il problema. Assicurarsi che venga ottenuta una nuova chiave per ogni chiamata telefonica e non consentire mai al contatore dei pacchetti di azzerare il contatore utilizzando la stessa chiave. Problema risolto!

O forse no. Ciò richiederà l'aggiornamento di molte apparecchiature e, francamente, una soluzione del genere di per sé non è estremamente affidabile. Sarebbe bello se gli standard trovassero un modo più sicuro per implementare le loro modalità di crittografia che non sia per impostazione predefinita catastroficamente vulnerabile a tali problemi di riutilizzo delle chiavi.

Una possibile opzione è utilizzare modalità di crittografia in cui l’uso improprio del nonce non porta a conseguenze catastrofiche. Questo potrebbe essere troppo costoso per alcuni degli hardware di oggi, ma è certamente un’area a cui i progettisti dovrebbero pensare in futuro, soprattutto perché gli standard 5G stanno per conquistare il mondo.

Questo nuovo studio solleva anche la questione generale del perché gli stessi dannati attacchi continuano a comparire in uno standard dopo l'altro, molti dei quali utilizzano progetti e protocolli molto simili. Quando ti trovi di fronte al problema di reinstallare la stessa chiave su più protocolli ampiamente utilizzati come WPA2, non pensi che potrebbe essere il momento di rendere le specifiche e le procedure di test più robuste? Smetti di trattare gli implementatori degli standard come partner premurosi e attenti ai tuoi avvertimenti. Trattali come avversari (non intenzionali) che inevitabilmente sbaglieranno le cose.

Oppure, in alternativa, possiamo fare ciò che aziende come Facebook e Apple stanno facendo sempre più spesso: far sì che la crittografia delle chiamate vocali avvenga a un livello più alto dello stack di rete OSI, senza fare affidamento sui produttori di apparecchiature cellulari. Potremmo anche spingere per la crittografia end-to-end delle chiamate vocali, come sta facendo WhatsApp con Signal e FaceTime, supponendo che il governo degli Stati Uniti smetta di farlo farci inciampare. Allora (ad eccezione di alcuni metadati) molti di questi problemi semplicemente scomparirebbero. Questa soluzione è particolarmente rilevante in un mondo in cui anche i governi non sono sicuri di fidarsi dei propri fornitori di apparecchiature.

Oppure possiamo semplicemente fare quello che hanno già fatto i nostri figli: smettere di rispondere a quelle fastidiose chiamate vocali.

Fonte: habr.com