18. Security Considerations (Considerazioni sulla sicurezza)

Ci sono diversi tipi di attacchi possibili in un sistema ICE. Questa sezione considera questi attacchi e le loro contromisure. Queste contromisure includono:

• Utilizzo di ICE in combinazione con tecniche di segnalazione sicure, come SIPS.

• Limitare il numero totale di controlli di connettività a 100 e facoltativamente limitare il numero di candidati che accetteranno in un'offerta o risposta.

18.1. Attacks on Connectivity Checks (Attacchi ai controlli di connettività)

Un aggressore potrebbe tentare di interrompere i controlli di connettività STUN. In definitiva, tutti questi attacchi ingannano un agente facendogli pensare qualcosa di errato sui risultati dei controlli di connettività. Le possibili false conclusioni che un aggressore può provare a causare sono:

False Invalid (Falso non valido): : Un aggressore può ingannare una coppia di agenti facendo loro pensare che una coppia di candidati non sia valida, quando non lo è. Questo può essere utilizzato per far sì che un agente preferisca un candidato diverso (come uno iniettato dall'aggressore) o per interrompere una chiamata forzando il fallimento di tutti i candidati.

False Valid (Falso valido): : Un aggressore può ingannare una coppia di agenti facendo loro pensare che una coppia di candidati sia valida, quando non lo è. Questo può far sì che un agente proceda con una sessione, ma poi non sia in grado di ricevere alcun supporto.

False Peer Reflexive Candidate (Falso candidato peer reflexive): : Un aggressore può far scoprire a un agente un nuovo candidato peer reflexive, quando non avrebbe dovuto. Questo può essere utilizzato per reindirizzare i flussi multimediali verso un obiettivo Denial-of-Service (DoS) o verso l'aggressore, per intercettazioni o altri scopi.

False Valid on False Candidate (Falso valido su falso candidato): : Un aggressore ha già convinto un agente che esiste un candidato con un indirizzo che non instrada effettivamente a quell'agente (ad esempio, iniettando un falso candidato peer reflexive o un falso candidato server reflexive). Deve quindi lanciare un attacco che costringa gli agenti a credere che questo candidato sia valido.

Se un aggressore può causare un falso candidato peer reflexive o un falso valido su un falso candidato, può lanciare uno qualsiasi degli attacchi descritti in [RFC5389].

Per forzare il risultato falso non valido, l'aggressore deve attendere l'invio del controllo di connettività da parte di uno degli agenti. Quando lo è, l'aggressore deve iniettare una risposta falsa con una risposta di errore irreversibile, come un 400. Tuttavia, poiché il candidato è, in effetti, valido, la richiesta originale potrebbe raggiungere l'agente peer e risultare in una risposta di successo. L'aggressore deve forzare l'eliminazione di questo pacchetto o della sua risposta, attraverso un attacco DoS, un'interruzione della rete di livello 2 o un'altra tecnica. Se non lo fa, la risposta di successo raggiungerà anche l'autore, avvisandolo di un possibile attacco. Fortunatamente, questo attacco è mitigato completamente attraverso il meccanismo delle credenziali a breve termine STUN. L'aggressore deve iniettare una risposta falsa e, affinché questa risposta venga elaborata, l'aggressore ha bisogno della password. Se la segnalazione offerta/risposta è protetta, l'aggressore non avrà la password e la sua risposta verrà scartata.

Forzare il risultato falso valido funziona in modo simile. L'agente deve attendere la richiesta Binding da ciascun agente e iniettare una falsa risposta di successo. L'aggressore non dovrà preoccuparsi di interrompere la risposta effettiva poiché, se il candidato non è valido, presumibilmente non verrebbe comunque ricevuto. Tuttavia, come l'attacco falso non valido, questo attacco è mitigato dal meccanismo delle credenziali a breve termine STUN in combinazione con uno scambio offerta/risposta sicuro.

Forzare il risultato del falso candidato peer reflexive può essere fatto con false richieste o risposte o con replay. Consideriamo prima il caso delle false richieste e risposte. Richiede all'aggressore di inviare una richiesta Binding a un agente con un indirizzo IP di origine e una porta per il falso candidato. Inoltre, l'aggressore deve attendere una richiesta Binding dall'altro agente e generare una risposta falsa con un attributo XOR-MAPPED-ADDRESS contenente il falso candidato. Come gli altri attacchi descritti qui, questo attacco è mitigato dai meccanismi di integrità del messaggio STUN e dagli scambi offerta/risposta sicuri.

Forzare il risultato del falso candidato peer reflexive con i replay dei pacchetti è diverso. L'aggressore attende fino a quando uno degli agenti invia un controllo. Intercetta questa richiesta e la riproduce verso l'altro agente con un indirizzo IP di origine falsificato. Deve anche impedire che la richiesta originale raggiunga l'agente remoto, lanciando un attacco DoS per causare l'eliminazione del pacchetto o forzandone l'eliminazione utilizzando meccanismi di livello 2. Il pacchetto riprodotto viene ricevuto dall'altro agente e accettato, poiché il controllo di integrità passa (il controllo di integrità non può e non copre l'indirizzo IP di origine e la porta). Viene quindi risposto. Questa risposta conterrà un XOR-MAPPED-ADDRESS con il falso candidato e verrà inviata a quel falso candidato. L'aggressore deve quindi riceverla e inoltrarla all'autore.

L'altro agente avvierà quindi un controllo di connettività verso quel falso candidato. Questa convalida deve avere successo. Ciò richiede che l'aggressore forzi un falso valido su un falso candidato. L'iniezione di false richieste o risposte per raggiungere questo obiettivo viene impedita utilizzando i meccanismi di integrità di STUN e lo scambio offerta/risposta. Pertanto, questo attacco può essere lanciato solo tramite replay. Per fare ciò, l'aggressore deve intercettare il controllo verso questo falso candidato e riprodurlo verso l'altro agente. Quindi, deve intercettare la risposta e riprodurla anche quella.

Questo attacco è molto difficile da lanciare a meno che l'aggressore non sia identificato dal falso candidato. Questo perché richiede all'aggressore di intercettare e riprodurre i pacchetti inviati da due host diversi. Se entrambi gli agenti si trovano su reti diverse (ad esempio, attraverso Internet pubblico), questo attacco può essere difficile da coordinare, poiché deve verificarsi contro due diversi endpoint su parti diverse della rete contemporaneamente.

Se l'aggressore stesso è identificato dal falso candidato, l'attacco è più facile da coordinare. Tuttavia, se viene utilizzato SRTP [RFC3711], l'aggressore non sarà in grado di riprodurre i pacchetti multimediali, ma sarà in grado solo di scartarli, disabilitando efficacemente il flusso multimediale per la chiamata. Tuttavia, questo attacco richiede che l'agente interrompa i pacchetti per impedire al controllo di connettività di raggiungere l'obiettivo. In tal caso, se l'obiettivo è interrompere il flusso multimediale, è molto più facile interromperlo semplicemente con lo stesso meccanismo, piuttosto che attaccare ICE.

18.2. Attacks on Server Reflexive Address Gathering (Attacchi alla raccolta di indirizzi server reflexive)

Gli endpoint ICE fanno uso delle richieste STUN Binding per raccogliere candidati server reflexive da un server STUN. Queste richieste non sono autenticate in alcun modo. Di conseguenza, esistono numerose tecniche che un aggressore può impiegare per fornire al client un falso candidato server reflexive:

• Un aggressore può compromettere il DNS, facendo sì che le query DNS restituiscano un indirizzo del server STUN canaglia. Quel server può fornire al client falsi candidati server reflexive. Questo attacco è mitigato dalla sicurezza DNS, sebbene DNS-SEC non sia richiesto per affrontarlo.

• Un aggressore che può osservare i messaggi STUN (come un aggressore su un segmento di rete condiviso, come il WiFi) può iniettare una risposta falsa che è valida e verrà accettata dal client.

• Un aggressore può compromettere un server STUN tramite un virus e fargli inviare risposte con indirizzi mappati errati.

Un falso indirizzo mappato appreso da questi attacchi verrà utilizzato come candidato server reflexive nello scambio ICE. Affinché questo candidato venga effettivamente utilizzato per i media, l'aggressore deve anche attaccare i controlli di connettività e, in particolare, forzare un falso valido su un falso candidato. Questo attacco è molto difficile da lanciare se il falso indirizzo identifica una quarta parte (né l'offerente, né il risponditore, né l'aggressore), poiché richiede di attaccare i controlli generati da ciascun agente nella sessione, ed è impedito da SRTP se identifica l'aggressore stesso.

Se l'aggressore sceglie di non attaccare i controlli di connettività, il peggio che può fare è impedire l'utilizzo del candidato server reflexive. Tuttavia, se l'agente peer ha almeno un candidato raggiungibile dall'agente sotto attacco, i controlli di connettività STUN stessi forniranno un candidato peer reflexive che può essere utilizzato per lo scambio di media. I candidati peer reflexive sono generalmente preferiti ai candidati server reflexive. Pertanto, un attacco esclusivamente alla raccolta di indirizzi STUN non avrà normalmente alcun impatto su una sessione.

18.3. Attacks on Relayed Candidate Gathering (Attacchi alla raccolta di candidati relayed)

Un aggressore potrebbe tentare di interrompere la raccolta di candidati relayed, costringendo il client a credere di avere un falso candidato relayed. Gli scambi con il server TURN sono autenticati utilizzando una credenziale a lungo termine. Di conseguenza, l'iniezione di risposte o richieste false non funzionerà. Inoltre, a differenza delle richieste Binding, le richieste Allocate non sono suscettibili agli attacchi di replay con indirizzi IP e porte di origine modificati, poiché l'indirizzo IP e la porta di origine non vengono utilizzati per fornire al client il suo candidato relayed.

Tuttavia, i server TURN sono suscettibili agli attacchi DNS o ai virus diretti al server TURN, allo scopo di trasformarlo in uno zombie o in un server canaglia. Questi attacchi possono essere mitigati da DNS-SEC e attraverso una buona sicurezza della scatola e del software sui server TURN.

Anche se un aggressore ha indotto il client a credere in un falso candidato relayed, i controlli di connettività fanno sì che tale candidato venga utilizzato solo se hanno successo. Pertanto, un aggressore deve lanciare un falso valido su un falso candidato, come sopra, che è un attacco molto difficile da coordinare.

18.4. Attacks on the Offer/Answer Exchanges (Attacchi agli scambi offerta/risposta)

Un aggressore in grado di modificare o interrompere gli scambi offerta/risposta stessi può lanciare prontamente una varietà di attacchi con ICE. Potrebbero dirigere i media verso un obiettivo di un attacco DoS, potrebbero inserirsi nel flusso multimediale e così via. Queste sono simili alle considerazioni generali sulla sicurezza per gli scambi offerta/risposta e si applicano le considerazioni sulla sicurezza in RFC 3264 [RFC3264]. Queste richiedono tecniche per l'integrità del messaggio e la crittografia per offerte e risposte, che sono soddisfatte dal meccanismo SIPS [RFC3261] quando viene utilizzato SIP. Pertanto, l'utilizzo di SIPS con ICE è RECOMMENDED.

18.5. Insider Attacks (Attacchi interni)

Oltre agli attacchi in cui l'aggressore è una terza parte che cerca di inserire offerte, risposte o messaggi stun falsi, ci sono diversi attacchi possibili con ICE quando l'aggressore è un partecipante autenticato e valido allo scambio ICE.

18.5.1. The Voice Hammer Attack (L'attacco Voice Hammer)

L'attacco voice hammer è un attacco di amplificazione. In questo attacco, l'aggressore avvia sessioni verso altri agenti e include maliziosamente l'indirizzo IP e la porta di un obiettivo DoS come destinazione per il traffico multimediale segnalato nell'SDP. Ciò causa una notevole amplificazione; un singolo scambio offerta/risposta può creare un'inondazione continua di pacchetti multimediali, possibilmente a velocità elevate (considerare le sorgenti video). Questo attacco non è specifico per ICE, ma ICE può aiutare a fornire rimedio.

Nello specifico, se viene utilizzato ICE, l'agente che riceve l'SDP dannoso eseguirà prima controlli di connettività verso la destinazione dei media prima di inviare media lì. Se questo obiettivo è un host di terze parti, i controlli non avranno successo e i media non verranno mai inviati.

Sfortunatamente, ICE non aiuta se non viene utilizzato, nel qual caso un aggressore potrebbe semplicemente inviare l'offerta senza i parametri ICE. Tuttavia, negli ambienti in cui l'insieme di client è noto ed è limitato a quelli che supportano ICE, il server può rifiutare qualsiasi offerta o risposta che non indichi il supporto ICE.

18.5.2. STUN Amplification Attack (Attacco di amplificazione STUN)

L'attacco di amplificazione STUN è simile al voice hammer. Tuttavia, invece di indirizzare i pacchetti vocali verso l'obiettivo, i controlli di connettività STUN sono diretti all'obiettivo. L'aggressore invia un'offerta con un gran numero di candidati, diciamo 50. Il risponditore riceve l'offerta e inizia i suoi controlli, che sono diretti all'obiettivo e, di conseguenza, non generano mai una risposta. Il risponditore avvierà un nuovo controllo di connettività ogni Ta ms (diciamo, Ta=20 ms). Tuttavia, i timer di ritrasmissione sono impostati su un numero elevato a causa del gran numero di candidati. Di conseguenza, i pacchetti verranno inviati a un intervallo di uno ogni Ta millisecondi e quindi con intervalli crescenti dopo quello. Pertanto, STUN non invierà pacchetti a una velocità maggiore di quella con cui verrebbero inviati i media e i pacchetti STUN persistono solo brevemente, fino a quando ICE non fallisce per la sessione. Tuttavia, questo è un meccanismo di amplificazione.

È impossibile eliminare l'amplificazione, ma il volume può essere ridotto attraverso una varietà di euristiche. Gli agenti SHOULD limitare il numero totale di controlli di connettività che eseguono a 100. Inoltre, gli agenti MAY limitare il numero di candidati che accetteranno in un'offerta o risposta.

Frequentemente, i protocolli che desiderano evitare questo tipo di attacchi costringono l'iniziatore ad attendere una risposta prima di inviare il messaggio successivo. Tuttavia, nel caso di ICE, questo non è possibile. Non è possibile differenziare i seguenti due casi:

• Non c'è stata risposta perché l'iniziatore viene utilizzato per lanciare un attacco DoS contro un bersaglio ignaro che non risponderà.

• Non c'è stata risposta perché l'indirizzo IP e la porta non sono raggiungibili dall'iniziatore.

Nel secondo caso, un altro controllo dovrebbe essere inviato alla prossima opportunità, mentre nel primo caso, non dovrebbero essere inviati ulteriori controlli.

18.6. Interactions with Application Layer Gateways and SIP (Interazioni con gateway a livello di applicazione e SIP)

I gateway a livello di applicazione (ALG) sono funzioni presenti in un dispositivo NAT che ispezionano il contenuto dei pacchetti e li modificano, al fine di facilitare l'attraversamento NAT per i protocolli applicativi. I controller di bordo di sessione (SBC) sono cugini stretti degli ALG, ma sono meno trasparenti poiché esistono effettivamente come intermediari SIP a livello di applicazione. ICE ha interazioni con SBC e ALG.

Se un ALG è consapevole di SIP ma non di ICE, ICE funzionerà attraverso di esso purché l'ALG modifichi correttamente l'SDP. Un'implementazione ALG corretta si comporta come segue:

• L'ALG non modifica le righe m e c o l'attributo rtcp se contengono indirizzi esterni.

• Se le righe m e c contengono indirizzi interni, la modifica dipende dallo stato dell'ALG:

  Se l'ALG ha già un'associazione stabilita che mappa una porta esterna a un indirizzo IP interno e una porta corrispondenti ai valori nelle righe m e c o nell'attributo rtcp, l'ALG utilizza quell'associazione invece di crearne una nuova.

  Se l'ALG non ha già un'associazione, ne crea una nuova e modifica l'SDP, riscrivendo le righe m e c e l'attributo rtcp.

Sfortunatamente, è noto che molti ALG funzionano male in questi casi limite. ICE non tenta di aggirare gli ALG rotti, poiché ciò non rientra nell'ambito della sua funzionalità. ICE può aiutare a diagnosticare queste condizioni, che spesso si presentano come una mancata corrispondenza tra l'insieme di candidati e le righe m e c e gli attributi rtcp. L'attributo ice-mismatch viene utilizzato per questo scopo.

ICE funziona meglio attraverso gli ALG quando la segnalazione viene eseguita su TLS. Ciò impedisce all'ALG di manipolare i messaggi SDP e interferire con il funzionamento di ICE. Le implementazioni che dovrebbero essere distribuite dietro gli ALG SHOULD prevedere il trasporto TLS dell'SDP.

Se un SBC è consapevole di SIP ma non di ICE, il risultato dipende dal comportamento dell'SBC. Se agisce come un corretto Back-to-Back User Agent (B2BUA), l'SBC rimuoverà tutti gli attributi SDP che non comprende, inclusi gli attributi ICE. Di conseguenza, la chiamata apparirà a entrambi gli endpoint come se l'altra parte non supportasse ICE. Ciò comporterà la disabilitazione di ICE e il flusso dei media attraverso l'SBC, se l'SBC lo ha richiesto. Se, tuttavia, l'SBC passa gli attributi ICE senza modifiche, ma modifica la destinazione predefinita per i media (contenuta nelle righe m e c e nell'attributo rtcp), ciò verrà rilevato come una mancata corrispondenza ICE e l'elaborazione ICE viene interrotta per la chiamata. Non rientra nell'ambito di ICE agire come strumento per "aggirare" gli SBC. Se ne è presente uno, ICE non verrà utilizzato e le tecniche SBC hanno la precedenza.