Silk Road bust - forensics & OpSec analysis

Delivering real-world network security requires meticulous study of failure cases; when things break, we learn alot about how to make less-breakable things. Here is where we examine failure, not as Schadenfreude wallow but rather as an essential analytic tool for security improvements.
Guest

Silk Road bust - forensics & OpSec analysis

Postby Guest » 03 Oct 2013, 05:46

{posts split off from the "Torsploit reloaded" thread, for ease of visual reference ~ pj}

Silk Road (SR) wasn't hosted at Freedom Hosting (FH). If it was, Dread Pirate Roberts (DPR) would have had a good belief that the entire site was compromised when FH went down.

There are still so many questions about DPR that have not been answered:

    1. How did they find the SR server/s?

    2. The friendlychemist situation is bizarre. Did friendlychemist really hack someone or were they the vendor looking to make some extra $$$? If they did hack someone, how did they find the vendor? Was the vendor lucydrop who claimed to be hacked around the same time?

    3. Why did he send the IDs directly to his house and why did those IDs have his own photo on them? Did DPR not know that fake IDs with his own picture are about as stupid as you can get on the darkweb?

    4. Why was DPR discussing fake IDs with redandwhite who was related to/could be friendlychemist who just blackmailed him?

    5. How did Border patrol find the fake IDs with a routine search? Seems like the ID vendor was compromised and they knew what to look for or DPR was already being monitored.

    6. The server was imaged in July but SR only kept messages and transactions for two months so how did they see the messages between DPR, friendlyshemist, and redandwhite in March and April?

    7. What information did the employee in the Maryland complaint have that DPR was so worried about? If they were arrested, as DPR believed, and could view all the messages on SR, why would he not think the site was already compromised?

Site Admin
User avatar
Posts: 1184
Joined: 15 Dec 2012, 21:34
Location: in the Higgs ocean...

Silk Road bust - forensics & OpSec analysis

Postby Pattern_Juggled » 03 Oct 2013, 08:33

The above guest poster is, I believe, responding to the news of the Silk Road shutdown and arrest of someone alleged to be DPR. Plus, a tweet sent out by Baneki Privacy Labs pointing out that...
DPR.png

(said information coming from a court document justifying probable cause for arrest - the "complaint" - attached; copy attached to bottom of this post)

There's some excellent questions in this list, and I'm going to see if I can add any value based on what is available currently - i.e. the court documents, mostly, as the reporting all seems to derive merely from the underlying documents themselves.

Guest wrote:Silk Road (SR) wasn't hosted at Freedom Hosting (FH). If it was, Dread Pirate Roberts (DPR) would have had a good belief that the entire site was compromised when FH went down.


