WebRTC DoS

{% hint style="success" %} Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Consultez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR aux HackTricks et HackTricks Cloud dépôts github.

{% endhint %}

Ce problème a été trouvé dans cet article de blog : https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/

La vulnérabilité décrite dans les serveurs multimédias WebRTC provient d'une condition de concurrence lors de l'initialisation des sessions multimédias, spécifiquement entre la vérification du consentement multimédia ICE et l'initiation du trafic DTLS. Voici une analyse détaillée :

Origine de la vulnérabilité

Allocation de port UDP : Lorsqu'un utilisateur initie un appel WebRTC, le serveur multimédia alloue des ports UDP pour gérer les flux multimédias, avec l'IP et le port communiqués via la signalisation.
Processus ICE et STUN : Le navigateur de l'utilisateur utilise ICE pour la vérification du consentement multimédia, utilisant STUN pour déterminer le chemin de connexion vers le serveur multimédia.
Session DTLS : Après une vérification STUN réussie, une session DTLS commence pour établir des clés maîtresses SRTP, passant à SRTP pour le flux multimédia.

Mécanisme d'exploitation

Exploitation de la condition de concurrence : Un attaquant peut exploiter une condition de concurrence en envoyant un message DTLS ClientHello avant l'utilisateur légitime, utilisant potentiellement une suite de chiffrement invalide comme TLS_NULL_WITH_NULL_NULL. Cela provoque une erreur DTLS sur le serveur, empêchant l'établissement de la session SRTP.

Processus d'attaque

Analyse de port : L'attaquant doit deviner quels ports UDP gèrent les sessions multimédias entrantes, envoyant des messages ClientHello avec la suite de chiffrement nulle à ces ports pour déclencher la vulnérabilité.
Diagramme de l'attaque : La séquence implique plusieurs messages ClientHello envoyés par l'attaquant au serveur, entrecoupés de signalisation légitime et de messages DTLS, entraînant un échec de la poignée de main en raison de la suite de chiffrement erronée.

Tests et atténuation

Tests sûrs : En utilisant des outils comme Scapy, les attaquants rejouent des messages DTLS ClientHello ciblant des ports multimédias spécifiques. Pour des tests éthiques, des modifications de Chromium (par exemple, JsepTransport::AddRemoteCandidates) ont été utilisées pour imiter le comportement de la victime en toute sécurité.
Mesures d'atténuation : Les solutions impliquent de rejeter les paquets provenant d'adresses non vérifiées, comme mis en œuvre dans les versions plus récentes de bibliothèques comme libnice. La solution principale met l'accent sur la confiance dans le processus de vérification ICE et sur le traitement uniquement des paquets provenant de combinaisons IP et port validées.

Scénarios non vulnérables

Configurations de serveur DTLS : Les cas où le navigateur agit en tant que serveur DTLS ou lorsque le serveur multimédia n'utilise pas de ports éphémères pour les sessions multimédias ne sont pas susceptibles à cette vulnérabilité.

Conclusion

Cette vulnérabilité met en évidence l'équilibre délicat dans les processus d'initialisation des sessions multimédias et la nécessité de mécanismes de vérification et de synchronisation précis pour prévenir l'exploitation. Les développeurs sont conseillés de mettre en œuvre les correctifs de sécurité recommandés et de garantir des processus de vérification robustes pour atténuer de telles vulnérabilités.