Silk Road forums
Discussion => Security => Topic started by: thaganjaman on April 03, 2013, 02:41 pm
-
A question probably posted many times. Is it in any way possible for law enforcement or black hat hackers to reveal a TOR users true IP when using standard settings TOR browser bundle?
Sorry if this the 10.000's time this is posted.
-
There are two main ways in which Tor for clients can fail.
A. The attacker hacks you and gets your IP address without breaking Tor
This is probably the most likely way that people would be deanonymized. LE have done attacks like this to get around VPNs and Botnets although I have not heard of any instance where they used this technique to get around Tor to deanonymize clients (they have to deanonymize hidden services though). For example, read about CIPAV. In all cases I am aware of LE have used known vulnerabilities that their targets did not patch. Of course it is possible they can use zero days as well, but it seems they do this quite rarely if at all. There is always the worry that they can buy zero days from groups that assist the police for a fee, and unfortunately this business model seems to be growing substantially. Anyway, protecting from this sort of attack requires hardening your system separately of Tor, for example I am a big fan of using virtual machines to isolate network facing applications from Tor and your external IP address. Doing this by itself significantly helps to protect you from this sort of attack, and indeed the targeted hidden services that used this technique were not deanonymized by LE hackers, even though they were penetrated. Additionally, make sure to keep your system up to date and patched, use Tor browser bundle only, I suggest disabling javascript to additionally harden the browser. There are other advanced techniques as well, using profiles with mandatory access control systems like security enhanced Linux or Apparmor, firewall rules, etc. It is also quite helpful to use a security oriented operating system that has features like automatic full ASLR (OpenBSD has this, for example. Others have as well to various extents, in some cases the programs need to be compiled with it but I think OpenBSD always has it for everything.).
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
In this case they are able to link you to your final destination with a timing attack. Tor is low latency, it doesn't significantly reorder or delay packets and there are statistical formulas that can say if two packets observed at different locations on the Tor network are part of the same stream. Tor banks on the attacker not being able to see the traffic at two different locations (most importantly entry and exit), failing this assumption the attacker trivially defeats Tor. Tor tries to make it hard for an attacker to watch traffic at entry and exit, but it doesn't protect at all from an attacker who watches traffic at entry and exit. This attack is just as applicable to traffic going to clearnet as it is to traffic going to hidden services, even though strictly speaking traffic arriving at a hidden service is not really exiting the Tor network. It may be slightly harder for an attacker to carry out this attack against clients connecting to hidden services than it is for them to carry it out against clients connecting to clearnet websites, but this is only because they first need to locate the hidden service and passively or actively put it under surveillance.
the two previously mentioned scenarios / attack methods are by far the most likely way that Tor will fail (or be circumvented), but there are a handful of other exotic / theoretical attacks as well. And of course there are other attacks that completely avoid technical aspects all together, for example Tor will not keep you anonymous if you give out information over it that identifies you. Traditional police work tends to focus on this sort of datamining attack rather than highly technical attacks, it is their true specialty and they are still struggling to utilize sophisticated technical investigatory methods. There are also some attacks on Tor that are very specific to our threat model, membership concealment is much more important when you leak your rough geographic location by shipping packages. Normally the Tor threat model sort of assumes that the users do not leak their rough geographic location, so a user could be in USA or Canada or Japan for all anyone watching their exit traffic knows. In the case of SR vendors this is not the case, not only do they reveal their country but they often reveal their city as well. This can majorly reduce the anonymity set size they have to hide in, an attacker who can observe large amounts of traffic from arbitrary cities in a country can now say that the vendor is one of the Tor users in this city, rather than a Tor user somewhere in the world. If there are not many Tor users in your rough geographic area, this could reduce your anonymity set size by enough to get you under surveillance. Even if there are a lot of Tor users in your area, using a combination of datamining (hm, which of these Tor users has prior drug charges) and membership detection could narrow in on the likely suspect set significantly. The best protection from this sort of attack is to hide the fact that you use Tor, for example by using bridges (although this in itself creates its own intelligence weaknesses, how many people in a country that doesn't censor the internet are likely to use bridges? Not many. So if you use an attacker controlled bridge while you are in the USA, they may have a good idea why. On the other hand, if you use an attacker controlled entry guard in any case you are probably close to fucked, so it is certainly a better option than not using a bridge imo). Laws restricting police agencies from doing dragnet surveillance may help some as well, even if they can detect your IP address is one of the only ones using Tor in your city , they might have legal trouble using that as probable cause to get your customer registration data from the ISP. That said I wouldn't count on the law to protect you much.
-
There are two main ways in which Tor for clients can fail.
A. The attacker hacks you and gets your IP address without breaking Tor
This is probably the most likely way that people would be deanonymized. LE have done attacks like this to get around VPNs and Botnets although I have not heard of any instance where they used this technique to get around Tor to deanonymize clients (they have to deanonymize hidden services though). For example, read about CIPAV. In all cases I am aware of LE have used known vulnerabilities that their targets did not patch. Of course it is possible they can use zero days as well, but it seems they do this quite rarely if at all. There is always the worry that they can buy zero days from groups that assist the police for a fee, and unfortunately this business model seems to be growing substantially. Anyway, protecting from this sort of attack requires hardening your system separately of Tor, for example I am a big fan of using virtual machines to isolate network facing applications from Tor and your external IP address. Doing this by itself significantly helps to protect you from this sort of attack, and indeed the targeted hidden services that used this technique were not deanonymized by LE hackers, even though they were penetrated. Additionally, make sure to keep your system up to date and patched, use Tor browser bundle only, I suggest disabling javascript to additionally harden the browser. There are other advanced techniques as well, using profiles with mandatory access control systems like security enhanced Linux or Apparmor, firewall rules, etc. It is also quite helpful to use a security oriented operating system that has features like automatic full ASLR (OpenBSD has this, for example. Others have as well to various extents, in some cases the programs need to be compiled with it but I think OpenBSD always has it for everything.).
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
In this case they are able to link you to your final destination with a timing attack. Tor is low latency, it doesn't significantly reorder or delay packets and there are statistical formulas that can say if two packets observed at different locations on the Tor network are part of the same stream. Tor banks on the attacker not being able to see the traffic at two different locations (most importantly entry and exit), failing this assumption the attacker trivially defeats Tor. Tor tries to make it hard for an attacker to watch traffic at entry and exit, but it doesn't protect at all from an attacker who watches traffic at entry and exit. This attack is just as applicable to traffic going to clearnet as it is to traffic going to hidden services, even though strictly speaking traffic arriving at a hidden service is not really exiting the Tor network. It may be slightly harder for an attacker to carry out this attack against clients connecting to hidden services than it is for them to carry it out against clients connecting to clearnet websites, but this is only because they first need to locate the hidden service and passively or actively put it under surveillance.
the two previously mentioned scenarios / attack methods are by far the most likely way that Tor will fail (or be circumvented), but there are a handful of other exotic / theoretical attacks as well. And of course there are other attacks that completely avoid technical aspects all together, for example Tor will not keep you anonymous if you give out information over it that identifies you. Traditional police work tends to focus on this sort of datamining attack rather than highly technical attacks, it is their true specialty and they are still struggling to utilize sophisticated technical investigatory methods. There are also some attacks on Tor that are very specific to our threat model, membership concealment is much more important when you leak your rough geographic location by shipping packages. Normally the Tor threat model sort of assumes that the users do not leak their rough geographic location, so a user could be in USA or Canada or Japan for all anyone watching their exit traffic knows. In the case of SR vendors this is not the case, not only do they reveal their country but they often reveal their city as well. This can majorly reduce the anonymity set size they have to hide in, an attacker who can observe large amounts of traffic from arbitrary cities in a country can now say that the vendor is one of the Tor users in this city, rather than a Tor user somewhere in the world. If there are not many Tor users in your rough geographic area, this could reduce your anonymity set size by enough to get you under surveillance. Even if there are a lot of Tor users in your area, using a combination of datamining (hm, which of these Tor users has prior drug charges) and membership detection could narrow in on the likely suspect set significantly. The best protection from this sort of attack is to hide the fact that you use Tor, for example by using bridges (although this in itself creates its own intelligence weaknesses, how many people in a country that doesn't censor the internet are likely to use bridges? Not many. So if you use an attacker controlled bridge while you are in the USA, they may have a good idea why. On the other hand, if you use an attacker controlled entry guard in any case you are probably close to fucked, so it is certainly a better option than not using a bridge imo). Laws restricting police agencies from doing dragnet surveillance may help some as well, even if they can detect your IP address is one of the only ones using Tor in your city , they might have legal trouble using that as probable cause to get your customer registration data from the ISP. That said I wouldn't count on the law to protect you much.
Thanks for this very detailed description, very useful! Unfortunately it's a bit to advanced for me. Any chance you will translate it a little? Sry for my ignorance..
A. The attacker hacks you and gets your IP address without breaking Tor
- I guess for this to happen the attacker would have to find and hack you outside of TOR, and therefor are not hacking you due to your SR activities, correct?
(What is zero days?)
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
- What would it take for an attacker to accomplish this? And how would that work?
Is it possible for an attacker to compromise a TOR user, simply by having the target clicking a corrupted link ?
I really appreciate your insight.
-
i will also say the unspoken around here, the software was written by the guberment for goodness sakes, please tell me who does all the updates and revisions for the program? Another question for members, if they can put a provision in Tor to identify perverts that do cp, why can they not put something in place for other reasons? Just asking, i haven't seen this asked, or addressed in nearly 2 years in these parts. i only post this cause things are getting a bit strange ,
I was aware that the government created TOR back in the days, but are you really saying that they are still controlling the software? Who does control the browser bundle? and who checks that it is not bugged with advanced spyware? And can you really trust anybody?
Is it a fact that LE is able to identify cp perverts hiding behind TOR? As you are pointing out, if this is actually possible, of course they will do the same with drug dealers....
-
Tor was kind of written by the government. The original inventor of the concept of onion routing was Paul Syverson, he works for the United States Navy. Another lead developer is Roger Dingledine, who briefly worked for the NSA. Nick Mathewson is the third original developer, and I am pretty sure he has no ties to the US government. The strongest link Tor has to 'being written by the government' is Syverson participating in its implementation (and being the inventor of the underlying concept). That said, Tor is open source and has a quite large community of hackers who contribute to audits, revisions and updates. Tor is by far the most researched anonymity software in the world. Also, they have never put a provision in Tor to identify people involved with CP, so that is kind of a strange implication. Maybe you are thinking about JAP. Essentially, any backdoor they put in Tor will need to make it past a ton of people. In the case of JAP they were able to put in specific "backdoors" to bust certain targets because the JAP relays are all operated by a small group of people. They didn't really backdoor the code that users were running, rather they installed logging software on several of the relays that watched for connections to sites the government (of various countries) ordered them to log, while ignoring other traffic flows. This is not possible in the case of Tor because there are many thousands of relays and they all use open source software that anyone can audit.
-
i will also say the unspoken around here, the software was written by the guberment for goodness sakes, please tell me who does all the updates and revisions for the program? Another question for members, if they can put a provision in Tor to identify perverts that do cp, why can they not put something in place for other reasons? Just asking, i haven't seen this asked, or addressed in nearly 2 years in these parts. i only post this cause things are getting a bit strange ,
I was aware that the government created TOR back in the days, but are you really saying that they are still controlling the software? Who does control the browser bundle? and who checks that it is not bugged with advanced spyware? And can you really trust anybody?
Is it a fact that LE is able to identify cp perverts hiding behind TOR? As you are pointing out, if this is actually possible, of course they will do the same with drug dealers....
The main Tor software is still largely controlled by Roger and Nick, not sure if Paul has a big role in it anymore or not. Of course there are also dozens of other prominent developers who work on it to various extents, Jacob Appelbaum being one of the most famous (he definitely has no ties to the US government, other than being perpetually harassed by them). His claim that LE can use some backdoor in Tor to identify people involved with CP is entirely baseless.
-
Tor was kind of written by the government. The original inventor of the concept of onion routing was Paul Syverson, he works for the United States Navy. Another lead developer is Roger Dingledine, who briefly worked for the NSA. Nick Mathewson is the third original developer, and I am pretty sure he has no ties to the US government. The strongest link Tor has to 'being written by the government' is Syverson participating in its implementation (and being the inventor of the underlying concept). That said, Tor is open source and has a quite large community of hackers who contribute to audits, revisions and updates. Tor is by far the most researched anonymity software in the world. Also, they have never put a provision in Tor to identify people involved with CP, so that is kind of a strange implication. Maybe you are thinking about JAP. Essentially, any backdoor they put in Tor will need to make it past a ton of people. In the case of JAP they were able to put in specific "backdoors" to bust certain targets because the JAP relays are all operated by a small group of people. They didn't really backdoor the code that users were running, rather they installed logging software on several of the relays that watched for connections to sites the government (of various countries) ordered them to log, while ignoring other traffic flows. This is not possible in the case of Tor because there are many thousands of relays and they all use open source software that anyone can audit.
Great post! Very insightful, thank you. I'd appreciate it if you'd take a second to address the questions below. (Although their basic nature).
A. The attacker hacks you and gets your IP address without breaking Tor
- I guess for this to happen the attacker would have to find and hack you outside of TOR, and therefor are not hacking you due to your SR activities, correct?
(What is zero days?)
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
- What would it take for an attacker to accomplish this? And how would that work?
Is it possible for an attacker to compromise a TOR user, simply by having the target clicking a corrupted link ?
-
A. The attacker hacks you and gets your IP address without breaking Tor
- I guess for this to happen the attacker would have to find and hack you outside of TOR, and therefor are not hacking you due to your SR activities, correct?
(What is zero days?)
Incorrect, hackers can hack you through Tor. Zero days are unpublished exploits that do not have commonly available patches to protect from them.
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
- What would it take for an attacker to accomplish this? And how would that work?
For example, if the attacker is your ISP, and you visit a website hosted by your ISP, and your ISP watches user traffic, they can link you to the website. That is a passive/external attack, because it happens without the involvement of any Tor nodes. An active/internal attack would be if your entry Tor node is owned by the attacker and so is your exit Tor node (or the hidden services entry guard). It works by measuring the time difference between observing a packet at one location on the network and another. A simpler explanation can be given in the context of multiple packets, although a single packet is enough to do this sort of attack (it is just harder to think about). Imagine you send a stream of packets to a website through Tor. The packets look like this leaving you to your entry node:
00000
but since your entry node holds the packets and forwards them on, they can insert a timing difference between the individual packets, sending the first one out then waiting some period of time before sending the second one out. This allows them to create a watermark in the stream. Now, imaging '-' is time delay, the entry node delays sending your packets to the middle node such that the stream of packets through the middle node looks like this:
0---0--0-0----0
now the middle node is good, so it just gets the packets and forwards them on how they came in to the exit node, so now the exit node gets this
0---0--0-0----0
now if the exit node is run by the same attacker who ran your entry node, they can see the watermark they inserted in the stream, they know that the stream is the same one that went through their entry node. They know you sent the stream through their entry node because you connect directly to the entry node. Also, as they are the exit node, they know where the stream is going. So now they have deanonymized you and linked your traffic to its destination.
This is a very primitive way in which this sort of attack could be carried out. In reality it works entirely passively and externally, meaning the attacker can simply observe the stream without modifying it, and they can observe it at the ISP level rather than the Tor node level. Also, they only need one packet, not an entire stream.
Is it possible for an attacker to compromise a TOR user, simply by having the target clicking a corrupted link ?
Sort of. An attacker could give you a link to an attack page that exploits a vulnerability in your browser and roots you, and get your real IP that way. That is an advanced sort of attack though, and if you are fully patched up it would require a zero day. Also if you layer security techniques it may require several zero days and some good luck on the part of the attacker. It is more likely that they will try to send you a link to a java applet or flash video that tries to send data back around Tor to deanonymize you, but since the browser bundle this sort of attack is not as realistic.
-
. The attacker hacks you and gets your IP address without breaking Tor
- I guess for this to happen the attacker would have to find and hack you outside of TOR, and therefor are not hacking you due to your SR activities, correct?
An attacker could hack you through a browser exploit. Even with transparent proxying of all connections, if he can get root privileges, he can disable Tor and your firewall. The best defense against this is an anonymizing middle box, a separate physical device from your main computer that runs Tor and transparently proxies all connections over the Tor network.
(What is zero days?)
Unpublished exploits.
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
- What would it take for an attacker to accomplish this? And how would that work?
Run many malicious relays. The probability of sending your circuits through the attacker's nodes is roughly
Centry / Nentry * Cexit / Nexit
where
Centry = number of entry nodes run by attacker
Nentry = total number of entry nodes
Cexit = number of exit nodes run by attacker
Nexit = total number of exit nodes
Let's say the attacker spins up 100 entry nodes and 100 exit nodes. For the sake of simplicity, let's say no entry nodes are exits and vice versa. Currently there are about 900 total entry nodes and 900 exit nodes. Then the probability of getting pwned by the attacker is 100/1000 * 100/1000 = 1/100, or 1%.
That doesn't sound so bad, but consider that your Tor client builds new circuits every 10 minutes. If it chose from all entry and exit nodes, there would be a 50% probability of getting pwned after 8.3 hours of Tor use. That threat is mitigated by using entry guards. Instead of changing entry nodes every 10 minutes, your client changes them about every 2 months. So it takes 8600 times longer to accomplish this attack.
-
I should note that relay selection is weighted by bandwidth, so the attacker would have to control 1/10 of the entry and exit bandwidth, in the example above, not just 1/10 of the relays.
-
. The attacker hacks you and gets your IP address without breaking Tor
- I guess for this to happen the attacker would have to find and hack you outside of TOR, and therefor are not hacking you due to your SR activities, correct?
An attacker could hack you through a browser exploit. Even with transparent proxying of all connections, if he can get root privileges, he can disable Tor and your firewall. The best defense against this is an anonymizing middle box, a separate physical device from your main computer that runs Tor and transparently proxies all connections over the Tor network.
Yeah using a dedicated box is definitely the best way to do it. You can also virtualize the same thing with VM's , however it does come at a trade off of decreased security of the guest OS versus running it on baremetal.
Run many malicious relays. The probability of sending your circuits through the attacker's nodes is roughly
Centry / Nentry * Cexit / Nexit
where
Centry = number of entry nodes run by attacker
Nentry = total number of entry nodes
Cexit = number of exit nodes run by attacker
Nexit = total number of exit nodes
Let's say the attacker spins up 100 entry nodes and 100 exit nodes. For the sake of simplicity, let's say no entry nodes are exits and vice versa. Currently there are about 900 total entry nodes and 900 exit nodes. Then the probability of getting pwned by the attacker is 100/1000 * 100/1000 = 1/100, or 1%.
That doesn't sound so bad, but consider that your Tor client builds new circuits every 10 minutes. If it chose from all entry and exit nodes, there would be a 50% probability of getting pwned after 8.3 hours of Tor use. That threat is mitigated by using entry guards. Instead of changing entry nodes every 10 minutes, your client changes them about every 2 months. So it takes 8600 times longer to accomplish this attack.
Although you also need to take into consideration that the attacker probably just passively watches destinations of interest, so in practice they don't likely need to own your exit node, only your entry guard. If there are 900 entry guards and the attacker owns 100 of them, they own 1/9 entry guards. You select three entry guards every month to two months, and every time you do the chances the attacker owns one of them is 1/3.
-
A. The attacker hacks you and gets your IP address without breaking Tor
- I guess for this to happen the attacker would have to find and hack you outside of TOR, and therefor are not hacking you due to your SR activities, correct?
(What is zero days?)
Incorrect, hackers can hack you through Tor. Zero days are unpublished exploits that do not have commonly available patches to protect from them.
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
- What would it take for an attacker to accomplish this? And how would that work?
For example, if the attacker is your ISP, and you visit a website hosted by your ISP, and your ISP watches user traffic, they can link you to the website. That is a passive/external attack, because it happens without the involvement of any Tor nodes. An active/internal attack would be if your entry Tor node is owned by the attacker and so is your exit Tor node (or the hidden services entry guard). It works by measuring the time difference between observing a packet at one location on the network and another. A simpler explanation can be given in the context of multiple packets, although a single packet is enough to do this sort of attack (it is just harder to think about). Imagine you send a stream of packets to a website through Tor. The packets look like this leaving you to your entry node:
00000
but since your entry node holds the packets and forwards them on, they can insert a timing difference between the individual packets, sending the first one out then waiting some period of time before sending the second one out. This allows them to create a watermark in the stream. Now, imaging - is time delay, the entry node makes your stream of packets look like this prior to sending them to the middle node:
0---0--0-0----0
now the middle node is good, so it just gets the packets and forwards them on how they came in to the exit node, so now the exit node gets this
0---0--0-0----0
now if the exit node is run by the same attacker who ran your entry node, they can see the watermark the inserted in the stream, they know that the stream is the same one that went through their entry node. They know you sent the stream through their entry node because you connect directly to the entry node. Also, as they are the exit node, they know where the stream is going. So now they have deanonymized you and linked your traffic to its destination.
This is a very primitive way in which this sort of attack could be carried out. In reality it works entirely passively and externally, meaning the attacker can simply observe the stream without modifying it, and they can observe it at the ISP level rather than the Tor node level. Also, they only need one packet, not an entire stream.
Is it possible for an attacker to compromise a TOR user, simply by having the target clicking a corrupted link ?
Sort of. An attacker could give you a link to an attack page that exploits a vulnerability in your browser and roots you, and get your real IP that way. That is an advanced sort of attack though, and if you are fully patched up it would require a zero day. Also if you layer security techniques it may require several zero days and some good luck on the part of the attacker. It is more likely that they will try to send you a link to a java applet or flash video that tries to send data back around Tor to deanonymize you, but since the browser bundle this sort of attack is not as realistic.
Once again, great stuff. Appreciate you are talking the time...
To boil it all down. How likely is it that LE uses zero days ?
And do you consider someone being "fully patched up" by having the latest version of the browser bundle?
Please explain this part. "For example, if the attacker is your ISP, and you visit a website hosted by your ISP, and your ISP watches user traffic, they can link you to the website."
Sounds like this only attack by random, since all these terms need to be present at once.
-
. The attacker hacks you and gets your IP address without breaking Tor
- I guess for this to happen the attacker would have to find and hack you outside of TOR, and therefor are not hacking you due to your SR activities, correct?
An attacker could hack you through a browser exploit. Even with transparent proxying of all connections, if he can get root privileges, he can disable Tor and your firewall. The best defense against this is an anonymizing middle box, a separate physical device from your main computer that runs Tor and transparently proxies all connections over the Tor network.
(What is zero days?)
Unpublished exploits.
B. The attacker is able to see your traffic enter Tor and arrive at its final destination
- What would it take for an attacker to accomplish this? And how would that work?
Run many malicious relays. The probability of sending your circuits through the attacker's nodes is roughly
Centry / Nentry * Cexit / Nexit
where
Centry = number of entry nodes run by attacker
Nentry = total number of entry nodes
Cexit = number of exit nodes run by attacker
Nexit = total number of exit nodes
Let's say the attacker spins up 100 entry nodes and 100 exit nodes. For the sake of simplicity, let's say no entry nodes are exits and vice versa. Currently there are about 900 total entry nodes and 900 exit nodes. Then the probability of getting pwned by the attacker is 100/1000 * 100/1000 = 1/100, or 1%.
That doesn't sound so bad, but consider that your Tor client builds new circuits every 10 minutes. If it chose from all entry and exit nodes, there would be a 50% probability of getting pwned after 8.3 hours of Tor use. That threat is mitigated by using entry guards. Instead of changing entry nodes every 10 minutes, your client changes them about every 2 months. So it takes 8600 times longer to accomplish this attack.
I get most of what you are saying, but some of it is very advanced. I try to keep up.
What is root privileges, and how would an attacker accomplish to get this? (Please explain, as simple as possible.)
When I press "use a new identity" on vidalia, I change entry node, correct? How do I use entry guards instead?
-
Although you also need to take into consideration that the attacker probably just passively watches destinations of interest, so in practice they don't likely need to own your exit node, only your entry guard. If there are 900 entry guards and the attacker owns 100 of them, they own 1/9 entry guards. You select three entry guards every month to two months, and every time you do the chances the attacker owns one of them is 1/3.
True, true. Although you will only be accessing the destination web site 1/3 of the time through that one entry guard, if the purpose of the attack is to identity person X on the destination web site, you only need to go through the bad guard once.
-
Although you also need to take into consideration that the attacker probably just passively watches destinations of interest, so in practice they don't likely need to own your exit node, only your entry guard. If there are 900 entry guards and the attacker owns 100 of them, they own 1/9 entry guards. You select three entry guards every month to two months, and every time you do the chances the attacker owns one of them is 1/3.
True, true. Although you will only be accessing the destination web site 1/3 of the time through that one entry guard, if the purpose of the attack is to identity person X on the destination web site, you only need to go through the bad guard once.
Sounds like it is actually quite easy for LE to identify a TOR user? How many TOR users in % do you think has been identified by LE?
-
I get most of what you are saying, but some of it is very advanced. I try to keep up.
What is root privileges, and how would an attacker accomplish to get this? (Please explain, as simple as possible.)
Root privileges is the Linux version of administrator privileges, except it's the top administrator. The attacker would gain administrator privileges through a privilege escalation attack. TBB runs as the normal user, but an exploit could give the attacker higher privileges.
When I press "use a new identity" on vidalia, I change entry node, correct? How do I use entry guards instead?
No. You can specify entry nodes in the Tor configuration file, but that's for advanced users and you shouldn't mess with it. New Identity simply builds new circuits, but they go through the same entry guards. Entry guard selection is left for the Tor client.
You don't have to do anything to use entry guards. Your client uses them by default.
-
Although you also need to take into consideration that the attacker probably just passively watches destinations of interest, so in practice they don't likely need to own your exit node, only your entry guard. If there are 900 entry guards and the attacker owns 100 of them, they own 1/9 entry guards. You select three entry guards every month to two months, and every time you do the chances the attacker owns one of them is 1/3.
True, true. Although you will only be accessing the destination web site 1/3 of the time through that one entry guard, if the purpose of the attack is to identity person X on the destination web site, you only need to go through the bad guard once.
Sounds like it is actually quite easy for LE to identify a TOR user? How many TOR users in % do you think has been identified by LE?
Well, that attack isn't trivial. It would be incredibly difficult to spin up 100 relays without getting noticed. If LEA are running relays, it's most likely fewer than 10. Also, watching certain sites, like Google and Facebook, would be really hard, because they use distributed content delivery networks. A user in Seattle accesses a different server than a user in New York when they go to the same site. It might be useful for specific smaller sites, but if the attacker runs 10 relays, then the chances of picking 1 of them as 1 of your 3 entry guards is 1/30, or only 3%. And if you don't pick any of them, the attacker would have to wait 1-2 months for you to new pick news, with again only a 3% chance of pwning you. It's not an effective attack for identifying a specific person. More like, "among all the users of this site, I can find a few of them every few months".
Also, none of this applies to hidden services, since the attacker can't watch the other end, although there are different potential attacks there.
-
How many TOR users in % do you think has been identified by LE?
Through a direct attack on the Tor network, like the one described here? None that we know of.
People have been identified because they took pictures with identifying landmarks in the background, or because they accidentally connected to a (IRC) server over clearnet. There are lots of ways to fuck up and deanonymize yourself, but nobody has been deanonymized because of an attack on Tor.
-
Although you also need to take into consideration that the attacker probably just passively watches destinations of interest, so in practice they don't likely need to own your exit node, only your entry guard. If there are 900 entry guards and the attacker owns 100 of them, they own 1/9 entry guards. You select three entry guards every month to two months, and every time you do the chances the attacker owns one of them is 1/3.
True, true. Although you will only be accessing the destination web site 1/3 of the time through that one entry guard, if the purpose of the attack is to identity person X on the destination web site, you only need to go through the bad guard once.
Sounds like it is actually quite easy for LE to identify a TOR user? How many TOR users in % do you think has been identified by LE?
Probably close to 0%. Most observations to be had of how LE act against online criminals are from watching their CP operations. Historically LE see an IP address accessing a site of interest and they automatically think it is the suspect, add the IP to a list of leads and possibly follow through on it with raids. This works out for them probably well over 90% of the time, even today, as most people use no security measures at all. More recently they have started to use WiFi analyzers to see if open WiFi is being used by neighbors, as this is the level of security your average online criminal trying to be secure takes. Between assuming that the IP observed doing illegal shit belongs to the suspect and checking the identified area for open WiFi and using directional antennas to pinpoint the real culprit, LE are probably covered in 95% of cases. Sometimes they used to raid exit nodes , but that is becoming less common in most countries as they are starting to figure out what anonymity networks are. They have tried tracing backwards to suspects through anonymity networks, from the exit and get logs all the way back, but that only works out for them when the target consistently uses a static non-changing path over a period of months usually. Now they seem to mostly just ignore traffic from the networks they have failed to trace back through in the past, and focus their efforts on the people not using any security at all. It is probably horrible to bank on it, because imo Tor really doesn't provide adequate anonymity, but nothing I have seen from much researching into LE tactics and operations leads me to conclude that they are even attempting to do even moderately advanced traffic analysis attacks against people using large free route networks (versus cascade networks, where they will eventually get to their target by going back one node at a time with new court orders all the way back). The fact that they hacked into hidden services to deanonymize them is pretty strong proof that they don't know shit about traffic analysis, actually.
-
I get most of what you are saying, but some of it is very advanced. I try to keep up.
What is root privileges, and how would an attacker accomplish to get this? (Please explain, as simple as possible.)
Root privileges is the Linux version of administrator privileges, except it's the top administrator. The attacker would gain administrator privileges through a privilege escalation attack. TBB runs as the normal user, but an exploit could give the attacker higher privileges.
When I press "use a new identity" on vidalia, I change entry node, correct? How do I use entry guards instead?
No. You can specify entry nodes in the Tor configuration file, but that's for advanced users and you shouldn't mess with it. New Identity simply builds new circuits, but they go through the same entry guards. Entry guard selection is left for the Tor client.
You don't have to do anything to use entry guards. Your client uses them by default.
Thank you for the clarification. You answer a lot in your post above.
Say LE took control over a popular hidden service site. Out of 1000 visits from TOR users, in how many cases would LE be able to reveal the true ip?
-
Although you also need to take into consideration that the attacker probably just passively watches destinations of interest, so in practice they don't likely need to own your exit node, only your entry guard. If there are 900 entry guards and the attacker owns 100 of them, they own 1/9 entry guards. You select three entry guards every month to two months, and every time you do the chances the attacker owns one of them is 1/3.
True, true. Although you will only be accessing the destination web site 1/3 of the time through that one entry guard, if the purpose of the attack is to identity person X on the destination web site, you only need to go through the bad guard once.
Sounds like it is actually quite easy for LE to identify a TOR user? How many TOR users in % do you think has been identified by LE?
Well, that attack isn't trivial. It would be incredibly difficult to spin up 100 relays without getting noticed. If LEA are running relays, it's most likely fewer than 10. Also, watching certain sites, like Google and Facebook, would be really hard, because they use distributed content delivery networks. A user in Seattle accesses a different server than a user in New York when they go to the same site. It might be useful for specific smaller sites, but if the attacker runs 10 relays, then the chances of picking 1 of them as 1 of your 3 entry guards is 1/30, or only 3%. And if you don't pick any of them, the attacker would have to wait 1-2 months for you to new pick news, with again only a 3% chance of pwning you. It's not an effective attack for identifying a specific person. More like, "among all the users of this site, I can find a few of them every few months".
Also, none of this applies to hidden services, since the attacker can't watch the other end, although there are different potential attacks there.
The attacker cannot watch connections to the hidden service until they realize that they can trivially trace it to three entry guards with the brute force circuit construction attack, and then it is as anonymous as someone using *three* different non-stacked one hop proxies. Also attacker may only need to run the introduction nodes of the hidden service. For popular hidden services like SR the introduction nodes change rapidly because the clients DDOS them.
-
Thank you for the clarification. In the end of the day, How big is the risk for a TOR user to be identified? Assuming you are not giving personal info.
That's hard to quantify. What I can tell you is that Tor with TBB in its default configuration is the safest and most anonymous way to access clearnet sites, of all the options available on the Internet.
Accessing hidden services is safer than clearnet sites. Some argue that Freenet is safer than hidden services, but I have reservations about using Freenet and I2P because they are so small. It's easier to enumerate all IP addresses, and I'd rather not have my IP on some list, even if they can't prove what I'm doing. I'd rather mix in with the millions of Tor users and access hidden services instead.
Say you were to enter a site controlled by the attacker. Is that alone enough to reveal the true IP? Out of 1000 visits from TOR users, in how many cases would the attacker be able to reveal the true ip ?
From simply logging into the site? Assuming you don't provide identifying info, that alone won't deanonymize you. Again, there would have to be some specific attack, like the adversary tricking you into running malware, or selecting his relays for entry guards.
-
The attacker cannot watch connections to the hidden service until they realize that they can trivially trace it to three entry guards with the brute force circuit construction attack, and then it is as anonymous as someone using *three* different non-stacked one hop proxies. Also attacker may only need to run the introduction nodes of the hidden service. For popular hidden services like SR the introduction nodes change rapidly because the clients DDOS them.
Maybe, maybe not. FH probably gets more traffic, and the Hidden Wiki might be up there. Certainly running a very active intro point would put it on a short list of hidden services that it is hosting the descriptor for, but it may not be provable which one. Also, what's the point? The intro point can't MITM the connection and serve fake descriptors, because they are signed with the hidden service's private key. The intro point *could* correlate traffic to users who are also using an entry node under the attacker's control. In that case, the hidden service is as (un)safe as a clearnet site, but not less safe. Lastly, if the churn is high, the attacker won't be an intro point for long, so the attack is limited and then users are safer than when using clearnet sites again.
-
Of course, the attacker could fetch the descriptors of the popular hidden services and see if he connects to himself. In that case it would be provable.
I love discussions like this. They really get you thinking. :)
-
The attacker cannot watch connections to the hidden service until they realize that they can trivially trace it to three entry guards with the brute force circuit construction attack, and then it is as anonymous as someone using *three* different non-stacked one hop proxies. Also attacker may only need to run the introduction nodes of the hidden service. For popular hidden services like SR the introduction nodes change rapidly because the clients DDOS them.
Maybe, maybe not. FH probably gets more traffic, and the Hidden Wiki might be up there. Certainly running a very active intro point would put it on a short list of hidden services that it is hosting the descriptor for, but it may not be provable which one. Also, what's the point? The intro point can't MITM the connection and serve fake descriptors, because they are signed with the hidden service's private key. The intro point *could* correlate traffic to users who are also using an entry node under the attacker's control. In that case, the hidden service is as (un)safe as a clearnet site, but not less safe. Lastly, if the churn is high, the attacker won't be an intro point for long, so the attack is limited and then users are safer than when using clearnet sites again.
Actually I think it is trivial for introduction points to know which hidden services they are intro points for, they just need to as clients connect to the hidden service and see if they are the introductory point selected. It is the correlation that I am worried about not MITM. It makes the hidden service less safe actually, because now not only can the correlation attack happen if the attacker owns the hidden services entry guard(s), but it can also happen if it owns the hidden services introductory points. And the introductory points of popular hidden services change rapidly because they become DDOSed. So if you compare introductory points to exit nodes to clearnet sites, in this way they would be roughly equivalent in anonymity if we assume churn time is roughly the same (new introduction point selected once every ten minutes or so). But with connection to clearnet site, if a thousand users access it there are a thousand different possible exit node selections, and if one exit node selected is bad it only effects the client that selected it, most clients will not be using that exit node. But with introductory nodes there are only a handful of them that ALL clients connecting to the hidden service with in the same ten minute period have to pick from. Now if one of the clients is using a bad introductory node they are likely sharing that bad node with hundreds of other clients all trying to connect to the hidden service.
-
Not to mention that with connections to clearnet the client will not select the same node as entry and exit, but with connections to hidden services the client could very easily share an entry guard with the hidden service. Active timing attacks linking clients to clearnet websites require a minimum of two nodes, but the same attack can be done with a single compromised node against hidden services. And if the hidden services entry guard is owned by an attacker it is trivial for them to determine which hidden service they are the entry guard of, and thus obtain the hidden services real IP address.
-
actually during high load to popular hidden services a client is likely to try to connect to all of the hidden services introductory nodes, because they will most all be down from being overwhelmed with requests. In cases where this happens , it will essentially be as if all clients connecting to the hidden service share the same exit node.
-
subbed.
-
Actually I think it is trivial for introduction points to know which hidden services they are intro points for, they just need to as clients connect to the hidden service and see if they are the introductory point selected. It is the correlation that I am worried about not MITM. It makes the hidden service less safe actually, because now not only can the correlation attack happen if the attacker owns the hidden services entry guard(s), but it can also happen if it owns the hidden services introductory points. And the introductory points of popular hidden services change rapidly because they become DDOSed.
Do you have evidence for this? Intro points are used temporarily to establish a connection, but the bulk of the bandwidth is distributed through the rendezvous points. That's one of the reasons to use rendezvous points.
So if you compare introductory points to exit nodes to clearnet sites, in this way they would be roughly equivalent in anonymity if we assume churn time is roughly the same (new introduction point selected once every ten minutes or so).
That seems far fetched. Take this forum as an example. There are 100-150 concurrent users, but how many are accessing the forum for the first time at any moment? Probably not more than one every 10 seconds. 6 new users per minute, 60 in 10 minutes. That seems like a fair estimate. I'm sure three intro points can handle 6 or even 20 users per minute. Even if the main site has 3 times the traffic, it doesn't seem like they would get DDOSed.
But with connection to clearnet site, if a thousand users access it there are a thousand different possible exit node selections, and if one exit node selected is bad it only effects the client that selected it, most clients will not be using that exit node. But with introductory nodes there are only a handful of them that ALL clients connecting to the hidden service with in the same ten minute period have to pick from. Now if one of the clients is using a bad introductory node they are likely sharing that bad node with hundreds of other clients all trying to connect to the hidden service.
I don't think that's going to be more than a few hundred people, even on the busiest hidden service.
-
The intro points shouldn't get DDOSed harder than the entry guards, because all of the traffic from 150 clients, going through more than 100 rendezvous points (presumably some clients use the same rend points) coalesces at the entry guards. So if the entry guards are ok, I think the intro points should be ok.
-
Do you have evidence for this? Intro points are used temporarily to establish a connection, but the bulk of the bandwidth is distributed through the rendezvous points. That's one of the reasons to use rendezvous points.
They are not drained of bandwidth but they have their CPU overwhelmed from all the crypto operations they need to do. Rendezvous points are from a much larger set of total nodes and each client connecting to a hidden service selects its own. The introduction points are from a small set of nodes and each client connecting to the hidden service uses a node from the same set. There are people who run relays putting in support tickets asking why their CPU usage suddenly jumps up to almost 100% and right now the answer is that they are probably selected as introduction points by popular hidden services.
https://trac.torproject.org/projects/tor/ticket/3825
It's not a matter of hidden services picking unreliable relays for use as intro points. The problem is that being chosen as one of a popular hidden service's intro points makes a relay unreliable, because clients start extending many more circuits to HS intro points, and due to the client-side part of this bug, when the relay starts to become overloaded, the clients respond by overloading it harder.
There have been many bugs related to popular hidden services (they tend to have poor reachability), several have to do with introduction points being overloaded. They have been working on these issues for a long time now and making improvements, but there are still recent reports of Tor relays being essentially totally drained of CPU processing power, and when this happens they cannot continue acting as introduction points. I am not sure the current status of this group of bugs, but I believe it still causes rapidly changing introduction points.
That seems far fetched. Take this forum as an example. There are 100-150 concurrent users, but how many are accessing the forum for the first time at any moment? Probably not more than one every 10 seconds. 6 new users per minute, 60 in 10 minutes. That seems like a fair estimate. I'm sure three intro points can handle 6 or even 20 users per minute. Even if the main site has 3 times the traffic, it doesn't seem like they would get DDOSed.
Your mistake is thinking that the DDOS is from bandwidth being overwhelmed instead of CPU. There are plenty of tickets related to introduction points being DDOSed I suggest reading up on the issue if you are interested in its current status. You do have a good point though, that clients already connected to the hidden service when an attacker gains control of the introduction point have nothing to worry about. But while an attacker owns the introduction point, all new connections to the hidden service though that introduction point are susceptible to timing attacks (provided the attacker also can observe entry traffic from the connecting client). So assuming new introduction points are selected every ten minutes, that is still roughly the same level of protection from timing attacks as connections to clearnet.
I don't think that's going to be more than a few hundred people, even on the busiest hidden service.
I have no idea how many people connect to the silk road market at the same time, or if this forum is on the same server for that matter, but hundreds of people connect to here at the same time. I wouldn't be surprised if over a thousand people connect to the main market at the same time, although I never go there so who knows. I do know it has been linked to from several news websites though, and that it has many more registered users than the forums do, so I imagine it is more active than the forums are.
The intro points shouldn't get DDOSed harder than the entry guards, because all of the traffic from 150 clients, going through more than 100 rendezvous points (presumably some clients use the same rend points) coalesces at the entry guards. So if the entry guards are ok, I think the intro points should be ok.
If there are 100 clients and 3 introduction points, assuming equal distribution for ease of example, each introduction point needs to handle cryptographic operations for roughly 33 clients. The clients all have three entry guards and use one per connection, so it is entirely possible that none of the 100 clients share an entry guard used to connect to the introduction points. I do see your point about the HS entry guards though, as they will need to handle just as many create cells on average as the introduction nodes, assuming that all attempts to access the hidden service are successful. Unfortunately, attempts to access hidden services are not always successful. When clients fail to establish a connection to the HS , they try again and again building new circuits to the introduction nodes, but not having their sent data make it all the way to the hidden services entry guards. The entry guards for the hidden service will handle 33 circuits in the mentioned scenario, whereas the introduction points may need to handle dozens of circuits for each of the connecting clients that try and repeatedly fail to use them. Last I read about this rransom was working on a fix to stop clients from repeatedly spamming the intro points, but I don't believe he ever perfectly fixed it because I still see my Tor opening dozens of failed circuits when it tries to connect to a hidden service that currently appears to be down to it. Does anyone else still see this behavior ?
Also currently it looks like hidden services use up to ten introduction nodes. When one introduction node is overwhelmed and cannot process the users connection in a timely manner, Tor rips down the circuit and tries another introduction node. So assuming there are ten introduction nodes and they are all overwhelmed, that means a connecting client will establish at least ten circuits to ten different potentially attacker controlled nodes. If they continue doing this over a period of say thirty minutes, and the introduction nodes rotate every ten minutes and are quickly overwhelmed, that would translate into up to thirty different attacker controlled introduction nodes being accessed in a period of 30 minutes, or one per minute. This may be a worst case scenario, but I have had periods of time where I can not establish a connection to the forums for half an hour or longer because of overwhelmed introduction nodes (made clear by the fact that Tor opened dozens of circuits that all failed, and the fact that people were still able to access the forum if they had an active rendezvous point, so it was not down). That could be roughly equivalent to using a new exit node once every minute to access clearnet sites.
-
you also need to take into account that when clients fail to establish a connection to a hidden service, the user tends to hit refresh and try again. So when you take hundreds of users trying to establish a connection * Tor retrying to establish a connection several dozen times * the user refreshing and restarting the process , that = thousands and thousands of cryptographic operations for the introduction nodes, but the hidden services entry guards only need to process one create cell per successfully established connection.