Silk Road forums
Discussion => Silk Road discussion => Topic started by: vanilla on June 12, 2013, 05:29 am
-
I came across this earlier tonight and it troubled me deeply. Basically details how SR could be de-anonymized for $11,000. Clearnet link... Anyone with way more technical knowledge than me care to comment? Should we be worried?
https://plus.google.com/114798402540078632611/posts/i45Ma63cMgg
-
Did you send it to DPR?
-
I did not send it to DPR directly but I hope that by putting it here this post might garner enough attention that he will see it. Feel free to contact him and direct him to the thread. Frankly, I wanted to get some input from some of the community's more knowledgeable people before bothering DPR with it.
-
I did not send it to DPR directly but I hope that by putting it here this post might garner enough attention that he will see it. Feel free to contact him and direct him to the thread. Frankly, I wanted to get some input from some of the community's more knowledgeable people before bothering DPR with it.
That's true, but when someone makes that bold of a claim I'm sure he/she/it wouldn't mind giving it a look over. I'd probably send it to pine too, just to see what the platypus has to say on such a thing.
-
it is unlikely the servers are traceable back to anyone except fictitious identities payed for in bitcoin. i wouldn't worry too much.
-
Yeah, so um... they've got some of their technical details... well they're either just straight up wrong, they're talking about an earlier protocol of Tor (despite their explicit claim to be referencing the current design), or I'm just too fucking exhausted to follow their paper. My money's on it being a prior version of the onion routing protocol. Which is pretty fucked up given their opening paragraphs; but frankly I'm too tired to read the whole thing... still, that's my opinion based on skimming their description of how the network they're attacking works. Even some of their diagrams aren't right...
I wouldn't worry about this. I think they're outdated, or... fucking something, I don't know. I'll come back to it another time. Don't forget, in academia, you either publish or perish -- nobody says it has to be useful ;D
-
FYI, Mike Hearn is a Google employee and Bitcoin developer.
Anyway: http://dkn255hz262ypmii.onion/index.php?topic=161391.msg1160970#msg1160970
The threat is real.
-
The threat is real.
*cue dramatic music*
-
Thanks for the link, vanilla. I've passed it up to DPR in case he/she hasn't seen it yet.
Libertas
-
*cue dramatic music*
It's pretty well known that Tor is insecure with respect to the default configuration for hidden services. An attacker can find the entry guards in under 2 hours. That's not news. One such attack has been in the literature since 2006.
However, there are measures a hidden service can take to mitigate these attacks, and I'm sure DPR and gang are well ahead of LE and researchers in their defenses.
-
However, there are measures a hidden service can take to mitigate these attacks, and I'm sure DPR and gang are well ahead of LE and researchers in their defenses.
No doubt!
Libertas
-
FYI, Mike Hearn is a Google employee and Bitcoin developer.
Anyway: http://dkn255hz262ypmii.onion/index.php?topic=161391.msg1160970#msg1160970
The threat is real.
But it can't be; here's their description of hidden services:
The Tor hidden service architecture:
1. Internet service which is available as Tor hidden service;
2. Client, which wants to access hidden service;
3. Introduction Points, tor relays chosen by the hidden service and which are used for forwarding management cells necessary to connect the Client and the Hidden Service at the Rendezvous point;
4. Hidden Service directories (HSDir): Tor relays at which the hidden service publishes its descriptors and which are communicated by clients in order to learn the address of the hidden service's introduction points;
5. Rendezvous point (RP): a Tor relay chosen by the client which is used to forward all the data between the client and the hidden service.
That's... not, quite accurate. It's leaving out guards, which is what had me thinking it was the protocol before their introduction. But sure, maybe they skimmed over it (or I missed it in my own skimming). But further on, they clearly state:
In order to establish a connection to a given hidden service Alice's OP [note: onion proxy] first builds a rendezvous circuit (step 4). It does this by establishing a circ uit to a randomly chosen Tor relay (OR) [note: onion router], and sending a RELAY_COMMAND_ESTABLISH_RENDEZVOUS cell to that OR. The body of that cell contains a Rendezvous cookie (RC). The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by Alice's OP... ... ... Alice builds a separate circuit to one of Bob's chosen introduction points, and sends it a RELAY_COMMAND_INTRODUCE1 cell containing the IP address and the fingerprint of the rendezvous point, the hash of the public key of the hidden service (PK_ID), and the rendezvous cookie (step 5).
If the introduction point recognizes PK_ID as the public key of a hidden service it serves, it sends the body of the cell in a new RELAY_COMMAND_INTRODUCE2 cell down the corrsponding circuit (step 6).
When Bob's OP receives the RELAY_COMMAND_INTRODUCE2 cell, it decrypts it using the private key of the corresponding hidden service and extracts the rendezvous point's nickname as well as the rendezvous cookie.
Sure, that's all well and good... except they STILL haven't mentioned the fucking guards? It's like they're analyzing the network before guards were introduced. Now in fairness they go on to talk about them when detailing their next attack, but there's weirdness there. Before skipping to VI A though, this line in V A caught my eye:
Just like any Tor client, an attacker is able to compute the descriptor IDs of the hidden service for any moment in the future and find the fingerprints of expected responsible HS directories. After that she can compute the private/public key pairs so that SHA-1 hash of the public keys would be in-between the descriptor ID and the fingerprint of the first responsible hidden service directory. The attacker then runs Tor relays with the computer public/private key pairs and waits for 25 hours until they obtain the HSDir flag.
I thought you could only calculate the descriptor IDs 24 hours in advance, but whatever, skipping that: how can this be possible at all, since even assuming they get to the point of impersonating the HSDirs in question due to the properties of the distributed hash table... they still won't have the private key for those servers that the 6 (is it 6?) authoritative directories will be checking for, and so will be ignored anyway?
Last bit I actually skimmed; I'm sick of quoting this paper, but again:
In order to confirm that an attacker controls a guard node of a hidden service she needs to control at least one more Tor non-exit relay. In the attack, the hidden service is forced to establish rendezvous circuits to the rendezvous point controlled by the attacker.
...
If all the conditions are satisfied, the attacker decides that her guard node was chosen for the hidden service's rendezvous circuit and marks the previous node in the circuit as the origin of the hidden service.
I skipped over some stuff because I"m tired, but I don't understand how this is possible, unless you're running Tor over Tor...? How can a guard ever be chosen as an introduction point for a hidden service -- the guard knows what hidden service it's a guard for, why in God's name would it blindly say "sure, I'll be the rendezvous point for my pal there!" ???
-
Good reading guys. thanks.
-
imagine how paranoid DPR must be! Anything so little out of the ordinary such as a strange car passing by and he probably thinks the feds are onto him!!
-
Thanks for the link, vanilla. I've passed it up to DPR in case he/she hasn't seen it yet.
Libertas
Hey just a heads up if you don't know someone's gender it's grammatically correct to say he instead of he/she. Not trying to be a dick. :)
Anyway, from skimming the paper I'm not sure this attack would really be that effective; I have no experience with Hidden Services development though, so take my opinion as you will.
-
That's because the FEDS are probably on to him.
-
This is unnerving. It doesn't seem to pose a threat to the users but to SR itself. Although we know here the drug war all to well, and we know there is always a way around it. If SR goes then there will be another to take its place. Except a new SR probably wouldn't be so open and maybe even invite. SR is only in danger because a lot of kids end up here after a few google searches and then cry to the authorities when their mommy intercepts their orders. SR needs to go low profile.
-
That's... not, quite accurate. It's leaving out guards, which is what had me thinking it was the protocol before their introduction. But sure, maybe they skimmed over it (or I missed it in my own skimming). But further on, they clearly state:
....
Sure, that's all well and good... except they STILL haven't mentioned the fucking guards? It's like they're analyzing the network before guards were introduced. Now in fairness they go on to talk about them when detailing their next attack, but there's weirdness there. Before skipping to VI A though, this line in V A caught my eye:
Well, they're describing the first part of the attack. The other part is to flood the network with guards, the economics of which is described in VI.C:
In early 2012 we operated a guard node that we rented from a large European hosting company (Server4You, product EcoServer Large X5) for EUR 45 (approx. USD 60) per month. Averaging over a month and taking the bandwidth weights into account we calculated that the probability for this node to be chosen as a guard node was approximately 0.6% on average for each try a Tor client made that month. As each hidden service chooses three guard nodes initially, we expect over 450 hidden services to have chosen this node as a guard node10 . Running these numbers for a targeted (non-opportunistic) version of the attack described in Section VI-A shows us that by renting 23 servers of this same type would give us a chance of 13.8% for any of these servers to be chosen. This means that within 8 months, the probability to deanonymize a long-running hidden service by one of these servers becoming its guard node is more than 90%, for a cost of EUR 8280 (approximately USD 11,000).
Just like any Tor client, an attacker is able to compute the descriptor IDs of the hidden service for any moment in the future and find the fingerprints of expected responsible HS directories. After that she can compute the private/public key pairs so that SHA-1 hash of the public keys would be in-between the descriptor ID and the fingerprint of the first responsible hidden service directory. The attacker then runs Tor relays with the computer public/private key pairs and waits for 25 hours until they obtain the HSDir flag.
I thought you could only calculate the descriptor IDs 24 hours in advance
Unless a cookie is set with the HiddenServiceAuthorizeClient option, the descriptor IDs are deterministic and computable arbitrarily into the future:
Tor hidden service desc_id‘s are calculated deterministically and if there is no ‘descriptor cookie’ set in the hidden service Tor config anyone can determine the desc id‘s for any hidden service at any point in time.This is a requirement for the current hidden service protocol as clients must calculate the current descriptor id to request hidden service descriptors from the HSDir’s. The descriptor ID’s are calculated as follows:
descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica))
The replica is an integer, currently either 0 or 1 which will generate two separate descriptor ID’s, distributing the descriptor to two sets of 3 consecutive nodes in the DHT. The permanent-id is derived from the service public key. The hash function is SHA1.
time-period = (current-time + permanent-id-byte * 86400 / 256) / 86400
The time-period changes every 24 hours. The first byte of the permanent_id is added to make sure the hidden services do not all try to update their descriptors at the same time.
identity-digest = H(server-identity-key)
The identity-digest is the SHA1 hash of the public key generated from the secret_id_key file in Tor’s keys directory. Normally it should never change for a node as it is used for to determine the router’s long-term fingerprint, but the key is completely user controlled.
but whatever, skipping that: how can this be possible at all, since even assuming they get to the point of impersonating the HSDirs in question due to the properties of the distributed hash table... they still won't have the private key for those servers that the 6 (is it 6?) authoritative directories will be checking for, and so will be ignored anyway?
I'm not sure what you're asking here.
In order to confirm that an attacker controls a guard node of a hidden service she needs to control at least one more Tor non-exit relay. In the attack, the hidden service is forced to establish rendezvous circuits to the rendezvous point controlled by the attacker.
...
If all the conditions are satisfied, the attacker decides that her guard node was chosen for the hidden service's rendezvous circuit and marks the previous node in the circuit as the origin of the hidden service.
I skipped over some stuff because I"m tired, but I don't understand how this is possible, unless you're running Tor over Tor...? How can a guard ever be chosen as an introduction point for a hidden service -- the guard knows what hidden service it's a guard for, why in God's name would it blindly say "sure, I'll be the rendezvous point for my pal there!" ???
The guard node isn't the intro point. The guard and rendezvous nodes are controlled by the attacker.
-
ANYONE WHO IS A THREAT TO THE ROAD SHOULD BE KILLED!! PERIOD!
its the best way to protect anything
-
Can't kill technology, man. The threat is not Mike Hearn for discussing this paper, nor the people that wrote it. There are flaws in the tor/.onion system that hopefully can be addressed. The tech is there regardless if anyone dies or not.
-
ANYONE WHO IS A THREAT TO THE ROAD SHOULD BE KILLED!! PERIOD!
its the best way to protect anything
Oh cool. Then we become another violent cartel.
-
But it can't be; here's their description of hidden services:
The Tor hidden service architecture:
1. Internet service which is available as Tor hidden service;
2. Client, which wants to access hidden service;
3. Introduction Points, tor relays chosen by the hidden service and which are used for forwarding management cells necessary to connect the Client and the Hidden Service at the Rendezvous point;
4. Hidden Service directories (HSDir): Tor relays at which the hidden service publishes its descriptors and which are communicated by clients in order to learn the address of the hidden service's introduction points;
5. Rendezvous point (RP): a Tor relay chosen by the client which is used to forward all the data between the client and the hidden service.
That's... not, quite accurate. It's leaving out guards, which is what had me thinking it was the protocol before their introduction. But sure, maybe they skimmed over it (or I missed it in my own skimming). But further on, they clearly state:
Notice that they left out the entire Tor circuit, I assume because they imagine we have a basic idea of how Tor works, but might not know the intricate details of the hidden service specific algorithms.
In order to establish a connection to a given hidden service Alice's OP [note: onion proxy] first builds a rendezvous circuit (step 4). It does this by establishing a circ uit to a randomly chosen Tor relay (OR) [note: onion router], and sending a RELAY_COMMAND_ESTABLISH_RENDEZVOUS cell to that OR. The body of that cell contains a Rendezvous cookie (RC). The rendezvous cookie is an arbitrary 20-byte value, chosen randomly by Alice's OP... ... ... Alice builds a separate circuit to one of Bob's chosen introduction points, and sends it a RELAY_COMMAND_INTRODUCE1 cell containing the IP address and the fingerprint of the rendezvous point, the hash of the public key of the hidden service (PK_ID), and the rendezvous cookie (step 5).
If the introduction point recognizes PK_ID as the public key of a hidden service it serves, it sends the body of the cell in a new RELAY_COMMAND_INTRODUCE2 cell down the corrsponding circuit (step 6).
When Bob's OP receives the RELAY_COMMAND_INTRODUCE2 cell, it decrypts it using the private key of the corresponding hidden service and extracts the rendezvous point's nickname as well as the rendezvous cookie.
Sure, that's all well and good... except they STILL haven't mentioned the fucking guards? It's like they're analyzing the network before guards were introduced. Now in fairness they go on to talk about them when detailing their next attack, but there's weirdness there. Before skipping to VI A though, this line in V A caught my eye:
They probably have not mentioned guards yet because so far they are completely irrelevant to what they are discussing, which is the hidden service protocol. All of the circuits utilized make use of guard nodes, but there isn't any particular reason for them to point this out yet.
Just like any Tor client, an attacker is able to compute the descriptor IDs of the hidden service for any moment in the future and find the fingerprints of expected responsible HS directories. After that she can compute the private/public key pairs so that SHA-1 hash of the public keys would be in-between the descriptor ID and the fingerprint of the first responsible hidden service directory. The attacker then runs Tor relays with the computer public/private key pairs and waits for 25 hours until they obtain the HSDir flag.
I thought you could only calculate the descriptor IDs 24 hours in advance, but whatever, skipping that: how can this be possible at all, since even assuming they get to the point of impersonating the HSDirs in question due to the properties of the distributed hash table... they still won't have the private key for those servers that the 6 (is it 6?) authoritative directories will be checking for, and so will be ignored anyway?
They are not impersonating hidden service directories, they are making it so that they are selected as the hidden service directories.
Last bit I actually skimmed; I'm sick of quoting this paper, but again:
In order to confirm that an attacker controls a guard node of a hidden service she needs to control at least one more Tor non-exit relay. In the attack, the hidden service is forced to establish rendezvous circuits to the rendezvous point controlled by the attacker.
...
If all the conditions are satisfied, the attacker decides that her guard node was chosen for the hidden service's rendezvous circuit and marks the previous node in the circuit as the origin of the hidden service.
I skipped over some stuff because I"m tired, but I don't understand how this is possible, unless you're running Tor over Tor...? How can a guard ever be chosen as an introduction point for a hidden service -- the guard knows what hidden service it's a guard for, why in God's name would it blindly say "sure, I'll be the rendezvous point for my pal there!" ???
This is a slight modification to the attack from 2006 that caused guard nodes to be introduced in the first place, essentially they are saying that if they are selected as the hidden services guard node they can deanonymize the hidden service by making it open a circuit to their malicious rendezvous node (which actually isn't even required, since they can just be the client, which is in itself enough for 1/2 of a timing attack). It doesn't say anything about introduction points.
I still have not read this paper but it seems that they are talking about two different attacks. One attack works to censor the hidden service, and also to position yourself for 1/2 of a timing attack against the hidden service and/or its clients, but the other attack is for enumeration of all hidden service .onion addresses, which can then be used in combination with the 2006 attack to deanonymize some percentage of the identified hidden services. In the 2006 attack they brute force circuits by making the server open new circuits to rendezvous node until they own its entry node, in this attack they 'brute enumerate' hidden services in the hopes that they own some of their entry guards.
-
ANYONE WHO IS A THREAT TO THE ROAD SHOULD BE KILLED!! PERIOD!
its the best way to protect anything
Oh cool. Then we become another violent cartel.
thats exactly what i was thinking!! (cartels) lol
they know how to protect a very lucrative business!!! kill anyone who gets in the way!!!
-
Can't kill technology, man. The threat is not Mike Hearn for discussing this paper, nor the people that wrote it. There are flaws in the tor/.onion system that hopefully can be addressed. The tech is there regardless if anyone dies or not.
Not to mention that if you kill all of the people finding attacks on Tor, nobody will work on Tor anymore, because all of the Tor developers also research how to attack Tor. Look at Roger Dingledine, he has his name on a lot of papers that demonstrate attacks against Tor. He is also the lead Tor developer. The person saying we should kill the anonymity researchers has got to be the stupidest fucking person in the world, he should get a prize or something.
-
sub'd
-
DPR does not take security lightly.. and quite frankly, he is actually EXTREMELY intelligent. I know this for a fact. He knows his shit.
Good to be vigilant at all times of course, but only "threats" to SR are at time going to be the human element(s), definetly not the tech/infrastructural.
i.e. vendors dealing IRL/customers blabbing about SR to idiot friends who log in via clearnet, etc etc. Those kinds of "threats" will always be reason to be vigilant. As far as a technically.. I wouldn't worry too much about that. The Pirate knows what he's doing. 8)
-
Can't kill technology, man. The threat is not Mike Hearn for discussing this paper, nor the people that wrote it. There are flaws in the tor/.onion system that hopefully can be addressed. The tech is there regardless if anyone dies or not.
Not to mention that if you kill all of the people finding attacks on Tor, nobody will work on Tor anymore, because all of the Tor developers also research how to attack Tor. Look at Roger Dingledine, he has his name on a lot of papers that demonstrate attacks against Tor. He is also the lead Tor developer. The person saying we should kill the anonymity researchers has got to be the stupidest fucking person in the world, he should get a prize or something.
+10. In fact the developers are doing a huge service to DPR and others who run similar illicit hidden sites by pointing out potential vulnerabilities before they are exploited by malevolent folks. I have faith that the Pirate and team have an exceptional security system in place and continually stay up to date on information security developments.
-
Great info, subbed the shit out of this thread
-
Not to mention that if you kill all of the people finding attacks on Tor, nobody will work on Tor anymore, because all of the Tor developers also research how to attack Tor. Look at Roger Dingledine, he has his name on a lot of papers that demonstrate attacks against Tor. He is also the lead Tor developer. The person saying we should kill the anonymity researchers has got to be the stupidest fucking person in the world, he should get a prize or something.
Then we can live in the ignorant bliss that our network is secure. That's what I tell the I2P folks when they mention that there are few known attacks on it. That only proves that few people are looking at it.
-
+10. In fact the developers are doing a huge service to DPR and others who run similar illicit hidden sites by pointing out potential vulnerabilities before they are exploited by malevolent folks.
Yep. It's better that an honest researcher proves these attacks work and makes them publicly known (in fact, the Tor devs knew about this months before it was made public) than a malicious person discovers an attack and keeps it to himself.
-
+10. In fact the developers are doing a huge service to DPR and others who run similar illicit hidden sites by pointing out potential vulnerabilities before they are exploited by malevolent folks.
Yep. It's better that an honest researcher proves these attacks work and makes them publicly known (in fact, the Tor devs knew about this months before it was made public) than a malicious person discovers an attack and keeps it to himself.
because men are superior 8)
-
+10. In fact the developers are doing a huge service to DPR and others who run similar illicit hidden sites by pointing out potential vulnerabilities before they are exploited by malevolent folks.
Yep. It's better that an honest researcher proves these attacks work and makes them publicly known (in fact, the Tor devs knew about this months before it was made public) than a malicious person discovers an attack and keeps it to himself.
Hell the Tor devs probably knew about this from the moment they implemented hidden services. It is obvious to anybody who knows how hidden services work.
-
but whatever, skipping that: how can this be possible at all, since even assuming they get to the point of impersonating the HSDirs in question due to the properties of the distributed hash table... they still won't have the private key for those servers that the 6 (is it 6?) authoritative directories will be checking for, and so will be ignored anyway?
I'm not sure what you're asking here.
Frankly, neither am I anymore... I think I had assumed that there was an additional check in place involving an identity key.
In order to confirm that an attacker controls a guard node of a hidden service she needs to control at least one more Tor non-exit relay. In the attack, the hidden service is forced to establish rendezvous circuits to the rendezvous point controlled by the attacker.
...
If all the conditions are satisfied, the attacker decides that her guard node was chosen for the hidden service's rendezvous circuit and marks the previous node in the circuit as the origin of the hidden service.
I skipped over some stuff because I"m tired, but I don't understand how this is possible, unless you're running Tor over Tor...? How can a guard ever be chosen as an introduction point for a hidden service -- the guard knows what hidden service it's a guard for, why in God's name would it blindly say "sure, I'll be the rendezvous point for my pal there!" ???
The guard node isn't the intro point. The guard and rendezvous nodes are controlled by the attacker.
Yeah, I... yeah. I shouldn't try making technical posts to things I've only read on day 2 or 3 awake; what can I say, it's a hard lesson to remember :P