Black Hat Researchers Actively Trying To Deanonymize Tor Users

An anonymous reader writes: Last week, we discussed news that a presentation had been canceled for the upcoming Black Hat security conference that involved the Tor Project. The researchers involved hadn't made much of an effort to disclose the vulnerability, and the Tor Project was scrambling to implement a fix. Now, the project says it's likely these researchers were actively attacking Tor users and trying to deanonymize them. "On July 4 2014 we found a group of relays that we assume were trying to deanonymize users. They appear to have been targeting people who operate or access Tor hidden services. The attack involved modifying Tor protocol headers to do traffic confirmation attacks. ...We know the attack looked for users who fetched hidden service descriptors, but the attackers likely were not able to see any application-level traffic (e.g. what pages were loaded or even whether users visited the hidden service they looked up). The attack probably also tried to learn who published hidden service descriptors, which would allow the attackers to learn the location of that hidden service." They also provide a technical description of the attack, and the steps they're taking to block such attacks in the future.

Comments

I'd like to believe weakness are temporary...

[i kan reed]

But I have my doubts about about technological fixes to the jackboot/battering-ram/nightstick vulnerability.

Re:I'd like to believe weakness are temporary...

[Anonymous Coward]

The foundation of the internet is computers asking adjacent (as for as the network is concerned) computers to relay something to somewhere else. TOR is a well constructed obfuscation layer on top of that, but the low-level standards are very traceable. Without even going into TOR vulnerabilities or PEBCAK errors, a sufficiently determined opponent will be able to beat any obfuscation of intent by extensive analysis of addressing and timing of the encrypted packets.

Black Hats shoot themselves in the foot.

[jellomizer]

I find it kinda funny that TOR is used by many Black Hats is being hacked by Them. TO expose who they are...

Re:Black Hats shoot themselves in the foot.

[i kan reed]

Tragedy of the commons. If you're the person who broke Tor, you're(temporarily) the king of blackhats. Who cares that it screws over all the other blackhats. They'd screw you over just as fast.

Re:Black Hats shoot themselves in the foot.

[ron_ivi]

Hard to tell who "them" is.

It's being used by, and trying to be hacked by, many groups.

University researchers, governments, MPAA/RIAA, computer security companies, etc.

Seems the project should encourage as many people as possible attempting to hack it -- because that increases the odds that when people finds a hack, at least some of them will report the weakness back to the project.

On the other hand, if the project discourages hacking attempts, only malicious groups will find the hacks.

Re:Black Hats shoot themselves in the foot.

[Opportunist]

Yeah: "Prison statistics: 4 out of 5 people like gang rape"

Re:Black Hats shoot themselves in the foot.

[wile_e_wonka]

If Black Hats don't hack it then the NSA will. But the NSA will quietly keep the vulnerability(ies) to themselves and use them to collect data. Whereas a Black Hat looking to rely on TOR will be best off figuring out its weaknesses in order to make it more effective.

In other words, people who rely on TOR would be completely stupid to not try to hack it to determine its vulnerabilities. The only odd thing about this isn't really odd at all when you think about these hackers are--they're exposing vulnerabilities in a particularly spectacular fashion.

Re:Changes to the protocol?

[ArcadeMan]

If we're talking about onion layers, please call it "Ogre" instead of "Tor 2".

Yeah, Roo-see-uh

[Impy the Impiuos Imp]

Fascinating. If they can detect suspicious fraud nodes, TOR could build into their project a blacklist support that they publish and honor in their code. Then it becomes a whack-a-mole issue, which is better han the current situation.

Ummm...what with Russia trying to de-anonymize TOR and all. Bad Rooskies.

Re:Yeah, Roo-see-uh

[Anonymous Coward]

Tor *does* have blacklist support: https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays

Can we get a hyphen?

[damn_registrars]

The first time I saw the headline I thought it said

Black Hat Researchers Actively Trying to Demonize Tor Users

Then I thought it was perhaps

Black Hat Researchers Actively Trying to Deamonize Tor Users

Before I figured out they meant

De-anonymize

Re:Oh really ?

[Qzukk]

And sure as hell it is impossible to develop a mixnet that will generate Camouflage traffic

It would have to generate traffic in equal amounts for every flow, which would halve network speed to give an attacker a 50/50 chance of guessing the correct flow. Those fake flows would also have to be carried to something that looks like a reasonable endpoint as well.

PRISM-level metadata collection makes it trivial to see which computer sent the original 682-byte request (recurse as necessary until the 800 byte request starts at the "sender") as well as which computer the multi-megabyte response was sent to (recurse as necessary until the multi megabyte response returns to the requesting computer). Camouflage traffic can't fix this on its own, it's easy to exclude the data that wasn't requested from the analysis.

I think that Tor's best bet while maintaining performance at this point would be to round all packets up to the nearest MTU (lets say 1400 to account for PPPoE, VPNs, and other layers on ethernet), so every request and response becomes a multiple of 1400 bytes, would make most tracking rely on packet timing. The next step would be to introduce packet delays at each hop, but that will slow the already slow network down.

Re:Oh really ?

[Qzukk]

Since you're not sharing, I'm guessing you're imagining some sort of multiplexing scheme where the node would take say 100 bytes from 14 different sources and combine them into one packet and send that. It's an intriguing idea that would slow down metadata analysis but it would have a lot of overhead to keep track of, but that "keeping track of" becomes an attack vector again especially with subverted nodes, since node B will need to know that the next 8 packets from node A will have 100 bytes of data that need to be kept together and sent on to node C.

If the network is busy it should actually not be bad for interactive small-packet connections. If the network is idle there could be a timer before the node fills unfilled slots with random data and sends it.