26 Mar 2013: http://www.reddit.com/r/SilkRoad/comments/1b1lvy/warning_the...
26 Mar 2013: http://www.reddit.com/r/Bitcoin/comments/1b1n7y/warning_to_s...
03 May 2013: http://www.reddit.com/r/SilkRoad/comments/1dmznd/should_we_b...
Maybe we'd have fewer incidents like these if keyboard jockeys were a bit more teachable. Even super 1337 h4xx0r5 make mistakes, often obvious ones. Software is complicated. Let this be a lesson to any of us who may dismiss a correction too quickly.
> you would have to go out of your way to expose
> your public IP via Tor.
> However, the hidden service you connect to,
> would be the load balancer. This service would
> have zero knowledge of its "external" ip
> address, as it would be running in a VM
> pointing to a port on the loopback device.
> - Server is almost 100% certainly running in a
> VM and doesn't have a public IP.
> - The entire harddrive for the server (which
> includes all the the information such as
> private messages and addresses) is almost 100%
> This is the motherfucking SilkRoad. They've
> been operating so successfully for so long
> because they're not amateurs. OP is a liar.
it's interesting that these people, who have no idea what an ip or load balancer or VM is, were able to pick up on this. i would guess that the h4xx0r5 actually spent little time using the service or had the bit of their own necks being exposed taint their assessment.
* yeah, i know no one really knows exactly what happened, but it's fun to poke fun.
'SERVER_NAME' The name of the server host under which the current script is executing. If the script is running on a virtual host, this will be the value defined for that virtual host.
'HTTP_HOST' Contents of the Host: header from the current request, if there is one.
2.) Even if the script is running in a vhost, if a listening port is specified but not an IP address the SERVER_NAME will be the IP of whatever the interface the http connection came from was.
HTTP servers, caching proxies, TLS terminators and load balancers have a habit of putting extra HTTP headers in the HTTP response to make the path of a request more clear. It's very possible that under some error condition one of them included an X-FORWARDED-FOR header or something similar that included the IP. This is all application layer data and can contain IPs.
Even ignoring headers, they could have triggered an error page that just dumps all PHP server variables, one of which includes local IP addresses.
Edit: It's infuriating that this article author doesn't understand that a packet sniffer can see contents of the HTTP protocol.
No, he does not. He says that there's no way a public IP would show up at layers 3 or 4 of the OSI model. The author takes the position that the IP leak must have come from layer 7 (quoting from the article):
[...] and it is at the application layer that the FBI uncovered the IP address.
Depending on how one interprets the FBI's wording, this impossibility contradicts their accounting of how they discovered the IP. Let's look at what the FBI said:
Upon examining the individual packets of data being sent back from the website,3 [sic] we noticed that the headers of some of the packets reflected a certain IP address not associated with any known Tor node as the source of the packets.
Note that they're talking about headers of the packets, not HTTP headers. This is the FBI, though, so it's possible they confused "packets" with "HTTP requests". Taking their words at face value, though, the FBI seem to say that they got the IP address from the IP headers on packets received from Silk Road, or at least traffic generated by their browser on behalf of Silk Road. That's what the author argues is impossible.
Nobody, least of all the author, disputes that Silk Road could have leaked its IP in HTTP headers, or via some other misconfiguration. But if they did, why didn't the FBI just say that? Why claim that they leaked it in the IP layer?
Two possibilities come to mind. The first is that the FBI got the IP from the application layer, as everyone believes is possible, and misattributed the leak to the IP layer due to terminology confusion. The second is that they got the IP from another source, attempted to deceptively misattribute the source, and accidentally picked a fake source the leak could not have come from. If the second option is the case, we're looking at an example of parallel construction.
Edit: Grammar. Gotta keep up appearances.
HTTP headers are in the packets, and I could see myself very very very easily writing "of the packets" in lieu of "in the packets". When proofreading, I'd be much more likely to catch the extra "3" in that same sentence, than to catch the s/in/of/ as introducing confusion.
I've done basic switch configuration, looked at packets, had to troubleshoot MTU and MRU misconfiguration in commercial switches, etc.
Conceptually stuff at that layer is a long ways from the actual content.
It's like pointing to a guy walking his dog at the park after noticing a parked car with it's lights on, and saying "there's the owner in the car" vs "there's the owner of the car".
It feels, to me, like those sorts of linguistic mistakes must be exceedingly rare?
Or maybe the person writing up the statement wasn't the person who generated the notes and they just had a transcription error. I'd buy that I guess.
So here's a bit of nuance for me. I can parse "the headers of the packets" in one of two ways:
1) For each packet, the header of said packet (clearly referring to the IP layer header)
2) For each packet, the headers of said packet (ambiguous)
"The header of a packet" is relatively unambiguous, and akin to your analogy. I would grant this kind of mistake to be rare, although I'm not sure we'd agree on how rare. Certainly not impossibly rare - more common than those spurious 3s in my own writing, and yet we see one of those quite clearly.
"The headers of a packet" is more ambiguous. A packet has only one header. The header has options, so that could be what's being referred to. Or it could be more loosely referring to metadata, or headers of another protocol contained within the packet data.
I could see myself using this kind of loose terminology quite easily. I'm not a network engineer, I don't do switch configuration, I don't have to get down and dirty with IP layer issues with MTU and MRU misconfigurations, so it's quite possible I'm more prone to this kind of mistake than you are.
I'm just a programmer who's occasionally asked to dabble with layer 7 networking stuff, and mostly interact with this when I e.g. fire up Wireshark to debug why my Amazon S3 authentication isn't working, only to discover Unity's WWW class ignored the (HTTP) headers I wanted to send on iOS (explaining why it worked perfectly fine on Windows!)
My gut reaction is that if I, as a civilian, were to ask an FBI agent for details about a case, I'm as likely to receive half-truths and lies by omission as anything at all though. So if you want to be pedantic I guess so.
I did point out that I'd believe it could just be a transcription error by someone unfamiliar with the subject matter though.
Your gut reaction seems to place you in the camp of the conspiracy theorists. That should raise alarm bells for you.
You say that like it's fact. But you're assuming.
I thought it was noteworthy that I can't recall ever seeing that specific error in the wild. Maybe I just missed it. Maybe it's a lot more common than I imagine. Maybe not. I don't know. Once it was brought to my attention I thought it was noteworthy though.
I'm not pretending anything. I gave an additional explanation I felt might be plausible. I'm sure there are others. I just doubt the plausibility of the one brought forward.
> irrational fear
Tomato tomato. There's no evidence it was a writing mistake, but you're presenting it as fact.
I guess it all boils down to this: Given domestic spying revelations I think you're extremely naive if you think it's irrational to think that the FBI might be telling less than the whole truth.
Your gut reaction puts you in the camp of people who would volunteer information to a LEO. Which I think should raise a lot more alarm bells than me shrugging my shoulders and suggesting I'd need actual evidence before taking the FBI at it's word.
The very idea that you would is blissfully naive IMO. But good luck with that.
And if you have an point to make, a little less ad-hom and snark (aka Reddittude) would be appreciated. My original comment was a few wonderings-out-loud, including posing a couple questions for discussion. Nothing in there intended to be snarky. If you want to discuss further, it would be nice if you could approach the conversation with the same level of basic respect.
This isn't really about you, it's about showing the other folks reading this how nuts you are, and luckily you're doing that for me.
As far as "how nuts your are". You seem to be taking this way too seriously.
"My gut reaction is to be skeptical" somehow equates to, in your words:
* Conspiracy Theorist
If that's all it takes to be a conspiracy theorist in your book, well sign me up I guess.
The outright dismissal that it might just be possible you don't have all the facts (and I'm certainly not claiming I do)... That's an idea you dismiss outright. I have to wonder how you get there. Because if anything here seems irrational, that's what I'd put my finger on. But maybe that's just me.
I can understand why they wouldn't want to give more details than they have to; it makes the prosecution's work harder. But I and many others have been arguing for years that there's nothing illegal about sending messages to a server and looking at the responses, if you aren't trying to damage anything. I can't see any reason why it would be less legal for the FBI to do it.
That line of reasoning sounds a lot like the Andre 'Weev' Auernheimer case , where he gathered AT&T customers' email addresses by interacting with a server simply by 'sending it HTTP requests.' The FBI made its position clear on that case, prosecuting Weev for "conspiracy to gain unauthorized access to computers" and ultimately getting the guy sentenced to three years in prison.
The overarching circumstances are clearly different but undeniably parallel. It seems curious to me that the FBI could use these some sort of apparently 'criminal' tactics (by their own precedent) as legal grounds in their case against DPR.
Why? Because it could EITHER be totally-legal or blatantly-illegal, depending on the time, place, manner, and other details.
Maybe they entered during business-hours, or maybe they broke in at 3AM. Maybe the package was a gift, maybe it was an explosive.
Hopefully the FBI won't be shooting people dead as a means of preparing a legal case—-that would be a pretty frightening 'ends justify the means' mindset. The crux of the matter is due process .
Granted, I'm not a lawyer nor am I well versed in legal processes: from a purely lay perspective, I just am seeing the FBI call tactic A a crime right before employing the same tactic A to indict someone else, and it smells like hypocrisy to me (honestly, more likely mistreatment of Weev than of DPR.)
 add quote from parent comment
