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