IP Multimedia Subsystem (IMS) offre molti servizi multimediali a qualsiasi rete di accesso basata su IP, come LTE o DSL. Oltre a VoLTE, IMS aggiunge flessibilità al provider di servizi, migliore QoS e controllo della ricarica alla quarta generazione di reti mobili. IMS scambia messaggi SIP con i suoi utenti o altri IMS e di solito queste comunicazioni sono protette da TLS o IPSec. Ma se un utente malintenzionato riesce a violare la riservatezza e l'integrità con IMS, lo troverebbe vulnerabile a diversi attacchi.
Un utente malintenzionato non deve superare la sicurezza del trasporto per violare la riservatezza e l'integrità con IMS. Ad esempio, possedere l'equipaggiamento utente (UE) di una vittima potrebbe garantire a un utente malintenzionato i dati riservati di cui ha bisogno per sviluppare molti attacchi contro di lui. Inoltre, gli aggressori motivati, che prendono di mira lo stesso IMS, possono riuscire a ottenere la loro IPSec ESP Integrity Key (IK ESP ) dalla loro UE e quindi manipolare le loro richieste a loro piacimento. Un esempio di quest'ultimo caso è ben spiegato qui. Questo post del blog discute lo sfruttamento di IMS in questi casi di integrità e perdita di riservatezza.
La mia tesi di Master "Valutazione della sicurezza IMS e sviluppo di test di penetrazione di IMS" discute lo sfruttamento delle vulnerabilità di IMS nel caso in cui le sue misure di riservatezza e integrità vengano violate. Le specifiche 3GPP e le RFC IETF definiscono il funzionamento di IMS e quindi possono portarci alle sue vulnerabilità. Gli attacchi per sfruttare queste vulnerabilità sono testati e dimostrati sul core di OpenIMS. Gli attacchi di disponibilità su IMS sono stati discussi in precedenza in un precedente post del blog .
Configurazione del laboratorio
Il laboratorio di test è costituito da due macchine virtuali, entrambe ospitate sullo stesso host. La prima è la macchina virtuale OpenIMS, disponibile per il download dal sito Web del progetto . È una macchina Ubuntu, con OpenIMS core e due client SIP installati. Due utenti predefiniti, Alice e Bob, esistono già su OpenIMS. Ho aggiunto un terzo utente "Evil" per rappresentare un attaccante. Sebbene il core di OpenIMS supporti TLS, IPsec e SIP su TCP, ho utilizzato la configurazione predefinita di SIP su UDP. Non vengono utilizzati né IPsec né TLS.
La seconda VM è una VM Kali, che rappresenta l'attaccante. L'attaccante Evil utilizza un client OpenIC_lite, oltre a diversi strumenti tra cui:
Rutto
A causa della somiglianza tra SIP e HTTP, il ripetitore di Burp viene utilizzato come metodo flessibile per costruire e scambiare messaggi SIP con OpenIMS core. Come mostrato di seguito, Repeater è configurato per inviare i propri messaggi alla porta TCP locale 6066.
Socat
Trasforma i messaggi HTTP / TCP prodotti da Burp in messaggi SIP / UDP che OpenIMS si aspetta e viceversa. Il comando seguente converte il traffico TCP proveniente dalla porta 6066 (output di Burp's Repeater) in UDP e lo inoltra a IMS (192.168.56.102 in questo caso).
socat -d -d tcp-listen: 6066, reuseaddr, fork udp: 192.168.56.102
Raccolta di informazioni
Prima che un utente malintenzionato esegua un attacco, esegue un processo di raccolta di quante più informazioni possibili sulla vittima (che si tratti di un utente o della rete stessa). Un utente malintenzionato può raccogliere molte informazioni semplicemente ascoltando i suoi messaggi SIP, come ad esempio:
Address Discovery
Conoscere l'indirizzo IP della vittima aiuta l'aggressore a prendere di mira un nodo specifico nella rete o a falsificare l'indirizzo IP della vittima per rubare la sua identità. Quando un utente malintenzionato riceve una richiesta di invito, può trovare indirizzi IP, porte e / o indirizzi FQDN del chiamante o dei nodi IMS nelle seguenti intestazioni:
- Via : un nodo SIP popola il suo indirizzo in un nuovo campo di intestazione Via e lo aggiunge a una richiesta SIP, in modo da garantire che la sua risposta venga instradata attraverso questo nodo. Pertanto, la richiesta di invito include solitamente l'indirizzo dell'utente che ha avviato e tutti i nodi da cui è stata gestita la richiesta SIP (PCSCF, I-CSCF e S-CSCF)
- Contatto : contiene l'indirizzo fisico del mittente di qualsiasi richiesta SIP. L'intestazione del contatto contiene solitamente l'indirizzo del mittente.
- Call-ID : Call-ID dovrebbe essere univoco nel tempo e nello spazio per identificare un dialogo specifico. I client SIP potrebbero aggiungere il proprio indirizzo IP all'identificatore per garantire l'unicità.
- Payload SDP : SDP viene trasportato come payload della richiesta di invito, per descrivere la sessione multimediale che successivamente metterà in attesa la chiamata. Ci sono due campi che contengono informazioni sull'indirizzo IP dell'origine della chiamata, queste intestazioni sono:
- Dati di connessione c
- Origine o
In alcune implementazioni IMS, gli utenti scoprono gli indirizzi di P-CSCF utilizzando query DHCP e / o DNS. Se a un utente non è vietato interrogare anche gli indirizzi di altri nodi, un utente malintenzionato può scoprire gli indirizzi di qualsiasi FQDN divulgato in qualsiasi messaggio SIP.
Enumerazione utenti
Come in qualsiasi rete di telefonia, la chiamata di un utente ti informerà sul suo stato, se disponibile, occupato, non disponibile o inesistente. Pertanto, la richiesta di invito è un modo accurato ma rumoroso per enumerare un utente. Tuttavia, la richiesta di Opzioni ha gli stessi codici di risposta della richiesta di invito [1]. Pertanto, un utente malintenzionato preferirebbe utilizzare la richiesta Opzioni silenziosa per conoscere lo stato di qualsiasi utente senza nemmeno avvisarlo. Le richieste di opzioni non sono essenziali per le azioni IMS come la registrazione o l'avvio di una chiamata. Pertanto, si consiglia di non rispondere alle richieste di Opzioni da parte degli utenti.
Enumerazione di rete
Se un nodo SIP riceve una richiesta Opzioni con il campo di intestazione Max-Forward impostato su 0, il nodo può rispondere alla richiesta indipendentemente dall'URI di destinazione [1]. Pertanto, se i nodi CSCF non sono ben rafforzati, un utente malintenzionato può raccogliere informazioni sui nodi utilizzando le richieste di opzioni con l'intestazione Max-Forward incrementale. Questo è noto come attacco SIP Traceroute [2].
Inoltre, qualsiasi nodo CSCF non protetto può aggiungere un banner del server alle sue risposte SIP. Tale intestazione può rivelare il produttore e la versione dei nodi CSCF. I nodi principali di OpenIMS allegano il seguente banner del server:
Attacchi di violazione dell'integrità
Dopo che l'autore dell'attacco ha raccolto informazioni sufficienti su IMS e sui suoi utenti, è il momento di mettere in atto queste informazioni. Un utente malintenzionato può concentrare i suoi attacchi su una vittima specifica o dirigere i suoi attacchi verso la rete stessa. La sezione seguente illustra esempi di scenari di attacco, quando un utente malintenzionato riesce a manipolare i propri messaggi SIP a IMS:
Furto d'identità dell'utente
La registrazione come utente potrebbe sembrare il modo più efficace per impersonare questo utente. Ma in tal caso, l'attaccante deve aggirare il rigoroso processo di autenticazione o fornire dati segreti come IMPI e il segreto condiviso. Pertanto, se un utente malintenzionato "Malvagio" desidera chiamare "Alice" come "Bob", sarebbe più facile impersonare Bob direttamente in una richiesta di invito. Questo attacco può essere suddiviso in due fasi:
1- Richiesta di invito
All'inizio, Evil deve creare un messaggio di invito che ingannerebbe sia l'IMS che il chiamato. Pertanto, i seguenti campi di intestazione dovrebbero essere presi in considerazione:
- Da : contiene l'IMPU dell'utente. Specifica l'identità del mittente e non influisce su alcuna decisione di instradamento.
- P-Asserted-Identity: conferma l'identità del mittente. P-CSCF di solito rimuove qualsiasi intestazione P-Asserted-Identity in qualsiasi messaggio SIP ricevuto da qualsiasi utente e quindi aggiunge la propria. Ma se il mittente è un "mittente privilegiato", P-CSCF mantiene il campo di intestazione così com'è [3].
- P-Preferred-Identity Questo campo di intestazione viene aggiunto dal mittente di un messaggio SIP per informare un proxy SIP (come P-CSCF) sull'IMPU che il mittente desidera che il proxy assegni come valore P-Asserted-Identity [4]. Questo porta P-CSCF a controllare le IMPU nella richiesta e fa fallire l'attacco.
Dopotutto, il successo dell'attacco dipende dal client della vittima e da come decide l'identità del chiamante. Per dimostrarlo, il Male lancerà due attacchi invece di uno. Nel primo attacco, impersonerà Bob per chiamare Alice come menzionato prima, e nel secondo farà il contrario: chiamerà Bob come Alice. Alice è registrata su OpenIMS core utilizzando il client OpenIC_lite, mentre Bob è registrato utilizzando un client Monster IMS. In entrambi gli attacchi, Evil crea un messaggio di invito che ha lo stesso aspetto di un messaggio di invito legittimo da Evil ad Alice o Bob, ad eccezione di quanto segue:
- L'URI della richiesta e il campo dell'intestazione A sono impostati sull'IMPU della vittima (sia di Alice che di Bob).
- Da è impostato su IMPU di Bob.
- P-Asserted-Identity viene aggiunto con un valore di IMPU di Alice.
- Il campo dell'intestazione P-Preferred-Identity viene rimosso.
La richiesta precedente imposta due identità del chiamante in due diversi campi. L'URI della richiesta è impostato rispettivamente su Alice e Bob nel primo e nel secondo attacco. Ad esempio, la richiesta di invito inviata ad Alice sarebbe simile alla seguente:
2- Spoofing IP
Quando un utente si registra a IMS, P-CSCF salva il suo indirizzo IP e la sua porta. Quindi, quando riceve un'ulteriore richiesta SIP da questo utente, convalida l'indirizzo IP e la porta del mittente con i dati salvati durante la registrazione [5]. Quindi, anche se né TLS né IPsec sono abilitati, P-CSCF può comunque eseguire alcune autenticazioni dell'origine dei dati. Pertanto, nella seconda fase, Evil deve falsificare l'indirizzo del chiamante. Fortunatamente, può conoscere l'indirizzo IP di qualsiasi utente come discusso sopra. Poiché utilizzo SIP su UDP, è stato possibile falsificare l'indirizzo IP e la porta della vittima.
Risultato
Le richieste di invito da entrambi gli attacchi vengono consegnate con successo alle vittime. Il client OpenIC_lite di Alice decide l'ID chiamante in base al campo di intestazione Da e visualizza l'ID chiamante come Bob. Il client IMS Monster di Bob ottiene l'ID chiamante da P-Asserted-Identity. Lo stesso attacco funziona anche con la messaggistica utilizzando la richiesta di messaggi SIP.
Manipolazione dell'intestazione
Questo è un esempio di un utente malintenzionato che prende di mira la rete stessa. Un utente malintenzionato può modificare alcune delle sue intestazioni per fornire a IMS informazioni false. L'impatto di tali attacchi dipende da come IMS gestisce questi campi di intestazione. Ad esempio, può trascurarli totalmente o prendere importanti decisioni di ricarica basate su di essi.
Manipolazione della posizione
Molti operatori di telefonia mobile offrono servizi basati sulla posizione (LBS), che forniscono agli utenti servizi speciali o offerte di addebito in base alla loro posizione. P-Access-Network-Info è il campo di intestazione che definisce la posizione dell'utente nella rete di accesso come mostrato nell'esempio seguente:
Se un utente malintenzionato può impostare questo campo di intestazione nei suoi messaggi SIP su qualsiasi ID cellulare che preferisce, può utilizzare offerte specifiche per località a cui non è effettivamente idoneo. Tuttavia, se questo campo dell'intestazione contiene l'attributo fornito dalla rete o np , P-CSCF recupererà la posizione dell'aggressore dalla rete di accesso e aggiornerà il campo dell'intestazione.
Roaming
I roaming in uscita di solito pagano tariffe di servizio più elevate e hanno accesso a meno servizi rispetto agli utenti della rete locale. Pertanto, qualsiasi aggressore vorrebbe un modo per sembrare alla sua rete domestica come un utente locale.
P-Visited-Network-ID è un campo di intestazione di una richiesta di registro che contiene la rete di accesso che serve l'utente. Di conseguenza, indica se l'utente è in roaming o meno. Quindi cosa succederebbe se un utente malintenzionato si registrasse da un'altra rete e inserisse un campo di intestazione P-Visited-Network-ID con il valore della rete locale nella sua richiesta di registro?
Normalmente, P-CSCF di OpenIMS aggiunge a qualsiasi richiesta di registro un campo di intestazione P-Visited-Network-ID con un valore del dominio di rete "open-ims.test". Supponendo che il dominio di rete di un utente malintenzionato in roaming sia ad esempio open-ims2.test, imposta P-Visited-Network-ID su questo valore nella sua richiesta di registrazione. Il P-CSCF di OpenIMS core non rimuove il campo né ne aggiunge uno nuovo. Invece, aggiunge semplicemente il dominio di rete al campo dell'aggressore come mostrato nella figura seguente. Alla fine, I-CSCF considera l'intero valore di P-Visited-Network-ID come l'ID di rete dell'attaccante . Sebbene l'attacco abbia avuto esito negativo, dimostra che la gestione del campo P-Visited-Network-ID da parte di CSCF può essere complicata e inaspettata.
Allegato intestazione extra
SIP è un protocollo flessibile che consente agli utenti di aggiungere intestazioni personalizzate alle loro richieste. Per impostazione predefinita, IMS non elimina i campi di intestazione aggiuntivi nei messaggi SIP. Ciò significa che un utente può trasferire messaggi o dati a un altro utente su richieste SIP gratuite.
Attacchi di iniezione
Un utente malintenzionato può lanciare altri attacchi di iniezione su IMS. Ad esempio, il campo di intestazione Autorizzazione di una richiesta di registro SIP contiene la risposta IMPI e password / AKA dell'utente che si registra. Questi dati vengono solitamente controllati da HSS, che alla fine della giornata è un database. Se HSS non è ben protetto, potrebbe essere vulnerabile agli attacchi di SQL injection.
Inoltre, le richieste SIP come Sottoscrivi e Pubblica contengono payload XML. Questi payload XML indurrebbero qualsiasi utente malintenzionato a provare alcuni attacchi XXE che potrebbero avere un impatto su qualsiasi nodo IMS che analizza queste richieste, in particolare i server di presenza.
Attacchi di violazione dell'integrità e della riservatezza
Più informazioni riceve un utente malintenzionato sul traffico SIP della vittima, più potenti potrebbero ottenere i suoi attacchi. Ad esempio, se un utente malintenzionato riesce a:
- Cattura il dialogo SIP corrente e gli identificatori di transazione (campi Da, A, Via, CSeq e Call-ID) dai messaggi SIP della vittima.
- Oltre alla sua capacità di spoofing IP che ha già dimostrato in precedenza
e segue le regole dei dialoghi e delle transazioni, quindi può iniettare qualsiasi messaggio SIP nel mezzo di qualsiasi dialogo. Può anche impersonare P-CSCF che serve l'utente e inviare alla vittima messaggi SIP non autorizzati come se provenissero da IMS. Di seguito sono riportati alcuni esempi dei possibili attacchi:
Reindirizza la chiamata stabilita di una vittima a qualsiasi destinazione
Se la vittima sta effettuando una chiamata e il telefono / client SIP dell'altra parte squilla, riceverà una risposta di 180 Ringing . A quel punto, l'attaccante può impersonare P-CSCF e inviare una risposta 302 Move Temporarily alla vittima. La chiamata della vittima verrà reindirizzata all'IMPU nell'intestazione del contatto della risposta canaglia [5].
La risposta 302 Move Temporary canaglia sarebbe la stessa della risposta 180 Ringing, ad eccezione della risposta di intestazione (302 Redirect) e dell'IMPU dell'attaccante nell'intestazione del contatto. Tutti i valori nelle caselle verdi dovrebbero essere gli stessi del messaggio 180 Ringing perché entrambi i messaggi devono appartenere alla stessa transazione SIP.
Termina una chiamata stabilita
L'aggressore può impersonare la vittima e inviare una richiesta SIP Bye per terminare la chiamata. Una richiesta Bye avvia una nuova transazione all'interno dello stesso dialogo, pertanto i campi di dialogo rimangono gli stessi della richiesta di invito iniziale e il campo CSeq viene incrementato.
Annulla una chiamata in corso
Se la vittima è il chiamante, un utente malintenzionato può impersonare P-CSCF e inviare una risposta 486 Busy SIP non autorizzato alla vittima. Ciò mantiene il dialogo e gli identificatori di transazione della precedente risposta provvisoria 180 Ringing.
Annulla la registrazione della vittima
Per simulare una cancellazione dalla rete avviata, un utente malintenzionato invia richieste di notifica non autorizzate come P-CSCF all'utente. gli attributi di stato e di evento di questa richiesta di notifica vengono impostati rispettivamente su terminato e rifiutato [3].
Conclusione
IMS è e sarà l'obiettivo di molti attacchi, a causa del suo ruolo principale in qualsiasi rete di telecomunicazioni IP. Al fine di raggiungere livelli di sicurezza elevati, l'IMS dovrebbe comunque essere protetto anche se la sicurezza del trasporto viene violata. Pertanto, si suggeriscono le seguenti misure:
- La divulgazione di informazioni dovrebbe essere ridotta al minimo nelle richieste SIP.
- Se gli utenti IMS scoprono l'indirizzo IP di P-CSCF utilizzando query DHCP / DNS, non dovrebbero essere autorizzati a rilevare altri nodi.
- La richiesta di opzioni SIP non deve essere accettata da IMS se viene emessa da un utente, a meno che non sia necessario.
- Tutti i nodi CSCF dovrebbero essere ben rafforzati, in modo da non rivelare informazioni come il campo di intestazione del server.
- I campi di intestazione SIP che non dovrebbero essere forniti dagli utenti (come P-Visited-Network-ID) dovrebbero essere rimossi da P-CSCF.
- I campi dell'intestazione SIP forniti dagli utenti (come P-Access-Network-ID) non dovrebbero essere completamente attendibili, soprattutto se IMS può ottenere le stesse informazioni da un'altra fonte attendibile (come la rete di accesso IP).
- Poiché non ha senso che un utente (privilegiato o meno) confermi la propria identità, il campo di intestazione P-Asserted-Identity dovrebbe essere rimosso da P-CSCF se ricevuto da un utente.
- Le intestazioni aggiuntive dovrebbero essere filtrate da P-CSCF, a meno che non siano necessarie.
- HSS e altri database dovrebbero essere protetti dagli attacchi SQL injection, soprattutto in caso di input dell'utente.
- I nodi che elaborano payload XML, come P-CSCF, S-CSCF e server di presenza, dovrebbero essere ben protetti contro gli attacchi XXE.
- Ultimo ma non meno importante, l'uso di IPSec o TLS per proteggere la comunicazione tra IMS e i suoi utenti è un must. Oltre alle tecniche di prevenzione dello spoofing IP.
Infine, vorrei ringraziare Hendrik Schmidt per il suo supporto e la supervisione della mia tesi.