It's certainly a novel approach to jury selection. Probably would be popular amongst a few State Bars.
But what worries me is that all of this will have to be eventually dumbed down to an explanation that a jury of average joes can understand. The increasingly technical complexity of evidence in some of these cases worries me that our system doesn't have an adequate way to deal with it.
This isn't a case that hinges on a technical nuance. It will be practically impossible for DPR to convince a jury that there is any reasonable doubt as to his guilt.
Isn't that for the judge to decide? Judge decides what can be presented to the jury, and jury renders the verdict, right?
Then the argument doesn't need to be dumbed down for the jury. They won't see it at all.
Although the argument will still probably have to be dumbed down for the judge.
I mean, the actual box was presumably seized after a proper warrant for searching a specific physical location. The question is would the fact that his stuff was searched be considered "fruit of the poisoned tree" since the servers were identified through that IP or as "inevitable discovery" since if he's a suspect, it's standard procedure to search his stuff anyways. But IANAL so I'm not sure how it works in USA.
Not necessarily. They could give up the right to a jury trial and go for a bench/judge trial. That's often done in complex or technical cases (the reasoning being that, despite the pro-state biases, better to appeal to an experienced and known-intelligent person like a judge than to risk the prejudices of the common man).
Indeed. Then, "any sufficiently advanced technology is indistinguishable from magic", and you have some ingredients for a witch-hunt.
Jurors don't switch off because they are learning how to move money between banks or break into servers - they switch off because it takes three months to present a case.
You think a cop did this? No... the FBI has technical personnel. Just like any corporation, they have different departments to fulfill different needs.
This is the equivalent of is the FBI allowed to search my trash if the trash is in a trashcan on my property or on the sidewalk, being pulled by a street cleaner or knocked over by a fox. We can make it as complicated as we like but the law needs to draw some lines somewhere and stick to them.
If so, is their any guidance from case law about the difference between some sort of legal poking and prodding vs illegal hacking?
(f) This section does not prohibit any lawfully authorized investigative, protective, or intelligence activity of a law enforcement agency of the United States, a State, or a political subdivision of a State, or of an intelligence agency of the United States.
I'm not sure what "lawfully authorized" means there, but my current belief is that one form of it is permission from the Attorney General.
Legally I don't know if we should allow "fuzzing" without a warrant. They've put people in jail for doing less.
The FBI discovered a flaw that let them see the IP address of a web server.
Weev discovered a flaw that let him see private information of AT&T customers.
Customer information is generally considered much more sensitive than an IP address.
Regardless, two wrongs...
Even in the hypothetical case where – for some unrealistic reason – the Silk Road hidden site was including an image on an external server by referencing its IP address or hostname, the agents would still observe this traffic as having come from Tor. There is no magic way that the traffic from a real IP embedded within the HTML of a hidden service would find its way directly to a client without passing over the Tor network and through Tor nodes. Were this the case, it would be a huge vulnerability in Tor, as it would allow the administrator of a hidden site to uncover visitors by including an element that is served directly to the client over clearnet (thankfully it isn’t and this doesn’t work – try it).
This wouldn't allow you to identify users, the request for captcha.jpg is still routed through TOR. However it does reveal the true IP of the server.
I'm definitely not a lawyer, but the server had an unknown provenance and it was physically located in Iceland, and that probably makes for some fuzzy ground at best as to whether or not what anything the FBI did to gain some sort of access to the physical server, even if it was made possible by parallel construction, would even be illegal.
Start up the Sill Road server with a tor circuit in front of it (isolated from the main network.) Then have the FBI demonstrate how to get the server to cough up it's IP. It's easy to prove who's telling the truth here.
Instead, I'm led to ask at what point will people stop using "myself" as a formal version of "me"? It isn't, it actually has a completely different usage.
In this case: "the SR Server was located by myself and another member of the CY-2". Here 'by myself' means 'on my own', not 'by me', so it directly confuses the meaning of this sentence. To me the obvious meaning is that they both work independently and found the same thing.
About the only other time you can use '-self' is in the reflexive, as in "I did this to myself", "you do this to yourself". I will never do something to yourself, and you will never do something to myself.
So, I know this is completely out of place, but if I can get one person to not do this in the future, I will make my life a bit happier. Also if I can persuade that small group of nameless people (you know who you are) that "could care less" actually means the opposite of what they think it does; and that "alot" is not a word.
I'm all for the English language evolving and expanding, but let's weed out the bad ideas which only increase confusion and bring nothing good. And seriously, "alot"? "Lot" is a three letter word, it's not hard to spell. As for "a" ...
Consider: "the SR Server was located by another member of the CY-2 and myself".
I'm not claiming that "me" wouldn't parse, but that using the current rules properly would not cause confusion in the first place. Someone is trying to sound intelligent, while putting their name first so as to emphasize their contribution.
I do appreciate it's very common in what I'd call pseudo-formal speech, mostly used when trying to impress someone one perceives to be of higher social station. Estate agents do it a lot when talking to clients. And so it does have the "well, lots of people do it" support.
However, if you go back to the roots (Latin), "myself" is specifically the reflexive form of the first person. When the first person is the object or the dative, it is "me/to me". So to have correct agreement with the verb, your example should end in "and me".
While your example is easy enough to parse, it doesn't actually follow the rules - though maybe the common practice. And if you rearrange the two object nouns (i.e. back to the original) the sentence loses clarity. Using "me" never loses clarity, and the ordering of object nouns shouldn't matter beyond providing emphasis.
Basically, that example is ok in Perl, but not in Java ;)
And ultimately, using the reflexive form incorrectly never makes a sentence clearer, and it's longer to write and say.
Anyway, this is so far off the OP's topic, which is actually much more important & interesting, I do apologise to him/her.
"I located the SR server by myself.", not
"The SR server was located by myself", which I don't think anyone, even those using this objectionable form, would produce.
I understand and sympathize with your distaste for the expression: it goes against previous rules of formal written English, and it signals the style adopted by people speaking for organizations attempting to convey power and control, which goes against the anti-authoritarian ethos of HN. But these sorts of judgments are usually motivated by deeply-held feelings and then rationalized as pleas for clarity and precision in language.
ETA: I should have said "one possible technology"; there may be others, but I am pretty sure that an IP-less Tor node requires that you play the Tor Bridge game and stream the Tor protocol over a non-IP link. I have had a prototype of this design running, but have yet to have it to a point I consider robust.
As an additional security measure, B could live behind a firewall that only let connections to Tor nodes. (yup, it might be a PITA to set up.)
Shouldn't be hard to create a script to generate e.g. iptables rules that permit connections to Tor public relays.
The security benefit is a bit marginal, though. The public relay list is basically world-writable.
But that raises another point I'd neglected. On the Tor gateway, you can block access to the public internet by anything other than the Tor process.
The security benefit against maliciousness is iffy, since the most likely route of compromise for a Tor gateway that's been set up with even a little care is the Tor process, but it certainly reduces the chance of accidents.
Bugs can exist even in code most of us would consider trivial. The Tor daemon is definitely not trivial, and the project itself points out that it needs work!
Here is "just" container.c from the Tor project. It's one very small part of the project that does fairly simple things any professional developer ought not have much trouble understanding.
It's almost 1600 lines. Are you telling me you can guarantee there are no bugs of potential security significance in that file?
They also want to make Tor even more multithreaded than it already is. Threaded code never has bugs, right?
Any software is a potential attack vector. Tor is no different.
You could probably proof it from anything but business-level error.
Not the OP, and I don't know much about Tor's protocol, but at a guess one might start with deliberately malformed layers of the onion, so you route through a Tor entry node, the outer onion layer is removed, then the packet is forwarded to a Tor relay.
The Tor relay then unwraps the next layer of the onion, but the data within that layer is deliberately malformed to trigger a bug in the Tor code running on that relay.
Ideally you actually place the HSB and TG in different network segments so packets from the HSB must pass through a router to get to the TG and vice-versa, ensuring a compromised HSB has no possibility of sniffing any incriminating broadcast traffic to/from the TG.
1. They could have meant simply viewing all the HTTP response headers with something like Chrome's dev tools, Firebug, or possibly a proxy like Burp Suite.
2. They may have set up Tor to essentially use no hops and use only their own host as an exit node. That way they would be able to directly observe traffic from a clearweb IP address in a PCAP. Or they could set just a single hop and specified another host they control as an exit node. This seems way overboard just to find an exposure like this, but it's possible that the FBI or NSA have such test environments to probe for other Tor-related vulnerabilities and misconfigurations.
2. exploit client tor missconfig
3. repeat 1-2 until you have a net so wide of tor users that only node out is the service