Completely agreed - I know of no evidence suggesting SR was on FH or connected to it in technical infrastructure. The Baneki tweet above (which I submitted to Baneki's feed, via the current admin of that account, just to be clear) points out the temporal concurrence here - and nothing more. What does it mean, that these two events were happening within a couple weeks of each other? We don't know yet. We don't know causal links, we don't know if there's "hidden variables" behind the scenes that are themselves causal determinants of the surface-level facts available for review thus far.

We also don't know if those dates are accurate, actually: the FBI agent says that was the date they imaged the SR machine; did they have root on it for months beforehand? Did they have dom0 root on the FH machines for months? We don't know. We know the FBI claims they imaged the machine a mere 9 days before FH went down with the arrest - and, remember, the FBI (or perhaps "FBI" at this point - because, seriously...) admits it had functional root on the FH machines for some time before the Thursday 1 August raid. That's important to keep in mind.

So we have a temporal congruence here, in which the "FBI" claims to have mysteriously gained full root access to the physical machines running Tor hidden services - without being noticed, mind you - in at least one case gaining a full hard drive image of the running machine without triggering any IDS toolsets or other alarms on the machine. It seems highly probable - although not confirmed - that the same was true on FH.

That's quite a coincidence, given that - until July of 2013 - not many folks assumed it was a trivial operation to bust through Tor hidden services and find the underlying machines on which they were hosted. Indeed, lots of smart people were pretty damned sure that was not possible - or, if possible, would require the resources and expertise of seriously heavy-hitting technical adversaries.

Not, need we point out, the FBI.

There are still so many questions about DPR that have not been answered:

    1. How did they find the SR server/s?


Absolutely the big question I see at this point, per comment above. This is the big "hail mary" step, after all. And not only did they locate servers, but they got root (admittedly, that could be done - per Baneki's post above - with the assistance of the datacentre staff, but that's a delicate operation)... and did so unnoticed.

Anyone who thinks this is "easy" is welcome to share their ability to do this - I'll specify a hidden service address, and you tell me what sever it's living on physically. Or, if someone says it's a "backdoor in Tor that the NSA - err 'FBI' is using," then please point to the code block in the current Tor build that includes the backdoor, and provide a walk-through of how it is called once in production.

Because, no, it's not easy.

2. The friendlychemist situation is bizarre. Did friendlychemist really hack someone or were they the vendor looking to make some extra $$$? If they did hack someone, how did they find the vendor? Was the vendor lucydrop who claimed to be hacked around the same time?


What if you have two vendors you are running as honeypots? You have one claim to have "hacked" the other - showing proof of it, to boot. This is designed to piss DPR the fuck off, and chivvy him into doing something rash, like threatening violence.

If you're trying to get to DPR, setting up honeypot vendors - who do deliver good stuff to customers, which the DEA has been doing for decades in undercover ops - is basically a given. To create a scheme in which one "hacks" another and threatens to expose customer details... that's a nice little bit of social engineering.

And then, guess who gets "referred" by FriendlyChemist as the "vendor" owed the money? R&W, which as anyone will likely know, is a not-subtle reference to folks who would NOT use such a name in such a situation. Ever. In a billion, billion years. But one might assume, if one were creating such a sting, that DPR - not being "of that world" - would not know that, and with a bit of Googling would think "oh, wow, I see, yeah that makes sense... now I understand." It's all put there on a plate, ready to be devoured by a hungry man. With hook carefully hidden inside.

Then you have the Canadians saying, "gee we don't have any record of the RL identity of FC, nor of a 'murder' in White Rock, nor of any of this...." because, yeah, it's all fictitious. Why would the U.S. Feds decide to locate their faux "murder" up here in coastal B.C? Cleaner than doing it in the U.S., one supposes. Offshoring the honeypot, as it were. Also far less likely DPR is going to want to do anything real-life to be present, since he'd have to cross an international border and might be paranoid about doing so? Just thinking out loud on that.

What is 100%, totally clear is that R&W is a fake account. Which means, since FC is claiming them as a "supplier" owed money, is by definition a fake account. Which means the "hack" is a setup, either done to another real SR vendor (with that amazing FBI offensive cyberware capability that's just suddenly, astonishingly, appeared out of thin air... no explanation offered; sigh) to feed fuel into the setup, or of another straw man honeypot vendor who has been collecting customer IDs all along.

If you take as axiomatic that R&W is fake - further evidence offered below - then the rest is, I believe, logically inevitable.

3. Why did he send the IDs directly to his house and why did those IDs have his own photo on them? Did DPR not know that fake IDs with his own picture are about as stupid as you can get on the darkweb?


Because he was lulled into a false sense of security by a well-run sting campaign. This, to be clear, is the domain of FBI expertise and I've no doubt they put this part together in-house and pulled it off beautifully.

If DPR buys the bait that R&W is who he will, inevitably, think it is - I'm not spelling it out, and please don't do so in this thread - the he's likely to let his guard down. This was not a "SR vendor" we're talking about here... not at all. Based on that reputation, and on the "hit" he's just successfully executed with them - he never hears from (the nonexistent, sham vendor) FriendlyChemist again, and concludes the hit must have been successful - he's going to be far more likely to trust in this deal.

So he decides to go for it, and get some "real" IDs with his photo, for use in serious circumstances. If you're gonna get those docs and trust they'll be done right, that's who'd you trust. Or so I hear.

The mailing address is a bit bizarre; I've no explanation for that. Just really lulled into security?

The cover story of the border agents "randomly" opening the package and finding the IDs is, screamingly obviously so, Parallel Construction in the wild: thar she blows! There was nothing random about it, and DPR was (rightly) convinced the chances of a "random" search of a standard postal envelope going across that border - sent by who he thought was sending it, with their reputation and competence - were statistically close to zero.

He was right. But that wasn't who he thought it was, and the whole ID thing was a setup. Once he asked about getting IDs from R&W, he was done.

Indeed, looking back, could the ID setup have been the start? With that, they have his RL name and identity... and with that, they start tracing the threads back to servers. They find a server, they send in TAO... err "those amazing FBI offensive cyberspercialists that nobody has ever heard of but who magically appeared this summer during the NSA's Snowden battles - root it, and sit there waiting to gather enough data to hang him and take the whole site down.

4. Why was DPR discussing fake IDs with redandwhite who was related to/could be friendlychemist who just blackmailed him?


Because he assumed he knew who was behind that screen name. And he assumed he'd just successfully ordered a "hit" through them, thus having proved their legitimacy and competence.

Further, nobody would use that alias falsely - nobody with half a fucking brain. So, to someone inexperienced, that gives it a whiff of authenticity. It'd be like walking into a boxing gym and claiming to be Mike Tyson, or something - you are not going to like the results of falsely "fronting" that name.

5. How did Border patrol find the fake IDs with a routine search? Seems like the ID vendor was compromised and they knew what to look for or DPR was already being monitored.


Per above, ID vendor was a setup from Day One - as was the "hit." As was the "hack." By logical extrapolation from known data points.

6. The server was imaged in July but SR only kept messages and transactions for two months so how did they see the messages between DPR, friendlyshemist, and redandwhite in March and April?


Because they rooted it earlier? After getting RL identification of DPR, via the fake "hit" and resulting "ID buy," in April. Once they rooted it, they'd have a back-facing window of 60 days' messages... thus enabling them to pull the PMs of the entire hit-for-hire shenanigan from the SR side, as well.

7. What information did the employee in the Maryland complaint have that DPR was so worried about? If they were arrested, as DPR believed, and could view all the messages on SR, why would he not think the site was already compromised?


I haven't read that complaint, yet - been poring line-by-line through the attached New York complaint:

UlbrichtCriminalComplaint.pdf
(3.27 MiB) Downloaded 229 times

Torass

Re: Silk Road bust - forensics & OpSec analysis

Postby Torass » 03 Oct 2013, 11:59

I just want to clarify one thing - in Canada it is perfectly reasonable for your mail to be randomly opened and inspected. I order online all the time, and I have had at least 2 or 3 packages opened and inspected by the RCMP. They repackage and write a certified letter inside advising you of what they have done. I usually just buy stuff for my horse, so no big deal.

Guest

Re: Silk Road bust - forensics & OpSec analysis

Postby Guest » 03 Oct 2013, 12:07

Pattern_Juggled wrote:The above guest poster is, I believe, responding to the news of the Silk Road shutdown and arrest of someone alleged to be DPR. Plus, a tweet sent out by Baneki Privacy Labs pointing out that...
DPR.png

(said information coming from a court document justifying probable cause for arrest - the "complaint" - attached; copy attached to bottom of this post)

There's some excellent questions in this list, and I'm going to see if I can add any value based on what is available currently - i.e. the court documents, mostly, as the reporting all seems to derive merely from the underlying documents themselves.


Thank you. Appreciate you taking the time to provide such a detailed reply. I'll try and reference my comments for you where possible to make it easier to follow.

Pattern_Juggled wrote:
Guest wrote:Silk Road (SR) wasn't hosted at Freedom Hosting (FH). If it was, Dread Pirate Roberts (DPR) would have had a good belief that the entire site was compromised when FH went down.


Completely agreed - I know of no evidence suggesting SR was on FH or connected to it in technical infrastructure. The Baneki tweet above (which I submitted to Baneki's feed, via the current admin of that account, just to be clear) points out the temporal concurrence here - and nothing more. What does it mean, that these two events were happening within a couple weeks of each other? We don't know yet. We don't know causal links, we don't know if there's "hidden variables" behind the scenes that are themselves causal determinants of the surface-level facts available for review thus far.

We also don't know if those dates are accurate, actually: the FBI agent says that was the date they imaged the SR machine; did they have root on it for months beforehand? Did they have dom0 root on the FH machines for months? We don't know. We know the FBI claims they imaged the machine a mere 9 days before FH went down with the arrest - and, remember, the FBI (or perhaps "FBI" at this point - because, seriously...) admits it had functional root on the FH machines for some time before the Thursday 1 August raid. That's important to keep in mind.

So we have a temporal congruence here, in which the "FBI" claims to have mysteriously gained full root access to the physical machines running Tor hidden services - without being noticed, mind you - in at least one case gaining a full hard drive image of the running machine without triggering any IDS toolsets or other alarms on the machine. It seems highly probable - although not confirmed - that the same was true on FH.

That's quite a coincidence, given that - until July of 2013 - not many folks assumed it was a trivial operation to bust through Tor hidden services and find the underlying machines on which they were hosted. Indeed, lots of smart people were pretty damned sure that was not possible - or, if possible, would require the resources and expertise of seriously heavy-hitting technical adversaries.

Not, need we point out, the FBI.


I'm glad that we both see the logic in SR not being hosted by FH. You are absolutely right however that the timing is suspicious. According to the Maryand complaint (MC), administrator's on the site "had the ability to see messages Silk Road users sent to each other, to see the details of each transaction on Silk Road, and to see the accounts - including financial information - of Silk Road users, including account of DPR" [MC, P7]. On January 15th, delivery was made by the police to the vendor/employee/adminstrator (VEA) on SR [MC, 10g] so it is fair to think that the site was compromised on that date and all information on it viewable by the police for at least 11 days until DPR communicates that the VEA was arrested.

So the question is, how easy would it have been to get root on the server with an administrator's account? Considering that SR was coded by DPR himself and that only a few months before this DPR had commented that he was a debian newbie [altoid, bitcointalk, 25/02/2011], I would say very easy, why break Tor when you can break PHP? So the question is, why image the machine in July just before the FH bust and I think that they may have been worried that DPR would take the site down after FH was busted and wanted to get an image in case that happened. The image would provide more details than they already had but taking it would also be risky for the reasons you mention above.

Pattern_Juggled wrote:
There are still so many questions about DPR that have not been answered:

    1. How did they find the SR server/s?


Absolutely the big question I see at this point, per comment above. This is the big "hail mary" step, after all. And not only did they locate servers, but they got root (admittedly, that could be done - per Baneki's post above - with the assistance of the datacentre staff, but that's a delicate operation)... and did so unnoticed.

Anyone who thinks this is "easy" is welcome to share their ability to do this - I'll specify a hidden service address, and you tell me what sever it's living on physically. Or, if someone says it's a "backdoor in Tor that the NSA - err 'FBI' is using," then please point to the code block in the current Tor build that includes the backdoor, and provide a walk-through of how it is called once in production.

Because, no, it's not easy.


Following from my response above, if they didn't use the administrator's access then there was another interesting point made in the New York complaint (NYC). On May 24th, 2013, a user sent DPR a message that an external IP was leaking and that the address turned out to be the VPN server that DPR was using [NYC, page 28, footnote 4]. Also of note is that DPR was accessing that VPN server directly from a cafe near where he was potentially living [NYC, 41c]. You know a lot more about this than me, but what would cause this or why would this even happen, shouldn't the SR server just accept incoming connections not start new outgoing connection?
I understand if DPR configured the server so that only someone at the VPN could login via SSH but to have the IP of the VPN server leak? Would leaking the IP benefit the FBI at all if DPR was accessing the SR server from the VPN?

To answer your challenge, how difficult would it be if someone pwned the web server somehow? That is add a caveat to your challenge, you tell me the hidden service and give me administrator access and see how easy it is to find the IP.

Pattern_Juggled wrote:
2. The friendlychemist situation is bizarre. Did friendlychemist really hack someone or were they the vendor looking to make some extra $$$? If they did hack someone, how did they find the vendor? Was the vendor lucydrop who claimed to be hacked around the same time?


What if you have two vendors you are running as honeypots? You have one claim to have "hacked" the other - showing proof of it, to boot. This is designed to piss DPR the fuck off, and chivvy him into doing something rash, like threatening violence.

If you're trying to get to DPR, setting up honeypot vendors - who do deliver good stuff to customers, which the DEA has been doing for decades in undercover ops - is basically a given. To create a scheme in which one "hacks" another and threatens to expose customer details... that's a nice little bit of social engineering.

And then, guess who gets "referred" by FriendlyChemist as the "vendor" owed the money? R&W, which as anyone will likely know, is a not-subtle reference to folks who would NOT use such a name in such a situation. Ever. In a billion, billion years. But one might assume, if one were creating such a sting, that DPR - not being "of that world" - would not know that, and with a bit of Googling would think "oh, wow, I see, yeah that makes sense... now I understand." It's all put there on a plate, ready to be devoured by a hungry man. With hook carefully hidden inside.

Then you have the Canadians saying, "gee we don't have any record of the RL identity of FC, nor of a 'murder' in White Rock, nor of any of this...." because, yeah, it's all fictitious. Why would the U.S. Feds decide to locate their faux "murder" up here in coastal B.C? Cleaner than doing it in the U.S., one supposes. Offshoring the honeypot, as it were. Also far less likely DPR is going to want to do anything real-life to be present, since he'd have to cross an international border and might be paranoid about doing so? Just thinking out loud on that.

What is 100%, totally clear is that R&W is a fake account. Which means, since FC is claiming them as a "supplier" owed money, is by definition a fake account. Which means the "hack" is a setup, either done to another real SR vendor (with that amazing FBI offensive cyberware capability that's just suddenly, astonishingly, appeared out of thin air... no explanation offered; sigh) to feed fuel into the setup, or of another straw man honeypot vendor who has been collecting customer IDs all along.

If you take as axiomatic that R&W is fake - further evidence offered below - then the rest is, I believe, logically inevitable.


I understand your theory but to me it seems convoluted. I would instead try and apply occam's razor and look for something simpler? SR was littered with scammers. One of the easiest scams was to sell a bunch of drugs, get a good reputation, and then ask for everyone to finalize early and do the runner. Tony76, Enter the matrix and countless others. I always imagined an evolution of that scam would be to record all the addresses and then when you wanted to leave SR, threaten people with the information. There was one vendor who even went so far as to release information under the handle infowars.

The entire friendlychemist (FC) scenario seems more like an elaborate exit scam to me more than anything else and friendlychemist and redandwhite was, in reality, just the vendor. Maybe as soon as FC realized DPR would actually hire a hitman to get rid of them, what better way to get out of that situation than take money to pretend to kill yourself?

If you look at both the NYC and MD complaints, the level of detail regarding the murder for hire plots are completely differently making me believe that FC and redandwhite weren't police and instead external.

Admittedly, I have no idea who redandwhite is though? Whatever you can add I would appreciate. It makes no sense however, if redandwhite were owed 500k by FC, why would they accept 150k to kill him and not get the 350k difference?

Pattern_Juggled wrote:
3. Why did he send the IDs directly to his house and why did those IDs have his own photo on them? Did DPR not know that fake IDs with his own picture are about as stupid as you can get on the darkweb?


Because he was lulled into a false sense of security by a well-run sting campaign. This, to be clear, is the domain of FBI expertise and I've no doubt they put this part together in-house and pulled it off beautifully.

If DPR buys the bait that R&W is who he will, inevitably, think it is - I'm not spelling it out, and please don't do so in this thread - the he's likely to let his guard down. This was not a "SR vendor" we're talking about here... not at all. Based on that reputation, and on the "hit" he's just successfully executed with them - he never hears from (the nonexistent, sham vendor) FriendlyChemist again, and concludes the hit must have been successful - he's going to be far more likely to trust in this deal.

So he decides to go for it, and get some "real" IDs with his photo, for use in serious circumstances. If you're gonna get those docs and trust they'll be done right, that's who'd you trust. Or so I hear.

The mailing address is a bit bizarre; I've no explanation for that. Just really lulled into security?

The cover story of the border agents "randomly" opening the package and finding the IDs is, screamingly obviously so, Parallel Construction in the wild: thar she blows! There was nothing random about it, and DPR was (rightly) convinced the chances of a "random" search of a standard postal envelope going across that border - sent by who he thought was sending it, with their reputation and competence - were statistically close to zero.

He was right. But that wasn't who he thought it was, and the whole ID thing was a setup. Once he asked about getting IDs from R&W, he was done.

Indeed, looking back, could the ID setup have been the start? With that, they have his RL name and identity... and with that, they start tracing the threads back to servers. They find a server, they send in TAO... err "those amazing FBI offensive cyberspercialists that nobody has ever heard of but who magically appeared this summer during the NSA's Snowden battles - root it, and sit there waiting to gather enough data to hang him and take the whole site down.


I don't think there was any direct evidence the IDs came from redandwhite, just that they came from Canada [NYC, p42a]. The complaint mentions that DPR talks to a user about needing a fake ID and that he also talked to redandwhite about it [NYC, 42b]. I'm not sure why DPR would give himself and his picture to someone who probably just blackmailed him two or three months earlier. It seems like something you would want to compartmentalise as a totally separate person so that you wouldn't give away you are DPR. It's one thing to sell drugs online, it is another thing entirely to get into the forgeries game. That usually draws a lot more attention because it could potentially be a precursor to something way more serious than getting high. It's why the feds were so interested in the guy selling forgeries at carder's market and turned him into an informant.

I agree with you entirely though on the border patrol. That entire paragraph is laughable. It's the exact reason why you can't have people being allowed to do random searches of anything because it just becomes a tool for the authorities to cover their more nefarious actions. If they are going to do random searches they should be derived from a random number generator not "intuition"

As for the ID begin a start, possibly. It just doesn't strike me as the most probable sequence of events.

Pattern_Juggled wrote:
4. Why was DPR discussing fake IDs with redandwhite who was related to/could be friendlychemist who just blackmailed him?


Because he assumed he knew who was behind that screen name. And he assumed he'd just successfully ordered a "hit" through them, thus having proved their legitimacy and competence.

Further, nobody would use that alias falsely - nobody with half a fucking brain. So, to someone inexperienced, that gives it a whiff of authenticity. It'd be like walking into a boxing gym and claiming to be Mike Tyson, or something - you are not going to like the results of falsely "fronting" that name.


Again, I just don't know enough about this side of the underweb/world to comment on this. I have no idea who redandwhite is.

Pattern_Juggled wrote:
5. How did Border patrol find the fake IDs with a routine search? Seems like the ID vendor was compromised and they knew what to look for or DPR was already being monitored.


Per above, ID vendor was a setup from Day One - as was the "hit." As was the "hack." By logical extrapolation from known data points.


Maybe. I'm more inclined to believe the server was already hacked and they just followed his messages. They picked up on the ID purchase and once they had that they knew he who was and that was the beginning of the end.

Pattern_Juggled wrote:
6. The server was imaged in July but SR only kept messages and transactions for two months so how did they see the messages between DPR, friendlyshemist, and redandwhite in March and April?


Because they rooted it earlier? After getting RL identification of DPR, via the fake "hit" and resulting "ID buy," in April. Once they rooted it, they'd have a back-facing window of 60 days' messages... thus enabling them to pull the PMs of the entire hit-for-hire shenanigan from the SR side, as well.


After reading the MD complaint, I'm inclined to believe that the server may have already been pwned and they had been monitoring his messages since then. They have his messages in March between FC/redandwhite but nothing before January when the VEA was arrested.

Pattern_Juggled wrote:
7. What information did the employee in the Maryland complaint have that DPR was so worried about? If they were arrested, as DPR believed, and could view all the messages on SR, why would he not think the site was already compromised?


I haven't read that complaint, yet - been poring line-by-line through the attached New York complaint:


Interested in hearing your thoughts after you read it.

Pattern_Juggled wrote:
UlbrichtCriminalComplaint.pdf


One extra question I didn't have originally was that DPR said in his interview with Andy greenberg
http://www.forbes.com/sites/andygreenberg/2013/08/14/meet-the-dread-pirate-roberts-the-man-behind-booming-black-market-drug-website-silk-road/
that the ownership changed after someone pointed out a flaw in the setup that gave up the server. I wonder if that was the May VPN bug that is referenced in the NYC complaint. It seems that all the information that is in the complaints is before the supposed transfer of the site was made in August.



Guest

Re: R&W

Postby Guest » 03 Oct 2013, 13:15

Pattern_Juggled wrote:Note colour scheme...

http://gangstersout.blogspot.ca/2011/08 ... house.html


What is their presence like in White Rock? I see the colours but is there anything that actually links "redandwhite" to the club?

Site Admin
User avatar
Posts: 1184
Joined: 15 Dec 2012, 21:34
Location: in the Higgs ocean...

Re: R&W

Postby Pattern_Juggled » 03 Oct 2013, 13:34

Guest wrote:What is their presence like in White Rock? I see the colours but is there anything that actually links "redandwhite" to the club?


To be clear, I see this unquestionably as a "front" - R&W isn't actually a real "R&W," but rather an LEO creation: an image they wanted to sell to DPR of the ultimate "connect."

Quite clearly and without any misunderstanding, I neither speak for nor speak of the activities of the Club. Not now, not ever.

Rather, I see LEO trading on the reputation to generate a honeypot "source" and hitman-connect (and identity papers connect)... reeling in DPR via this persona they created. And, frankly, only LEO could get away with a "front" like that - anyone else would be having a very bad day/life.

There was no murder, there was no "FriendlyChemist" - all LEO creations. All staged to entrap DPR in a murder-for-hire scheme, and nail his identity with the offer of ID papers delivered to him by a source that - if you're in that kind of world - is sort of the ultimate trusted entity. Getting ID papers from them is... well, bee's knees.

Again, it's a front: LEO. There's no R&W in any of this that I see as an outside analyst. Their name was just used as bait - tricky, clever, underhanded... and terribly successful.

(White Rock is covered by Haney, afaik...)

Guest

Re: Silk Road bust - forensics & OpSec analysis

Postby Guest » 03 Oct 2013, 13:42

As an aside, the SR takedown reminds me of the oink.me.uk takedown. Oink was an amazing source of information about music. Had it been harnessed correctly by the labels it would be worth a billion dollars today. SR is the same.

Oink.me.uk -> what.cd & waffles.fm
SR -> ?? & ??

I imagine the next young libertarian entrepreneur to come along won't make the same mistakes.

clownshoes19

Re: Silk Road bust - forensics & OpSec analysis

Postby clownshoes19 » 03 Oct 2013, 21:57

That article 'Locating Hidden Servers' is dated, but interesting.

I imagine that counter measures have been deployed since that was published, but I lack the time needed to research it further. I would suggest looking at the project's release notes or bug tracker.

I wonder if the recent JavaScript exploit in Firefox (and subsequently the Tor bundle) has once again made it possible to do a timing based attack like they described in the publication.

Site Admin
User avatar
Posts: 1184
Joined: 15 Dec 2012, 21:34
Location: in the Higgs ocean...

Tor papers - separate thread

Postby Pattern_Juggled » 04 Oct 2013, 14:10

clownshoes19 wrote:That article 'Locating Hidden Servers' is dated, but interesting.


To keep things easier to access, I've moved the research paper cited above over to a new thread collecting Tor vuln papers. This isn't some coded reference to hint that "the Tors are broken!!" or anything of the sort. Rather, the healthy production of research results on Tor-related issues reflects a darknet technology both widely used, and of substantive technical design.

In other words, nobody writes research papers of this level of professionalism about useless tech.

For any complex system, the path to robust security involves peer-review, extensive testing, and open dialogue/debate. This is healthy: a feature, not a bug.

Site Admin
User avatar
Posts: 1184
Joined: 15 Dec 2012, 21:34
Location: in the Higgs ocean...

What's different?

Postby Pattern_Juggled » 04 Oct 2013, 14:32

A fair question to ask about this latest attack on Tor protection is: why does it matter?

It matters because it's different.

These kinds of attacks - machines getting rooted secretly, using unknown techniques or, as in the case of torsploit, zero-day vulns deployed against big chunks of global targets - are new. This is the kind of stuff we expect to see being done by organized crime syndicates, black hat collectives... that sort of thing.

Or, obviously, the NSA.

A point that was made repeatedly during the torsploit forensic analysis in August and, more recently, the (highly limited and likely parallel-constructed) disclosures regarding the FH takedown - "torsploit reloaded" - is that there's no historical precedent for the FBI, alone and unaided, engaging in this kind of attack. At all. If there's such examples, I have never seen them - and I'd certainly hope folks can point to them if they know of such examples.

As one amoungst many examples, here's one from 2008: the FBI, in combination with LE organizations worldwide, engaged in a massive effort to hunt down visitors to a site-linking forum (described in the article as "child porn," but it appears there's some considerable definitional issues that remain ambiguous). This was a years-long effort, somewhere close to unprecedented.

And here's how they imaged the server HDs:

In February 2008, seven months after gaining access to their informant’s Cache account, US postal inspectors obtained a warrant to seize the thecachebbs.com server from North Carolina hosting company Caro.net.

Caro pulled the machine offline and turned the hard drive inside over to postal inspectors, who passed it on to the Department of Justice’s (DOJ) Child Exploitation and Obscenity Section (CEOS) in Washington, DC. James Fottrell served as head of the High Technology Investigative Unit at CEOS, and he used the main database found on the hard drive to rebuild The Cache locally in his office, creating a private, forensically sound version of the site that looked just as it would have to the site’s users. When infiltrating the board, Arney had been merely a regular user with a regular user’s limitations; now Fottrell had complete run of the site.

A few weeks later, Fottrell took his copy of The Cache out to the Immigration and Customs Enforcement (ICE) Cybercrimes Center in Fairfax, Virginia, to get more space. He set up shop in a training room with 24 computers. For a week, federal, state, and local agents sat at those computers and probed this locally re-created Cache, following its links, downloading evidence, preserving it for prosecution. The team eventually assembled investigative lead packets on every member of the site, packets that included usernames, profile information, and the Internet Protocol (IP) addresses of every machine used to access The Cache.


(Boldface added)

Now, that was 2008 and in the years between it's possible the FBI developed some technique for imaging live HDs on dedicated machines - without rooting them - but I've not seen yet any pointers to tools in the "civilian" world (or references to the FBI using such tools) elsewhere. There's people who can do that sort of thing, obviously - TAO, serious black hats, Vupen-supplied 0days, that sort of thing - but there's no known precedent of the FBI making use of them in criminal cases.

Hence, this is... interesting.

Guest

Re: Silk Road bust - forensics & OpSec analysis

Postby Guest » 04 Oct 2013, 16:14

vmware converter is capable of cloning any powered on physical system's disks into a virtual machine, without downtime, and by installing a small agent in the host, which won't trigger any malware alarms. It does require root/admin access, which isn't hard to grab if you're logged through a remote KVM that can be bugged with a USB keylogger.

The converter is free. Grab it and test it from vmware's website. You can power on the vm with vmware player, another free software.

I hate your inhumane captchas! And the audio sounds like a zombie that had eaten a full unpeeled pineapple!

Site Admin
User avatar
Posts: 1184
Joined: 15 Dec 2012, 21:34
Location: in the Higgs ocean...

Re: Silk Road bust - forensics & OpSec analysis

Postby Pattern_Juggled » 04 Oct 2013, 16:25

Guest wrote:vmware converter is capable of cloning any powered on physical system's disks into a virtual machine, without downtime, and by installing a small agent in the host, which won't trigger any malware alarms. It does require root/admin access, which isn't hard to grab if you're logged through a remote KVM that can be bugged with a USB keylogger.

The converter is free. Grab it and test it from vmware's website. You can power on the vm with vmware player, another free software.


Thanks for the pointer; I'll take a look at it. It does, however, require root - admittedly not impossible to gain (as you say) via sniffing a KVM session (which assumes KVM is wired onto the box and the remote admin enters FDE passphrase via that channel). Further, it requires nobody notice that root was gained - which, for any competent sysadmin, will require erasing logfiles to ensure there's not breadcrumbs left behind. It also requires that no IDS components be triggered during the process - which is a different issue than anti-malware scans. And it requires that the admin not notice a new process running on the machine - or it requires an obfuscated process.

(unless the assumption is that the machine is already sitting on a VMware - or other? - hypervisor... which may or may not be true, right?)

I hate your inhumane captchas! And the audio sounds like a zombie that had eaten a full unpeeled pineapple!


Frankly, we hate them too. They suck. All the old ones have been broken by the spambots; it's a constant cat and mouse game with them.

Do you have suggestions on better ones? We're really, really keen to find CAPTCHAS that aren't awful - but will allow us to keep guest posting without our forum admin staff being buried by tsunamis of junk spambot posts.

Thanks for being blunt about the sucky CAPTCHAS - it helps us prioritise the issue, too.

Guest

Re: Silk Road bust - forensics & OpSec analysis

Postby Guest » 05 Oct 2013, 06:58

Pattern_Juggled wrote:Thanks for the pointer; I'll take a look at it. It does, however, require root - admittedly not impossible to gain (as you say) via sniffing a KVM session (which assumes KVM is wired onto the box and the remote admin enters FDE passphrase via that channel). Further, it requires nobody notice that root was gained - which, for any competent sysadmin, will require erasing logfiles to ensure there's not breadcrumbs left behind. It also requires that no IDS components be triggered during the process - which is a different issue than anti-malware scans. And it requires that the admin not notice a new process running on the machine - or it requires an obfuscated process.

(unless the assumption is that the machine is already sitting on a VMware - or other? - hypervisor... which may or may not be true, right?)

Frankly, we hate them too. They suck. All the old ones have been broken by the spambots; it's a constant cat and mouse game with them.

Do you have suggestions on better ones? We're really, really keen to find CAPTCHAS that aren't awful - but will allow us to keep guest posting without our forum admin staff being buried by tsunamis of junk spambot posts.

Thanks for being blunt about the sucky CAPTCHAS - it helps us prioritise the issue, too.


I think you're giving DPR a lot more credit than he deserves. Looking at his early posts on how to deploy Bitcoind on Debian, then failing and switching to Ubuntu. After that, he shows some horrible skills at PHP, and not knowing when to enclose variables with double quotes, hint at how many fields SR must have had that were not sanitized before processing user inputs.

You can see these posts here: http://grugq.tumblr.com/post/62919678278/osint-case-study-ross-ulbricht-aka-dread-pirate

From the indictment documents, it's clear that the employee who was captured provided access to the internal admin panel, which could've had SQLi exploits, giving the feds access to the history, and probably allow them to plant a root shell, too.

Even if that didn't happen. It's fairly easy to fake a disk failure in the datacenter (plug out a disk!), and then requesting the admin to take down the server for maintenance, and there were cases where SR was taken down for maintenance (not sure if software or hardware).

I dealt with data recovery companies who can restore data from RAID arrays (LSI, for example), so taking out the disks, plugging them into another exact server, then cloning the disks, isn't hard. The very least they can do is to plant a USB keylogger on the KVM during this downtime, and cause some sort of communication problem on Ethernet to force him to use the KVM.

There was no indication that the machine was on a hypervisor, and I doubt it was. He probably rented bare metal boxes, and I highly doubt any IDS/IPS was involved anywhere.

From the documents, his setup was: a bunch of boxes scattered in a few countries, all served by 1 front end system, used as a reverse proxy, and that front end box contained the publicly known onion hidden service.

As for the capcthas, I don't know of a sane alternative, but I did notice that when using a direct connection rather than being behind Tor, I'm served a tad bit better images. The ones served when behind Tor were brutal...

Guest

Re: Silk Road bust - forensics & OpSec analysis

Postby Guest » 06 Oct 2013, 18:37

Here are a few suggestions for improving OpSec for remotely-hosted servers with full-disk encryption, in light of the recent busts:

(1) Assuming the remote server runs on bare metal, run an operating system protected against cold boot attacks. For example, Linux with TRESOR:

http://www1.informatik.uni-erlangen.de/tresor

Note that the solution would still remain vulnerable if running on a virtual machine. Malignant hosting provider could pretend to be providing bare metal servers, which in reality would be virtualized. I think there're timing or other side-channel attacks to detect whether you're running natively or under virtualization, with good degree of probability.

(2) Once you got remote server configured and running, don't reboot it. Ever. You'd go about setting up a new remote server as follows:

(a) Initialize the new machine by installing OS and software, or, more likely, by replicating image of an existing, already up-and-running server from your cluster.
(b) Boot up new machine for production service. Enter FDE passphrase via KVM.
(c) If a reboot occurs or becomes necessary:

(i) Not initiated by you. Stop paying for this host, and don't ever use this hosting provider again. Perhaps wipe the server as a good-bye gesture, by booting it into some recovery shell without entering the FDE passphase.
(ii) Explicitly initiated by you. Use your judgement. Personally I would still wipe and abandon the host.

I realize that these measures may seem a bit excessive. So color me paranoid :-) There's always been reverse correlation between security and convenience, and in this day and age hosting solutions are so commoditized, that I think you'd be able to follow this policy without much hassle. Especially considering the stakes.

Some of the attack vectors would be:

(3) Intercepting FDE passphrase over KVM during small window of opportunity when the box will be initially set up.
(4) Dumping all RAM contents of the server, while it's running in production. You should lease a host with only just enough RAM to provide reasonable performance. Let it grind the disk, and don't let it cache all the application data from the past week. Gosh, trying to do secure computing on untrusted hardware is tough.

Return to netsecurity fails: cipher crashes, DNS leaks, Tor vulns, &c.



Who is online

Users browsing this forum: No registered users and 4 guests