STUNnion - webrtc IP de-obfuscation of Tor .onion site visitors

To stay ahead of new and evolving threats, cryptostorm has always looked out past standard network security tools. Here, we discuss and fine-tune our work in bringing newly-created capabilities and newly-discovered knowledge to bear as we keep cryptostorm in the forefront of tomorrow's network security landscape.

STUNnion - webrtc IP de-obfuscation of Tor .onion site visitors

Post by cryptostorm_team » Wed Mar 04, 2015 9:31 am

{direct link: | src: }

As a supplement to the STUNnion webrtc-over-Tor testing tool (native .onion URL | torstorm URL), we've collected some prior work on this subject here, both to provide additional material for folks curious and to thank those who had seen this as a topic of concern before we noticed it, too.

We also wanted to thank the good folks at the Tor Project for being well out in front of this, as is often the case. The Tor Browser Bundle - standard for many visitors to .onion sites, has compiled without webRTC capability for several years. As a result, folks using the TBB are fully protected from STUN-based IP leaks. That's excellent work, and shows both foresight and attention to real-world security matters. Nicely done!

Without further ado, here's some prior writing on the topic of .onion-hosted STUN attacks:

* Just last month, Daniel Wendler wrote this short piece on the topic: "WebRTC deanonymizing Tor / VPN / Proxy users"
Software engineer Daniel Roesler recently discovered how the WebRTC implementation in Mozilla Firefox and Chrome expose your real WAN IP to the website you visit.

The Tor Browser Bundle does currently block WebRTC by default (or at least the demo doesn’t work).

When I use Tor through the normal Firefox / Chrome, my real IP is getting exposed to the website.

How does the Tor Socksproxy ( handle non-http request?
As far as our testing has shown, Socksproxy does pass STUN queries... but we'd prefer others validate that finding, first. We're also collecting pcaps to verify packet-level characteristics, but didn't want to hold off on publishing longer than necessary, so we'll append those data to this thread.

* Barely a week ago, Ian Harris wrote this excellent piece on the topic: "Excuse me Sir, Your WebRTC is Leaking." It's got some useful advice on browser-specific settings modifications to protect against these leaks, although he points out that a long-term solution is ideally achieved via user-based explicit authorisation of STUN queries (which, unfortunately, isn't likely to happen):
Long term the ideal solution would be to have a user prompt whenever a WebRTC connection is being requested. This would be similar to the prompt requesting a user to authorise access to the camera and microphone. However, this solution relies on such a mechanism being mandated in the specifications and implemented by your browser provider.

* David Huerta's questions last summer about STUN over Tor produced a lively discussion, and much useful insight: "WebRTC via TorReport"
I've been experimenting with using WebRTC in a browser using Tor with Twilio to see if it's not totally impossible to do voice communication
in a way that anonymizes location (source IP). The problem is that Twilio WebRTC requires UDP connections over ports 10,000 to 60,000 and at least from my research (correct me if I'm wrong), Tor doesn't do onion routing for UDP traffic. As an alternative to WebRTC, there does seem to be a Twilio Client Flash option* which is TCP-only, but eww Flash. Any ideas on how to shoehorn UDP traffic into Tor-friendly TCP or do something else that would produce basically the same effect?

* Finally, in terms of what we found most directly relevant, the Tor Project has been actively discussing and mitigating against Tor-based STUN leaks for quite some time; a good starting point for the various projects & discussions around this topic is found in "Tor Weekly News — February 11th, 2015"
Even though Tor Browser is not vulnerable to the recent WebRTC IP attack proof-of-concept proof-of-concept, Mike Perry nevertheless invited “interested parties to try harder to bypass Tor in a stock Firefox using WebRTC and associated protocols (RTSP, SCTP) with media.peerconnection.enabled set to false”, before a plan to enable WebRTC-based QRCode bridge address resolution and sharing in Tor Launcher is implemented.

* This, in turn, links out to several related discussions:

While far from complete, we hope these summary resources will serve as a good starting point for those seeking to dig deeper into the topic. Additionally, our webRTC threads here in the forum have quite a bit of collected data and pointers to the underlying technologies and concepts involved.

Thanks again to everyone who did the prior work in this area. We merely bolted it together in a way that helps spotlight some places where additional risk mitigation is warranted.

Best regards,
  • ~ cryptostorm_team