Black Hat Researchers Actively Trying To Deanonymize Tor Users 82
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.
I'd like to believe weakness are temporary... (Score:5, Insightful)
But I have my doubts about about technological fixes to the jackboot/battering-ram/nightstick vulnerability.
Re: (Score:2, Interesting)
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.
Re:Oh really ? (Score:4, Insightful)
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: (Score:1)
I don't think you can imagine a proper Camouflage scheme at this point. I do think I can. And yes, it would thwart correlation attacks. It might induce some delays for (say) ssh-over-TOR sessions which transmit very small packages. Camouflage would of course mandate a single package size histogram over a certain time frame. Many small payload packages would be stuffed in a single transport package, which means delay. Lots of dummy octets would be transmitted in the course of a browsing session. Bandwidth wo
Re: (Score:3)
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
Re: (Score:1)
You are focusing on packet length patterns, which is only part of the whole story. The TLAs also have the ability to impress transmission-rate patterns onto TOR traffic. There are some papers out there which demonstrated good results (from the TLA perspective) from that.
So next-gen TOR needs to handle both the packet length problem and the transmission rate shaping problem.
Finally, where did you get 3 modpoints from ?
Re: (Score:2)
There is nothing in a packet's headers that will indicate what route it took to get somewhere, no matter what sort of analysis you apply to it. The only 3 clues you have are the TTL, the source MAC address, and the source IP address.
Re: (Score:2)
And the thing is, when you're the government of a country, you can bust down every door, pull the mac address, look at the routing table, and head to the next door to bust down. It goes even faster when every ISP is freely complicit(they are in the US, China, Russia, and anywhere else notably stompy).
Re: (Score:2)
Didn't Russia just announce a bounty for anyone who could help them identify weaknesses and track TOR users? Maybe the presentation at the Black Hat conference was cancelled because the Russians pay more?
Black Hats shoot themselves in the foot. (Score:5, Interesting)
I find it kinda funny that TOR is used by many Black Hats is being hacked by Them. TO expose who they are...
Re: (Score:3)
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: (Score:3)
Yeah: "Prison statistics: 4 out of 5 people like gang rape"
Re: (Score:2)
It's a bit like the endgame for the game Uplink-- if you go blackhat, you end up in a race to destroy the internet. If you succeed, the only thing that happens is that you get a 'connection terminated' notice.
Re:Black Hats shoot themselves in the foot. (Score:5, Insightful)
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: (Score:2, Interesting)
Re: (Score:2)
Evidence?
Re: (Score:2)
Re: (Score:2)
Yes. I doubt everything that I don't have evidence of.
Re: (Score:2)
So your rationale for accusing the NSA of something is "They do other bad stuff, clearly they do this as well?"
Re: (Score:2)
Given Saddam Hussein's long history with chemical weapons, was it reasonable to assume he had an active chemical weapons program in 2002?
Re: (Score:2)
Re: (Score:2)
What's interesting about this post being modded interesting is the number of people who apparently read it and thought "yep, nothing wrong with that logic". Or have never thought seriously, and apparently have no idea, what "black hat" hacker means.
Re: (Score:1)
I think you're conflating terms here. Yes, a black hat hacker is someone who generally breaks into systems and otherwise acts outside of the scope of legality. However, Black Hat is a security conference held in Las Vegas on an annual basis, and while the atmosphere can be slightly different than DEFCON, it's...generally a similar convention. Black Hat Researchers referenced here, therefore, likely fall under that official umbrella, and thus likely would NOT necessarily fall under the general black hat
Re: (Score:2)
Re:Black Hats shoot themselves in the foot. (Score:5, Insightful)
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: (Score:2)
Changes to the protocol? (Score:2)
I wonder how feasible it would be to modify tor, or maybe make a tor version 2 protocol so that the onion layers are determined packet by packet, instead of by the stream.
I'm not all that knowledgeable when it comes to the tor protocol, but it sounds like each stream is bounced off a series of relays.. If you could change that to each packet, or split the stream into a few other streams that took different routes (and let the stream get reassembled from packets from multiple streams at the destination), the
Re:Changes to the protocol? (Score:4, Funny)
If we're talking about onion layers, please call it "Ogre" instead of "Tor 2".
Re: (Score:2)
I wonder how feasible it would be to modify tor, or maybe make a tor version 2 protocol so that the onion layers are determined packet by packet, instead of by the stream.
I think that might fall apart at the exit node, since expecting the server to receive response packets from 2 different IPs isn't TCP/IP compliant. You could certainly build sites that work with that expectation, but it would essentially require all layers to be designed to support TOR.
Re: (Score:2)
Tor is designed to be low-latency. Such complicated routing would definitely make a large latency tradeoff, since you'd have several routes, all of different latencies, which would mean the packets would arrive out of order and you'd need to delay to determine if you'd actually received a complete set before reconstructing an in-order stream to the final destination.
Re: (Score:2)
Yeah, Roo-see-uh (Score:2)
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: (Score:2, Informative)
Tor *does* have blacklist support: https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays
Can we get a hyphen? (Score:5, Funny)
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: (Score:1)
I think they meant Dean-omize. Turn Tor users into Deans of well respected Universities/Colleges, probably to help increase the adoptomization and respectomization of Tor.
Re: (Score:2)
I think they meant Dean-omize. Turn Tor users into Deans of well respected Universities/Colleges, probably to help increase the adoptomization and respectomization of Tor.
If instead you meant Dean-omize as in "turn them into Howard Dean", then in this crowd that would have the exact same effect as demonization.
Re: (Score:2)
I was actually hoping that we'd be turned into Dean Martin. Even if he's long dead, he's cooler than the entire TOR user community and node operator community combined.
Re: (Score:1)
I was thinking Jimmy Dean's Pork Sausage. I mean, why not something meaningfully tasty?
Re: (Score:1)
3.) makes it clear you don't understand how tor works. You can configure as many TOR nodes as you wish. There are points speaking for, and others speaking against your suggestion.
2.) TOR money better should go into the number of TOR relays first, not senseless camouflage traffic.
3 relay path (Score:2)
apparently 3 proxies aren't enough, should rather be 7 :-)
Duh (Score:2)
It's because Russia's offering $$$ for a TOR hack...
http://www.themoscowtimes.com/... [themoscowtimes.com]
on the bright side, TOR will be better in the end because of it.
Re: (Score:2)
on the bright side, TOR will be better in the end because of it.
[citation seriously needed]
Re: (Score:1)
http://lmgtfy.com/?q=tor+russi... [lmgtfy.com]
Re: (Score:2)
http://lmgtfy.com/?q=tor+russi... [lmgtfy.com]
Which does NOT address how the TOR network will magically become somehow better because of being attacked not one bit at all.
This is a good thing! (Score:1)
I see many naysayers & detractors here querying why black-hats would want to break the very services they rely on, but surely that's exactly what they should be doing?
If you want to rely on a service for your own security, it's in your best interests to find all the weaknesses - especially with open source projects, which rely on the community to find & fix faults.
THIS IS NOT BLACK HAT RESEARCHERS (Score:2)
"We spent several months trying to extract information from the researchers who were going to give the Black Hat talk, and eventually we did get some hints from them about how "relay early" cells could be used for traffic confirmation attacks, which is how we started looking for the attacks in the wild. They haven't answered our emails lately, so we don't know for sure, but it seems likely that the answer to Q1 is "yes"."
Fucking slashdot, can't even be bothered to RTFA to check the headline. It's only suspe
bitmessage (Score:1)