Hacker News Reader

Comment by cjbprime | Hacker News Reader

We should be clear that this isn't a vulnerability in the Tor software or network, but an (apparent) vulnerability in this unrelated "Freedom Hosting" company's site:

https://blog.torproject.org/blog/hidden-services-current-eve...

View on HN

Not according to TFA:

"In this paper we expose flaws both in the design and implementation of Tor’s hidden services that allow an attacker to measure the popularity of arbitrary hidden services, take down hidden services and deanonymize hidden services Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization"

http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

The author never explained how the contents of that paper were related to the js attack on freedomhost users. It just seemed like an aside about the security of the Tor network in general. Since they (allegedly) found the guy running freedomhosting, maybe they were using those cookies to do a traffic correlation attack to find the host?

And possibly in Firefox (!), with some sort of JavaScript exploit. This is the most worrying part for me--does anyone have any info on what the payload does?

Doesn't have to do much. Once you execute pretty much any (non-sandboxed) code on a machine, you can bypass something like TOR easily. From this point, any network packet sent by the payload to the feds effectively de-anonymizes the user completely. Also, by including a tracking cookie in the JS, they can cross reference all user activity on the compromised websites with the newly discovered IP address.

I still don't understand this concept. Any iframe or JS executed is still going through Tor. They'd need to load up Chrome or start another Firefox process.

The point is the iframe/JS is used to break out of the browser sandbox, due to a bug in the browser, with techniques like heap spraying (mentioned in the article).

Once you manage to get arbitrary code running in the context of the browser, you can do anything the browser can, including (presumably) making raw non-TOR connections to anywhere, identifying the TOR user and correlating that with what they were doing over TOR.

Among other things like installing arbitrary malware kits that completely compromise the machine.

That's why there are things like Whonix

> Once you execute pretty much any (non-sandboxed) code on a machine, you can bypass something like TOR easily. From this point, any network packet sent by the payload to the feds effectively de-anonymizes the user completely.

One partial solution would be to run the Tor client on a physically separate machine which acts as a transparent proxy for your browsing/internet box, and blocks any direct contact with the public internet via iptables trickery. I dunno what the processing overhead of running tor client is, but in theory you might be able to do so on a router running openWRT or similar.

you can use a raspberry pi for it. there's a nice tor-proxy kit on adafruit.

personally i think a separate machine booted using the tails bootdisk and no write access to anything is probably the safest.

I actually use a setup that involves a bunch of VMs for pretty good separation. It's a bit of a complicated setup, so I won't elaborate here. The main thing about it, is that even if an attacker runs with root privs on the "anonymous" VM, they'll need a 0-day in the Virtualization engine itself to de-anonymize the machine. I make sure that the VMs are as isolated from the host machine as they can be, so the attack surface is indeed minimized to the VM engine itself. Some "VM busting" attacks did occur in the past, but I believe very few (if any) attacked the VM engine itself. Most used the wider attack surface provided by stuff like the "VMWare tools" API (which for "isolated" VMs should be disabled). Edit: come to think of it, I should probably write up my method and post it to HN at some point...

I don't think anyone's fully reverse-engineered the payload yet.

It breaks out of the browser sandbox and submits a get request to some server with the guid identifying the user and the tor site they were on.

Reply on news.ycombinator.com