STUNnion – Detecting IP Address Leaks During Tor .Onion Browsing

DeepDotWeb
DeepDotWeb

  4 Mar 2015   3

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…

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)

stun1

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.

stun2

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

3 Comments

Write a comment

  1. March 31, 2015 at 12:15 am janice

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

    0 0
    Reply this comment

    Before reply this comment! read the guidelines   X


  2. March 11, 2015 at 11:42 am last ver of tor

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

    0 0
    Reply this comment

    Before reply this comment! read the guidelines   X


    • March 16, 2015 at 9:17 am cryptostorm

      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

      0 0
      Reply this comment

      Before reply this comment! read the guidelines   X


Write a Comment

view all comments
Read before write a comment! Read the guidelines