Le vulnerabilità di Voice-over LTE

I ricercatori della francese P1 Security hanno svolto un’analisi del protocollo VoLTE , i cui risultati hanno evidenziato alcune problematiche di sicurezza che spaziano dalla possibilità di effettuare attacchi di spoofing – falsificando le informazioni sul mittente – all’opportunità di individuare informazioni riservate relative ad altri utenti della rete telefonica, come la posizione geografica e L’IMEI.

VoLTE (Voice over LTE) è una tecnologia che punta alla reimplementazione delle funzionalità di comunicazione vocale proprie della rete GSM su una rete di quarta generazione LTE (Long Term Evolution) tramite protocolli VoIP (Voice over IP); l’obiettivo più generico è quindi quello di fornire un livello di convergenza basato su reti IP per le funzionalità multimediali relative a dispositivi di comunicazione fissi e mobili ( IMS ).

Tra i protocolli implicati ricordiamo SIP (Session Initiation Protocol), utilizzato per stabilire le sessioni di comunicazione nei protocolli di comunicazione VOIP, e SDP (Session Description Protocol), payload di SIP che fornisce un formato per la descrizione di sessioni di comunicazione multimediali.

Da un’indagine condotta nell’ambito della ricerca di P1 Security è emerso come tale tecnologia, adottata inizialmente in Corea del Sud e a Singapore, sia ormai uno standard de facto adottato da svariati operatori su tutto il territorio globale a partire dalla fine del 2015.

È appunto questa la ragione che ha portato i ricercatori ad analizzarne la sicurezza, individuando tre vulnerabilità classificate come “attive” – sfruttabili forgiando pacchetti SIP – e tre vulnerabilità “passive”, rilevate mediante semplici operazioni di sniffing effettuate tramite un dispositivo Android con privilegi di root.

I risultati della ricerca sono stati ampiamente documentati in un articolo presentato alla conferenza SSTIC 2017 , tenutasi dal 7 al 9 giugno scorso a Rennes, in Francia.

Vulnerabilità attive
1) Enumerazione degli utenti mediante il messaggio SIP “INVITE”
In alcune implementazioni dei proxy CSCF (Call Session Control Function) è stato possibile effettuare attacchi a forza bruta utilizzando il comando “INVITE” del protocollo SIP per enumerare gli utenti connessi alla rete. Ciò richiede che anche l’attaccante sia registrato sulla rete; la vulnerabilità consiste nel fatto che il messaggio di risposta al comando INVITE conterrà il codice “SIP 500 CX Unable To Comply” nel caso in cui l’utente selezionato non esiste.
Una possibile mitigazione, in tal caso, potrebbe consistere nel limitare il rate di messaggi INVITE .

2) Utilizzo del protocollo SDP per scambiare dati
Questa vulnerabilità permette di scambiare dati sfruttando il protocollo SDP , evitando di inizializzare il modulo CDR responsabile della fatturazione e il modulo LI (Lawful Interception, utilizzato per permettere alle autorità di intercettare alcune caratteristiche del traffico telefonico per fini legali). I ricercatori sono stati in grado di modificare gli header iniettando stringhe arbitrarie senza che i meccanismi di sicurezza adottati se ne accorgessero.
Per evitare casi simili occorre introdurre meccanismi di sanitizzazione dei dati o deep packet inspection .

3) Spoofing dell’identificativo utente (MSISDN) tramite SIP “INVITE”
L’MSISDN è il numero telefonico dell’utente, comprensivo di prefisso operatore e del prefisso internazionale. Questa vulnerabilità è evidentemente la più grave di questa categoria, e consente, come è facilmente intuibile, di falsificare il numero telefonico di un utente durante una chiamata .
Ciò può avvenire modificando i valori degli header From e P-preferred-Identity nel comando SIP INVITE, che non sempre vengono sovrascritti dal proxy CSCF per errori di implementazione o di configurazione.

Vulnerabilità passive
1) Leak di informazioni tecniche del server SIP mediante la ricezione di messaggi “200 Ok”
Si tratta di una vulnerabilità con impatto limitato che permette di effettuare enumerazione e fingerprinting dei componenti e degli apparati della rete dell’operatore, analizzando le intestazioni dei pacchetti in transito sulla rete. La contromisura è banale, e consiste nel sanitizzare in modo opportuno i pacchetti inviati dal server SIP al dispositivo client.

2) Leak del codice IMEI di un utente della rete
Il codice IMEI è individuabile nel messaggio SIP ” 183 session Progress “, inviato dal terminale ricevente in risposta al messaggio INVITE , in particolar modo nella variabile +sip.instance .

3) Leak dell’identificativo della cella a cui è connesso un utente della rete
Analogamente alla vulnerabilità appena descritta, l’identificativo della cella è disponibile nel messaggio “183 session Progress”, nella variabile ultran-cell-id-3gpp .

Ciò fornisce a un attaccante la possibilità di ottenere informazioni ben più sensibili dell’IMEI, come ad esempio informazioni sulla posizione del dispositivo, sulla base della cella agganciata.
Infatti la variabile in questione contiene le seguenti informazioni:
– MCC, Mobile Country Code, prime tre cifre, che identificano la nazione;
– MNC, Mobile Network Code, di due cifre, che identifica l’operatore mobile;
– LAC, Location Area Code, di quattro cifre, che identifica in modo univoco l’area geografica dell’utente, organizzata sulla base di stazioni raggruppate per ottimizzare il segnale;
– LCID, ULTRAN CellID, Concatenazione dell’RNC-ID (identificativo del Radio Network Controller) e del CID (identificativo della cella telefonica).
Una volta ottenuti tali dati, un attaccante può risalire alla posizione della vittima utilizzando vari database online .

Patrizio Tufarolo