How was the Silk Road run?

[Coldblackice]

Anyone know how the Silk Road was run (or at least, likely/hypothetically run)?

...purely for curiosity's sake, of course

But for real -- how would/could someone go about running something like this, not only for so long, but from within the United States?

I just can't understand how one would go about setting up some hotly-trafficked community, hosted from within the United States, and be actively running/maintaining/interacting with such.

Where do you guess it was being hosted? How would the web host not know what was up? Did it all just come down to using Tor for absolutely everything?

 

[TCM]

Do you know how a Tor hidden service operates?

 

[Lunas]

The mmo?i used to play that like 5 years ago...

The drugs for bit coins thing not sure the first i herd of it was on the news

 

[teh_chem]

With Tor, a very broad generalization is that your internet activity is routed and rerouted through multiple locations and is encrypted at each point; theoretically completely obfuscating your activity from being tracked to any real extent. But when it comes to physical items and transactions, I think that amount of security breaks down, so the strength of this sort of thing ends when it comes to actual physical transactions (especially of illegal activity)--physical items can be tracked fairly easily.

I don't know anything about Silk Road to any extent of detail--so I completely admit to being wrong--but my guess is authorities knew who the likely culprit was for quite some time, they were probably just amassing evidence during that time to solidify a case. Anonymity--at least IMO--is more of an illusion than a reality in most cases.

 

[TCM]

It's not encrypted at each point. It's encrypted by the client only.

 

[lilfiend]

When using TOR you send data to an entry node, unencrypted, then that node encrypts it (and snoops it if its ran by the NSA/FBI) and sends it along to a bridge node, which, IIRC, re-encrypts it, then sends it along to an exit node, which decrypts it and sends it to the website you're trying to access, which if its a .onion, AFAIK does the same thing in reverse for the most part.

 

[TCM]

Could you guys at least read the papers? What would be the point if the client sends unencrypted data to the first node? That would compromise who the client is and what target it's trying to reach all in a single step. Also, it would be stupid.

Roughly, it works like this:

To send data via Tor, the Tor client serves as a SOCKS proxy to the browser and picks 3 nodes from the publicly available directory. It encrypts the data with the last node's public key[1], then with the middle node's key and finally with the entry node's key and sends it off to the entry node.

Entry node peels off the outer layer using his private key and sends it off to the middle node. Middle node peels off the 2nd layer using his private key and sends it to the exit node. Exit node decrypts the last layer and sends the packet off to its destination. That's the whole meaning of "onion" routing. Each node only knows its direct neighbour nodes, so the exit node doesn't know the entry node and vice versa and the middle node doesn't know anything about the client or its destination.

Browser ---SOCKS--- Tor client - - - entry node - - - middle node - - - exit node ----- destination

----- unencrypted, - - - encrypted

In the case of a hidden service, the data ends somewhere in the Tor network with noone knowing where exactly.

[1] Most probably the usual method of picking a random symmetric cipher key is used since encrypting payload with public key crypto would be way too slow.

 

[MekoSuka]

TOR can be very effective at hiding ones internet communications. The FBI and NSA have had only a modicum of success in tracking most individuals who use it. The difference with Silk Road was that they setup shop within the network, and as others have mentioned here processed transactions for goods. This makes you more of a stationary target than a moving one.

The weakest part of TOR is the exit node. You do not know who is running them and what intentions they have over forwarding your traffic. There have been many posts on how easy it is to setup your own exit node and run an MiTM to capture logins etc... This includes SSL comms.

 

[MekoSuka]

This was posted a week ago ...

NSA Tracks Google Ads

and Schneier wrote this on the 7th:

Bruce Schneier

 

[HoppyChris]

Well, coldblackice, the first rule of sellin' drugs on the internets is not talking about selling drugs on the internets, which was one of the things that got the silk road guy caught.

Other people have talked about Tor and how it's generally secure, but a good point that I saw made recently is that if you're running the next Silk Road, it only takes one mistake to get caught and it might not even be you making that mistake.

Apparently the hosting question was another of the things that got him caught, as there were 9 fake ids with the guy's face on them allegedly to be used to obtain more servers.

So in short, running a website using Tor isn't terribly difficult, but not letting on that you're about to beforehand, managing to host a complicated and popular website, and really just not putting yourself in a situation where you feel like you need to have someone killed are the hard parts.

Oh, and also bitcoins aren't nearly as anonymous as people want to believe (every transaction is logged forever, look up bitcoin laundering for more info before you start in on your new career!)

Good luck!

 

[Biznatch]

