STUNnion – Detecting IP Address Leaks During Tor .Onion Browsing
The guys from Cryptostorm.is 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:
So what happens to out-of-channel "NAT-busting" webRTC parallel-universe funky-packets going across Tor? @i2p? Hyperboria/cjdns? Any papers?
— cryptostorm〰cstørmˣˣ (@cryptostorm_is) February 21, 2015
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 stun:stun.services.mozilla.com). 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)
stunmbj4vvnuv5pr.torstorm.org (torstorm.org gateway)
We’ve posted full attribution for all prior work in this forum thread but we’d like to mention in particular the work of Daniel Roesler on webRTC_ips & the foresight of the Tor Project in ensuring that the Tor Browser Bundle is 100% protected against this class of disclosures by removing webRTC support entirely, pre-compile: excellent work.
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 torstorm.org ,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.