WebRTC DoS
Impara e pratica Hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica Hacking GCP: 
HackTricks Training GCP Red Team Expert (GRTE)
Questo problema è stato trovato in questo post del blog: https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/
La vulnerabilità descritta nei server multimediali WebRTC deriva da una condizione di gara durante l'inizializzazione delle sessioni multimediali, specificamente tra la verifica del consenso multimediale ICE e l'inizializzazione del traffico DTLS. Ecco un'analisi dettagliata:
Origine della Vulnerabilità
Allocazione della Porta UDP: Quando un utente avvia una chiamata WebRTC, il server multimediale alloca porte UDP per gestire i flussi multimediali, con l'IP e la porta comunicati tramite signaling.
Processi ICE e STUN: Il browser dell'utente utilizza ICE per la verifica del consenso multimediale, utilizzando STUN per determinare il percorso di connessione al server multimediale.
Sessione DTLS: Dopo una verifica STUN riuscita, inizia una sessione DTLS per stabilire le chiavi master SRTP, passando a SRTP per il flusso multimediale.
Meccanismo di Sfruttamento
Sfruttamento della Condizione di Gara: Un attaccante può sfruttare una condizione di gara inviando un messaggio DTLS ClientHello prima dell'utente legittimo, potenzialmente utilizzando una suite di cifratura non valida come
TLS_NULL_WITH_NULL_NULL. Questo causa un errore DTLS sul server, impedendo l'instaurazione della sessione SRTP.
Processo di Attacco
Scansione delle Porte: L'attaccante deve indovinare quali porte UDP gestiscono le sessioni multimediali in arrivo, inviando messaggi ClientHello con la suite di cifratura nulla a queste porte per attivare la vulnerabilità.
Diagramma dell'Attacco: La sequenza coinvolge più messaggi ClientHello inviati dall'attaccante al server, intercalati con signaling legittimo e messaggi DTLS, portando a un fallimento del handshake a causa della suite di cifratura errata.
Test e Mitigazione
Test Sicuri: Utilizzando strumenti come Scapy, gli attaccanti riproducono messaggi DTLS ClientHello mirati a porte multimediali specifiche. Per test etici, sono state utilizzate modifiche a Chromium (ad es.,
JsepTransport::AddRemoteCandidates) per imitare il comportamento della vittima in modo sicuro.Misure di Mitigazione: Le soluzioni prevedono il rifiuto dei pacchetti da indirizzi non verificati, come implementato nelle versioni più recenti di librerie come libnice. La soluzione principale enfatizza la fiducia nel processo di verifica ICE e l'elaborazione solo dei pacchetti provenienti da combinazioni IP e porta validate.
Scenari Non Vulnerabili
Configurazioni del Server DTLS: I casi in cui il browser funge da server DTLS o quando il server multimediale non utilizza porte effimere per le sessioni multimediali non sono suscettibili a questa vulnerabilità.
Conclusione
Questa vulnerabilità evidenzia l'equilibrio delicato nei processi di inizializzazione delle sessioni multimediali e la necessità di meccanismi di temporizzazione e verifica precisi per prevenire sfruttamenti. Si consiglia agli sviluppatori di implementare le correzioni di sicurezza raccomandate e garantire processi di verifica robusti per mitigare tali vulnerabilità.
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Last updated