16. Security Considerations (Considerazioni sulla sicurezza)
16.1. Attacks against the Protocol (Attacchi contro il protocollo)
16.1.1. Outside Attacks (Attacchi esterni)
Un attaccante può tentare di modificare i messaggi STUN in transito, al fine di causare il fallimento di un'operazione STUN. Questi attacchi contro richieste e risposte possono essere rilevati attraverso il meccanismo di integrità dei messaggi, utilizzando credenziali a breve o lungo termine. Naturalmente, una volta rilevati, i pacchetti manipolati verranno scartati, causando il fallimento effettivo della transazione STUN. Questo attacco può essere lanciato solo da un attaccante sul percorso.
Un attaccante che può osservare, ma non modificare, i messaggi STUN in transito (ad esempio, un attaccante presente su un mezzo di accesso condiviso, come Wi-Fi) può vedere una richiesta STUN e quindi inviare immediatamente una risposta STUN, tipicamente una risposta di errore, al fine di interrompere l'elaborazione STUN. Per i messaggi con MESSAGE-INTEGRITY, anche questo attacco è prevenuto. Tuttavia, alcune risposte di errore, specificamente quelle relative all'autenticazione, non possono essere protette da MESSAGE-INTEGRITY. Quando STUN stesso viene eseguito su un protocollo di trasporto sicuro, come TLS, questi attacchi sono completamente mitigati.
A seconda dell'utilizzo STUN, questi attacchi possono avere conseguenze minime e quindi l'integrità dei messaggi potrebbe non essere necessaria per contrastarli. Ad esempio, quando STUN viene utilizzato con un server STUN di base per scoprire un candidato riflesso dal server per l'uso con ICE, l'autenticazione e l'integrità dei messaggi non sono necessarie, poiché questi attacchi vengono rilevati durante la fase di verifica della connettività. Tuttavia, i controlli di connettività stessi richiedono protezione affinché ICE funzioni correttamente nel complesso. Come discusso nella Sezione 14, un utilizzo STUN descrive quando l'autenticazione e l'integrità dei messaggi sono necessarie.
Poiché STUN utilizza HMAC con un segreto condiviso per l'autenticazione e la protezione dell'integrità, è suscettibile ad attacchi di dizionario offline. Quando viene utilizzata l'autenticazione, le password dovrebbero (SHOULD) essere scelte in modo da non essere soggette a tali attacchi di dizionario offline. Proteggere il canale stesso utilizzando TLS può mitigare questi attacchi. Tuttavia, STUN viene più comunemente eseguito su UDP, e in questi casi, le password forti sono l'unica difesa contro questi attacchi.
16.1.2. Inside Attacks (Attacchi interni)
Un client malevolo potrebbe tentare di lanciare un attacco DoS contro un server inviandogli un gran numero di richieste STUN. Fortunatamente, le richieste STUN possono essere elaborate senza stato da un server, rendendo difficili tali attacchi.
Un client malevolo può utilizzare un server STUN come riflettore, inviandogli richieste con un indirizzo IP e una porta sorgente falsificati. In questo caso, la risposta verrebbe consegnata a quell'IP e porta sorgente. Non c'è amplificazione del numero di pacchetti con questo attacco (il server STUN invia un pacchetto per ogni pacchetto inviato dal client), sebbene ci sia una piccola amplificazione della quantità di dati, poiché le risposte STUN sono tipicamente più grandi delle richieste. Il filtraggio dell'indirizzo sorgente in ingresso può aiutare a mitigare questo attacco.
Rivelare la versione software specifica dell'agente attraverso l'attributo SOFTWARE potrebbe consentire a un attaccante di lanciare attacchi più facilmente contro software noto per contenere falle di sicurezza. Gli implementatori dovrebbero (SHOULD) rendere l'uso dell'attributo SOFTWARE un'opzione configurabile.
16.2. Attacks Affecting the Usage (Attacchi che influenzano l'utilizzo)
Questa sezione elenca gli attacchi che potrebbero essere lanciati contro un utilizzo STUN. Ogni utilizzo STUN deve (must) considerare se questi attacchi sono applicabili e, in tal caso, discutere le contromisure.
La maggior parte degli attacchi in questa sezione ruota attorno a un attaccante che modifica l'indirizzo riflesso appreso dal client STUN attraverso una transazione richiesta/risposta Binding. Poiché l'uso dell'indirizzo riflesso è una funzione dell'utilizzo, l'applicabilità e i rimedi per questi attacchi sono specifici dell'utilizzo. Nel caso più comune, un attaccante sul percorso può facilmente modificare l'indirizzo riflesso. Consideriamo, ad esempio, il caso comune di STUN eseguito direttamente su UDP. In questo caso, un attaccante sul percorso può modificare l'indirizzo IP sorgente della richiesta Binding prima che arrivi al server STUN. Il server STUN restituirà quindi questo indirizzo IP nell'attributo XOR-MAPPED-ADDRESS al client e invierà la risposta a quell'indirizzo IP e porta (falsificati). Se l'attaccante può anche intercettare questa risposta, può reindirizzarla al client. Proteggersi da questo attacco utilizzando un controllo di integrità dei messaggi è impossibile, poiché il valore di integrità dei messaggi non può coprire l'indirizzo IP sorgente, poiché deve essere modificabile dai NAT intermedi. Invece, una soluzione per prevenire gli attacchi elencati di seguito è che il client verifichi l'indirizzo riflesso appreso, come viene fatto in ICE [MMUSIC-ICE]. Altri utilizzi possono utilizzare altri mezzi per prevenire questi attacchi.
16.2.1. Attack I: Distributed DoS (DDoS) against a Target (Attacco DDoS distribuito contro un obiettivo)
In questo attacco, l'attaccante fornisce a uno o più client lo stesso indirizzo riflesso falsificato che punta a un obiettivo previsto. Questo ingannerà i client STUN facendo loro credere che i loro indirizzi riflessi siano uguali a quello dell'obiettivo. Se i client distribuiscono quell'indirizzo riflesso per ricevere traffico su di esso (ad esempio, in un messaggio SIP), il traffico verrà invece inviato all'obiettivo. Questo attacco può fornire un'amplificazione sostanziale, specialmente quando utilizzato con client che stanno usando STUN per abilitare applicazioni multimediali. Tuttavia, può essere lanciato solo contro un obiettivo per il quale i pacchetti dal server STUN all'obiettivo passano attraverso l'attaccante, limitando i casi in cui è possibile.
16.2.2. Attack II: Silencing a Client (Silenziare un client)
In questo attacco, l'attaccante fornisce a un client STUN un indirizzo riflesso falsificato. L'indirizzo riflesso fornito è un indirizzo di trasporto che non porta da nessuna parte. Di conseguenza, il client non riceverà nessuno dei pacchetti che si aspetta di ricevere quando distribuisce l'indirizzo riflesso. Questo exploit non è molto interessante per l'attaccante. Colpisce un singolo client, che spesso non è l'obiettivo desiderato. Inoltre, qualsiasi attaccante che può montare l'attacco può lanciare attacchi DoS più efficaci contro il client in altri modi, come impedendo al client di ricevere qualsiasi risposta dal server STUN, o anche da un server DHCP. Come con l'attacco nella Sezione 16.2.1, questo attacco è possibile solo quando l'attaccante è sul percorso dei pacchetti inviati dal server STUN verso questo indirizzo IP inutilizzato.
16.2.3. Attack III: Assuming the Identity of a Client (Assumere l'identità di un client)
Questo attacco è simile all'attacco II. Tuttavia, l'indirizzo riflesso falsificato punta all'attaccante stesso. Questo consente all'attaccante di ricevere il traffico destinato al client.
16.2.4. Attack IV: Eavesdropping (Intercettazione)
In questo attacco, l'attaccante forza il client a utilizzare un indirizzo riflesso che indirizza a se stesso. Quindi inoltra tutti i pacchetti che riceve al client. Questo attacco consentirebbe a un attaccante di osservare tutti i pacchetti inviati al client. Tuttavia, per lanciare l'attacco, l'attaccante deve aver già potuto osservare i pacchetti dal client al server STUN. Nella maggior parte dei casi (come quando l'attacco viene lanciato da una rete di accesso), questo significa che l'attaccante poteva già osservare i pacchetti inviati al client. Questo attacco è quindi utile solo per osservare il traffico da parte di attaccanti sul percorso dal client al server STUN ma non generalmente sul percorso dei pacchetti indirizzati al client.
16.3. Hash Agility Plan (Piano di agilità hash)
Questa specifica utilizza HMAC-SHA-1 per il calcolo dell'integrità dei messaggi. Se, in futuro, HMAC-SHA-1 dovesse risultare compromesso, può essere applicata la seguente correzione.
Definiremo un'estensione STUN che introduce un nuovo attributo di integrità dei messaggi calcolato utilizzando un nuovo hash. I client dovrebbero includere sia il nuovo che il vecchio attributo di integrità dei messaggi nelle loro richieste o indicazioni. I nuovi server utilizzerebbero il nuovo attributo di integrità dei messaggi, e i vecchi server utilizzerebbero quello vecchio. Dopo un periodo di transizione in cui vengono distribuite implementazioni miste, il vecchio attributo di integrità dei messaggi verrà deprecato da un'altra specifica, e i client cesserebbero di includerlo nelle richieste.
È anche importante notare che la chiave utilizzata da HMAC è essa stessa calcolata utilizzando un hash del nome utente e della password. La scelta dell'hash MD5 è stata fatta per l'archiviazione legacy di password in questa forma nei database. Se, in futuro, il lavoro scopre che l'uso di HMAC con input MD5 non è sicuro, e un hash diverso è necessario, questo piano può essere utilizzato anche per quel cambiamento. Tuttavia, ciò richiederebbe agli amministratori di ripopolare i loro database.