WebRTC (Web Real-Time Communication) is an open-source project that facilitates real-time audio, video, and data sharing directly between web browsers and mobile applications without the need for plugins.
Its integration into HTML5 and support across major browsers make it a versatile tool for various applications. EnableSecurity recently discovered that vulnerabilities in WebRTC implementations let threat actors trigger DoS attacks.
Vulnerabilities In WebRTC Implementations
WebRTC uses standardized protocols like “DTLS” and “SRTP” for encryption over “UDP” for low latency.
The connection process involves three main steps:-
- Signaling
- ICE media consent verification
- DTLS handshake
During signaling the peers exchange offers and answers with “ICE candidates,” “usernames,” and “passwords.”
How to Choose an ultimate Managed SIEM solution for Your Security Team -> Download Free Guide (PDF)
ICE then verifies connectivity and peer identity using STUN messages. Then a “DTLS handshake” establishes the secure connection with certificate fingerprints that are verified against those exchanged during “signaling.”
This process ensures “end-to-end encryption” and “authentication” for ‘real-time audio,’ ‘video,’ and ‘data sharing.’
While designed for “peer-to-peer communication,” WebRTC often employs intermediary servers for improved performance and NAT traversal.
The technology is vulnerable to certain DoS attacks, particularly during the transition between media consent verification and DTLS handshake phases where malicious “DTLS ClientHello” messages can disrupt connections.
This vulnerability arises when “WebRTC” treats “ICE” only as an initial “consent mechanism” rather than a “comprehensive transport mechanism.”
Malicious actors can exploit this gap by injecting a fraudulent “DTLS ClientHello” message before the “legitimate peer” can cause a “denial of service” in real-time communication services.
The issue is particularly dominant in systems using “UDP,” which lacks “inherent packet source verification.”
Vulnerable implementations include popular open-source projects like “Asterisk,” “RTPEngine,” and “FreeSWITCH,” as well as some “proprietary solutions.”
Mitigation strategies involve implementing stricter checks on the source of “DTLS ClientHello packets,” as this ensure they match the “verified ICE candidate pair.”
The study recommends updating “RFC 8826” and “RFC 8827” to include explicit guidelines for processing “DTLS ClientHello messages” in relation to “ICE-verified media streams.”
This vulnerability highlights the need for a more comprehensive understanding of “media” in WebRTC contexts, extending beyond just “RTP” to include “DTLS” and “SCTP” in ICE verification processes.
Free Webinar on How to Protect Small Businesses Against Advanced Cyberthreats -> Watch Here