STUNnion – Detecting IP Address Leaks During Tor .Onion Browsing

2 minute read

Posted by: DeepDotWeb

March 4, 2015

The guys from just released a new research regarding a security vulnerability that may affect and cause De-anonymization of Tor users browsing .onion sites without using the Tor Browser Bundle –  that includes the “expert” browser bundle via SOCKS proxy. The summary was shared with us and is brought to you here:

A few weeks back, as we were working on mitigating webRTC-based IP disclosures, we asked a question in twitter…

It appeared somewhat obvious to us that this information disclosure vector would work across Tor just as well a on the plaintext internet – but others in the community weren’t as sure. Since (conventional) STUN requests are sent via UDP rather than TCP, it almost looked as if Tor sessions might be ontologically protected. But of course the STUN queries don’t route across TOR; they go to a plaintext internet lookup (for the STUNnion tester, we’ve used Then they come back across Tor to the initiating server, where they present as unwelcome information disclosure.

After a bit of testing, we confirmed our suspicions and had positive test results we could consistently replicate. Since it seemed likely that a mere published announcement of webRTC over Tor would would succeed in alerting as many potential targets of this leak as possible, we went ahead and built a testing site to confirm the viability of the vector firsthand. (note: we have adhered to what we consider responsible disclosure practices in this matter)

Since we’ve noted quite a few leak testing sites that are surprisingly heavy with aggressive advertising scripts, we have chosen to publish all source code of the STUNnion test concurrently with its release; it can be found here, in full.

(╭☞ ͡° ᴥ ͡°)╭☞ …heere’s STUNnion!

stunmbj4vvnuv5pr.onion (native .onion) ( gateway)</p>

Unfortunately, it still leaves (a rough estimate of) 10% of folks visiting .onion sites via non-TBB browsers who are potentially vulnerable. There’s discussions & resources of this issue in another series of forum threads that may prove useful for those seeking additional protection strategies. Plus there’s a bunch more out there; too many to list in one place, really. tl;dr protect yourself if you’re not using TBB to access .onion resources!

We’d be remiss if we didn’t mention that the webRTC blocking heuristics in our client-side ‘widget’ have proved successful thus far in protecting against in-the-wild examples of these disclosure events. Further, we’ve implemented across-the-board denial of all STUN-based queries for .onion-directed sessions accessing Tor via our ,onion gateway service. Since torstorm operates as a true http/onion proxy, it’s able to do this kind of thing particularly effectively (source code published here). Torstorm’s about to be opened up to everyone, rather than only cryptostorm members, since we’ve recently implemented native .onion access across our entire network, via our deepDNS system of layered-security DNS resolver resources. Of course, there’s other ways to block webRTC than the methods we’ve implemented for our members – we generally recommended layering of such defences, to ensure maximum protection even in corner-state scenarios.
Thanks to everyone in the community and on our team who pitched in to help get this test ready for deployment. Here’s to the memory of Aaron Schwartz, who inspired so many of us to think creatively about big challenges. We miss you, Aaron.

~ ˣˣcstørm_teamˣˣ

Updated: 2015-03-04