Home » Featured » STUNnion – Detecting IP Address Leaks During Tor .Onion Browsing
Click Here To Hide Tor

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:

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 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)

stun2We’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.

~ ˣˣcstørm_teamˣˣ


  1. The site nothing reveals only webrowser …
    Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.

    • Most likely, that means the browser you are using is properly locked-down and either has webRTC fully disabled, or entirely compiled out (as in the Tor Browser Bundle). In the TBB case, that’s a good thing and is reliably secure.

      When it comes to disabling webRTC in browsers, either via extension or via parameter changes, there are published workarounds that can once again enable it on a per-session basis and reveal IP.

      In any case, “passing” the STUNnion test – not showing any IPs, or show a “public” IP that is of a network security service – is a good thing. We’d like to think nobody will fail – show a leak of public IP – but unfortunately we know that’s not the case.

      STUNnion is only one proof of concept of an entire class of browser leaks that exist and are being actively exploited in the wild. We’re doing our best to ensure these attack vectors are well understood in the community, so that folks can mitigate risks and take appropriate defensive measures.

      ~ cryptostorm

  2. Why does it show windows when I’m not using windows ?

    • It’s because of the user-agent. Tor Browser uses a general user agent and the websites see the user as he was coming from “Windows”.

      Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Leave a Reply

Your email address will not be published. Required fields are marked *


Captcha: *