Tor 0day: Stopping Tor Connections(hackerfactor.com) |
Tor 0day: Stopping Tor Connections(hackerfactor.com) |
1. "using JavaScript, you can identify the scrollbar width [...] so an attacker can identify the underlying operating system"
Using JavaScript, you can simply ask Tor Browser what platform it's on using navigator.userAgent, and it will tell you the truth because lying breaks e.g. websites' custom key combinations. Tor Browser will however attempt to anonymize the platform in passive indicators, i.e. HTTP User-Agent: https://blog.torproject.org/new-release-tor-browser-801 (search for "User Agent")
(EDIT) This was too dismissive, because scrollbar width differences are more fine-grained than platform differences: https://bugzilla.mozilla.org/show_bug.cgi?id=1397996#c5
2. Blocking entry node connections:
"Checking every network connection against every possible Tor node takes time. This is fine if you have a slow network or low traffic volume, but it doesn't scale well for high-volume networks."
If you can muck around in TLS cert fields in real time, you can look up an IP address in a hash table...
"Second, the list of nodes changes often. This creates a race condition, where there may be a new Tor node that is seen by Tor users but isn't in your block list yet."
Oh no! (clutches pearls)
Not to say that it isn't worthwhile to tidy up the TLS fields some more, but hyping this as a zeroday is absurd.
There are many other ways to detect TOR connections or nodes and block them. Theres enough that there are a whole set of ways of obfuscating traffic called pluggable transports: https://trac.torproject.org/projects/tor/wiki/doc/AChildsGar...
Trying to fix this would be a never-ending losing battle, I can understand why the Tor project aren't that interested in changing things.
Why? If someone knows I'm running TOR, I guess that's not great, but I don't really see the issue.
This post talks about how you can identify a running Tor when you connect to the (operator-assigned, public) relay port. You can only "see" these TLS certificate details when you are connecting to the relay yourself. This means this does not allow network operators to detect traffic going to Tor nodes, or in-between nodes, let alone identify users or deanonymize anyone: To external observers, such traffic looks like typical browser TLS traffic.
So, what this does is allow you to identify Tor nodes, which is by definition not a problem for all Tor relays except bridges, which should not be as easily discoverable by a network scan. The problem has been known before, and work as been done so you can now run a Tor bridge without this problem. As this problem has been publicly discussed and outlined in the very first design documents, it cannot be called a "0day", even if it was more problematic than it actually is.
Tor came up with the concept of "pluggable transports" to address this very successfully, which allows clients and entry bridges to basically make Tor traffic look like anything you want.
In this case the fact that a user is using tor is considered protected information meaning any exposure of that is in fact a info leak vulnerability
The reported scroll bar width vulnerability is his strongest case. He rightly got a bounty for it. But it's relatively hard to fix, and until recently, the Tor browser also just leaked your window size via Javascript. But they're getting there, slowly.
However, the story about public bridge certificates is pretty unjustified. The response he got from the Tor Project is completely clear, and his proposed solution in trying to impersonate traditional PKI simply won't work against even mediocre attackers. Furthermore, bridge enumeration as a systemic attack might be a problem against censorship systems, but can't rightly be called a '0day'. Private bridges (https://bridges.torproject.org) also solve a lot of the problem.
In the linked ticket, you clearly see that they are trying pretty hard to find a sponsor willing to fund the solution.
Though this was why Tor would always open in the same window size. But ya, that all fell apart if you maximized.
When did they fix “the leak” itself? Wouldn’t that require intercepting the JavaScript call in the same way that the scroll bar size issue could be fixed?
I thought it was accepted and strongly emphasized that running JavaScript in a Tor environment was insecure and could leak information in all sorts of ways, which is why Tor Browser came with NoScript enabled by default.
Is that no longer the case? Is there now an expectation that you should be able to safely run JS in Tor Browser without risk?
A website operator can already get refreshed lists of Tor exit nodes and simply block them. Your ISP/government can already see that there's Tor traffic coming from your house, and probably "match" at least some activity with an exit node.
> But there's a third issue: websites can easily determine whether you have allowed JavaScript for them, and if you disable JavaScript by default but then allow a few websites to run scripts (the way most people use NoScript), then your choice of whitelisted websites acts as a sort of cookie that makes you recognizable (and distinguishable), thus harming your anonymity.
How would this work exactly? And if it did work, wouldn't it at the very worst only work on sites for which you had enabled JS? I.e. sites that you had already essentially conceded your anonymity on by choice?
I don't see this as a worthy argument for enabling JS by default and destroying users' anonymity without custom configuration.
What? I can't tell if this is sarcastic or not. There's only around 3000 tor entry nodes[1]. This is orders of magnitude smaller than the number of entries in the internet routing table, which is around 800k. This means at the worst case, if you're an ISP, you can block tor nodes at the router level with virtually zero impact.
[1] https://onionoo.torproject.org/details?search=flag:Guard%20r...
This plus the other descriptions/responses from the project in his post makes me think the project has attracted a lot of people that aren't programmers or can't actually do the valuable work of fixing the thing (though I'd be interested in seeing the specific ticket).
I'd guess that projects like Tor that interest people outside of strict programmer types have this as a bigger issue.
The result is you end up with a lot of people filing tickets and writing emails, but very few actually doing work to fix things because they don't know how. The few that could figure it out, are probably over extended. Having non-programmers interested in helping isn't necessarily a bad thing since good support people help make it easier to fix issues, but it can become bad if support people bias to closing issues because they can't fix them and closing them becomes the goal.
Tor does have some obfuscation proxies (called pluggable transports) to try and disguise the traffic to make it harder to block (there were videos a few years ago when I looked into how Tor worked that talked about this, the traffic is disguised as VOIP among other things). I know China blocks Tor by blocking all the bridge nodes it can find (both public and private) and by using the tricks he describes to slow or stop identified traffic. I think the head of the project cares about these issues.
Not an easy problem to fix, they probably need more programmers. Maybe a direct focus on these issues would help, but it could be they're focused on problems of similar or worse severity (hard to know).
His points are valid, and these are vulnerabilities. However they seem like feature requests, rather than being focused on a technical vulnerability (for example use after free).
I’ll wait and see if there are any real vulnerabilities in the queue.
Being tracked and anonymous feel like two distinct issues. If you were to only see a hash of my username, you could track me, but you couldn't identify me with it. Definitely something you'd want TOR to stop, but I think that's pretty important.
The other vulnerability is that websites can identify that a user is using TOR. My understanding is that this has always been fairly trivial?
It feels like the real 'story' here is that the TOR project hasn't been grooming their bug bounty program, and so there may be more serious bugs lurking.
Pseudonymous is the word for that sort of "tracking". Tracking just means being tracked, no matter if they use the real name or a hash of it or fingerprinting/metadata like IP + user agent string + installed fonts.
But that's not how tor works. It's not like a VPN where all your traffic comes out of one node. So if even if you logged into facebook using tor browser, it won't be able to correlate your other tor browsing activities. Even third party cookies won't work because tor browser has third party isolation enabled.
Step 1: Log into tor.
Step 2: Create facebook account using a fake name
Step 3: Don't add anyone you know in real life as a friend. Best not to search for friends.
Facebook will not connect you now.
Is there an alternative that's performant and built with a decent language? Or do the good ones just get snuffed out?
Banned
0Day #1: Blocking Tor Connections the Smart Way
There are two problems with the "block them all" approach. First, there are thousands of Tor nodes. Checking every network connection against every possible Tor node takes time. This is fine if you have a slow network or low traffic volume, but it doesn't scale well for high-volume networks. Second, the list of nodes changes often. This creates a race condition, where there may be a new Tor node that is seen by Tor users but isn't in your block list yet.
However, what if there was a distinct packet signature provided by every Tor node that can be used to detect a Tor network connection? Then you could set the filter to look for the signature and stop all Tor connections. As it turns out, this packet signature is not theoretical. #!/bin/bash
addresses=$(curl -s https://check.torproject.org/torbulkexitlist?ip=<your-server's-ip> | sed '/^#/d')
if [ -n "$addresses" ]; then
/sbin/ipset flush tor
echo "$addresses" | while read address; do
/sbin/ipset -q -A tor "$address"
done
fi
I don’t allow JavaScript to run on my mobile browser because of the disturbing crash logs in WebKit in the few times I have enabled JS.
It's like if you kept trying to fix other people's cars when you know only the principles of a combustion engine, own an electric motorcycle yourself, and those cars would be very different from each other: I'd much rather someone does it who actually knows what they're doing, it would save all parties a lot of trouble. Diagnosing problems very specifically should already help them a lot of the time they would otherwise have to put in.
So they are basically reporting trivial issues (this is trivial, at least, I cannot judge for the others they say they have) and pretending that people paid by someone else now care just about that. Doesn't look like very smart.
This sounds so interesting to me to hear about. Can anyone recommend a podcast where like-minded engineers discuss things like this? I'd love to vicariously live through their hacking adventures.
So, I don't want to infer your opinions, but I want to ask: what about social justice and diversity is to the detriment of their software?
Remove those reasons and I would prefer a more open culture and prefer less toxic and would switch browsers to support single thought vs group think.
Even if the certificate is valid, there are lots of other distinguishing factors. You can go as far as timing attacks. As the answer alludes to, they have an entire project around obfuscated transports primarily for clients and private bridges. [1]
But there's no need for obfuscation here as the ORPort can 'simply' be closed, if it wasn't such a hassle to actually implement.
[1] https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt
I generally chalk this up to leadership issues.
> But that's not how tor works. It's not like a VPN where all your traffic comes out of one node. So if even if you logged into facebook using tor browser, it won't be able to correlate your other tor browsing activities. Even third party cookies won't work because tor browser has third party isolation enabled.
Except that the OP discussed a technique that exposed an attribute of the user's setup that (when combined with other such techniques) allows unique (albeit pseudonymous) identification of the user across requests and sessions (this is called fingerprinting). Add in correlation of the pseud identifier with a real-world identity via use of FB, and the user would be totally hosed.
Or... a bazillion other illegitimate reasons ;).
And then the tests won't pass on master!
In any case, first-party isolation can be subverted: https://news.ycombinator.com/item?id=17947605
Personally, I don't do it, but I understand why it's appealing. I see it as a personal decision (its your website after all) and not morally wrong as some see it.
I once talked to someone working security for a Canadian government agency. They considered it against their charter and/or illegal to block tor nodes, because it could be blocking legitimate access for Canadian citizens potentially in distress, much to the chagrin of their downstream customers (other agencies). I thought that was pretty interesting.
If I were fortunate enough to be part of a larger team, I'd advocate for exactly what you're suggesting.
Also CDNs generally offer this if you use one.
Hopefully the Tor devs consider the proposed enhancements to make the traffic less vulnerable to identification. As he already digged into the source code, maybe it's easier when he submits a PR for a higher chance to fix the issue.
The author's approach requires examining a certificate to see if it matches a pattern that may or may not change in the future.
I could write a conf.d file to be included in each vhost, and write a script to generate a large rewrite file nightly and "apachectl graceful" it afterward, and that would probably work... but I expect that will have a measurable impact on response times and, again, I'm not hosting governmental sites or anything that could reasonably be considered vital to the health and well-being of innocent tor users.