WebRTC DoS
Dieses Problem wurde in diesem Blogbeitrag gefunden: https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/
Die beschriebene Schwachstelle in WebRTC-Medienservern ergibt sich aus einer Rennbedingung während der Initialisierung von Mediensitzungen, insbesondere zwischen der ICE-Medienzustimmungsüberprüfung und der DTLS-Verkehrsinitiierung. Hier ist eine detaillierte Aufschlüsselung:
Ursprung der Schwachstelle
UDP-Portzuweisung: Wenn ein Benutzer einen WebRTC-Anruf initiiert, weist der Medienserver UDP-Ports zur Verarbeitung der Medienströme zu, wobei die IP und der Port über Signalisierung kommuniziert werden.
ICE- und STUN-Prozesse: Der Browser des Benutzers verwendet ICE zur Überprüfung der Medienzustimmung und nutzt STUN, um den Verbindungsweg zum Medienserver zu bestimmen.
DTLS-Sitzung: Nach erfolgreicher STUN-Überprüfung beginnt eine DTLS-Sitzung, um SRTP-Master-Schlüssel zu etablieren, und wechselt zu SRTP für den Medienstream.
Ausbeutungsmechanismus
Ausnutzung der Rennbedingung: Ein Angreifer kann eine Rennbedingung ausnutzen, indem er eine DTLS ClientHello-Nachricht vor dem legitimen Benutzer sendet, möglicherweise unter Verwendung einer ungültigen Cipher-Suite wie
TLS_NULL_WITH_NULL_NULL. Dies verursacht einen DTLS-Fehler auf dem Server, wodurch die SRTP-Sitzung nicht eingerichtet werden kann.
Angriffsprozess
Port-Scanning: Der Angreifer muss erraten, welche UDP-Ports eingehende Mediensitzungen verarbeiten, und sendet ClientHello-Nachrichten mit der Null-Cipher-Suite an diese Ports, um die Schwachstelle auszulösen.
Diagramm des Angriffs: Die Sequenz umfasst mehrere ClientHello-Nachrichten, die vom Angreifer an den Server gesendet werden, die mit legitimer Signalisierung und DTLS-Nachrichten durchmischt sind, was zu einem Handshake-Fehler aufgrund der fehlerhaften Cipher-Suite führt.
Testen und Minderung
Sicheres Testen: Mit Tools wie Scapy spielen Angreifer DTLS ClientHello-Nachrichten ab, die auf bestimmte Medienports abzielen. Für ethisches Testen wurden Modifikationen an Chromium (z. B.
JsepTransport::AddRemoteCandidates) verwendet, um das Verhalten des Opfers sicher zu imitieren.Minderungsmaßnahmen: Lösungen beinhalten das Verwerfen von Paketen von nicht verifizierten Adressen, wie in neueren Versionen von Bibliotheken wie libnice implementiert. Die primäre Lösung betont das Vertrauen in den ICE-Überprüfungsprozess und die Verarbeitung von Paketen nur von validierten IP- und Portkombinationen.
Nicht anfällige Szenarien
DTLS-Serverkonfigurationen: Fälle, in denen der Browser als DTLS-Server fungiert oder wenn der Medienserver keine ephemeral Ports für Mediensitzungen verwendet, sind nicht anfällig für diese Schwachstelle.
Fazit
Diese Schwachstelle hebt das empfindliche Gleichgewicht in den Prozessen zur Initialisierung von Mediensitzungen hervor und die Notwendigkeit präziser Zeit- und Überprüfungsmechanismen, um eine Ausnutzung zu verhindern. Entwicklern wird geraten, empfohlene Sicherheitsfixes zu implementieren und robuste Überprüfungsprozesse sicherzustellen, um solche Schwachstellen zu mindern.
Last updated