TOR can be very effective at hiding ones internet communications. The FBI and NSA have had only a modicum of success in tracking most individuals who use it. The difference with Silk Road was that they setup shop within the network, and as others have mentioned here processed transactions for goods. This makes you more of a stationary target than a moving one.

The weakest part of TOR is the exit node. You do not know who is running them and what intentions they have over forwarding your traffic. There have been many posts on how easy it is to setup your own exit node and run an MiTM to capture logins etc... This includes SSL comms.

As far as I know, there is still no way to do a MITM against SSL traffic without alerting the user. Unless they have a valid cert for that domain issued by the root cert. Any attempt to mess with that chain will cause the browser to throw a cert error and stop the site from loading unless the user allows it. I'd like to think most of the TOR users are smart enough to not allow, and I'm sure there is some kind of way to report a rogue node to TOR to remove them from the list.

 

[MekoSuka]

As far as I know, there is still no way to do a MITM against SSL traffic without alerting the user.

You are partially correct. You can break the SSL connection unannounced to the user and even alter the content of the page in the process thereby deceiving said user.

Search for SSLStrip and find the Blackhat presentation (*Thought it was Defcon --edited) from 2009.

Actually, here it is ...

http://player.vimeo.com/video/50018478

I've also done this against my own environment (in a lab) and pilfered uid/pw and stolen 2FA PINs etc...

The presentation is well worth the 1 hour it is in time.

Keep in mind that you can perform something similar to sslstrip on your own SSL sessions using tools such as Burp etc... and your browser would never tell you. Burp is freely is available on the pentest suite Kali.

 

[devman]

You are partially correct. You can break the SSL connection unannounced to the user and even alter the content of the page in the process thereby deceiving said user.

Search for SSLStrip and find the Blackhat presentation (*Thought it was Defcon --edited) from 2009.

Actually, here it is ...

http://player.vimeo.com/video/50018478

I've also done this against my own environment (in a lab) and pilfered uid/pw and stolen 2FA PINs etc...

The presentation is well worth the 1 hour it is in time.

Keep in mind that you can perform something similar to sslstrip on your own SSL sessions using tools such as Burp etc... and your browser would never tell you. Burp is freely is available on the pentest suite Kali.

This is one of the attack vectors (not specifically Tor, the same type of attack can be launched from any gateway) HTTP STS is being introduced to combat. That still, however, requires you to have connected to the legit site at least once in the past.

 

[MekoSuka]

This is one of the attack vectors (not specifically Tor, the same type of attack can be launched from any gateway) HTTP STS is being introduced to combat. That still, however, requires you to have connected to the legit site at least once in the past.

I believe that you're still susceptible if you're first hitting an http site and then being redirected to SSL due to sslstrip's ability to mod headers.

Also, isn't the only difference with STS in play and someone is running sslstrip, that the browser goes back to throwing a certificate error? If that's the case, YMMV on getting users to accept.

*edit it looks like some others have been talking about this as well: BT Forums

It would appear I've also gone astray on this thread :/

 

[devman]

I believe that you're still susceptible if you're first hitting an http site and then being redirected to SSL due to sslstrip's ability to mod headers.

Also, isn't the only difference with STS in play and someone is running sslstrip, that the browser goes back to throwing a certificate error? If that's the case, YMMV on getting users to accept.

*edit it looks like some others have been talking about this as well: BT Forums

It would appear I've also gone astray on this thread :/

HTTP STS header isn't honored unless its served over an HTTPS connection, so the STS status a user-agent holds for a particular host can only be modified over an HTTPS session with that host the user-agent accepts.

Its true that an attacker that could attempt to get the user to click through a cert warning to a bogus site served up under the same domain, but that is no different than a traditional pharming attack. DNSSEC would be required to mitigate that vector (or simply not accepting the bogus cert).

An attacker could try to serve a redirect to a similar looking domain with a legit SSL controlled by the attacker (this would be a standard phishing attack), but again HTTP STS defeats this as the user-agent will ignore any response from the host over HTTP (assuming an STS policy has been established from a previous connection), that isn't an SSL upgrade.

 

[MekoSuka]

Yea, this is why I find myself more and more modifying the user-agent string to get around some of the better encrypted sites. Since STS isn't fully deployed everywhere and since many of the mobile versions of sites are typically the weakest link, this still serves a purpose.

*Disclaimer: I do this in testing only

One can assume that this hack will eventually run its course the same way others have, while new hacks become more prevalent. The main point of this was to simply show there are ways to defeat SSL from an end to end standpoint and not have the browser inform the user of such an act.