WebRTC DoS

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

This issue was found in this blog post: https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/

The described vulnerability in WebRTC media servers arises from a race condition during the initialization of media sessions, specifically between the ICE media consent verification and the DTLS traffic initiation. Here’s a detailed breakdown:

Vulnerability Origin

UDP Port Allocation: When a user initiates a WebRTC call, the media server allocates UDP ports for handling the media streams, with the IP and port communicated via signaling.
ICE and STUN Processes: The user's browser uses ICE for media consent verification, utilizing STUN to determine the connection path to the media server.
DTLS Session: Following successful STUN verification, a DTLS session starts to establish SRTP master keys, switching to SRTP for the media stream.

Exploitation Mechanism

Race Condition Exploitation: An attacker can exploit a race condition by sending a DTLS ClientHello message before the legitimate user, potentially using an invalid cipher suite like TLS_NULL_WITH_NULL_NULL. This causes a DTLS error at the server, preventing the SRTP session from being established.

Attack Process

Port Scanning: The attacker needs to guess which UDP ports are handling incoming media sessions, sending ClientHello messages with the null cipher suite to these ports to trigger the vulnerability.
Diagram of Attack: The sequence involves multiple ClientHello messages sent by the attacker to the server, interleaved with legitimate signaling and DTLS messages, leading to a handshake failure due to the erroneous cipher suite.

Testing and Mitigation

Safe Testing: Using tools like Scapy, attackers replay DTLS ClientHello messages targeting specific media ports. For ethical testing, modifications to Chromium (e.g., JsepTransport::AddRemoteCandidates) were used to mimic victim behavior safely.
Mitigation Measures: Solutions involve dropping packets from unverified addresses, as implemented in newer versions of libraries like libnice. The primary solution emphasizes trusting the ICE verification process and only processing packets from validated IP and port combinations.

Non-Vulnerable Scenarios

DTLS Server Configurations: Instances where the browser acts as a DTLS server or when the media server does not use ephemeral ports for media sessions are not susceptible to this vulnerability.

Conclusion

This vulnerability highlights the delicate balance in media session initialization processes and the need for precise timing and verification mechanisms to prevent exploitation. Developers are advised to implement recommended security fixes and ensure robust verification processes to mitigate such vulnerabilities.