WebRTC DoS

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

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

  1. 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.
  2. ICE- und STUN-Prozesse: Der Browser des Benutzers verwendet ICE zur Medienzustimmungsüberprüfung und nutzt STUN, um den Verbindungsweg zum Medienserver zu bestimmen.
  3. 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, durch legitime Signalisierungs- und DTLS-Nachrichten unterbrochen, 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.

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks