in Tor

Analyzing the FBI’s Explanation of How They Located Silk Road

The first incarnation of online drug marketplace Silk Road was shutdown in October 2013 resulting in the arrest of Ross Ulbricht. In the indictment the Department of Justice contend that Ulbricht was Dread Pirate Roberts, the owner and administrator of Silk Road. The case has been in pretrial for some time now, with defense lawyers contesting many elements as part of a large and broad motion to dismiss (subsequently denied) and other filings.

The marketplace was hosted as a hidden service on Tor, a distributed network that provides a layer of anonymity for web and other traffic on the internet. Edward Snowden’s leaks revealed that the NSA target Tor users and that the agency has struggled to deanonymize users on the network.

One of the big outstanding issues was how the FBI managed to uncover the real IP address of the server hosting the Silk Road. The indictment is intentionally vague on the details of how the server was discovered, and the issue is important since a large number of users (numbering in the millions) rely on the Tor software network to protect their identity.

Last month Ulbricht’s lawyers filed a motion seeking to uncover details on how the FBI located the server. The core of the issue for the defense is if the FBI violated Ulbricht’s Fourth Amendment right to privacy in tracking down the server IP address by using any unlawful techniques or a method that would have required a warrant. If the evidence is found to have been obtained unlawfully, then much of the case against Ulbricht would collapse as all subsequent evidence discovered as a result of the server being uncovered would be ruled inadmissible.

On Friday Wired reported that the FBI had responded with their own filing detailing how they uncovered the server:

The FBI claims to have found the server’s location without the NSA’s help, simply by fiddling with the Silk Road’s login page until it leaked its true location.


they found a misconfiguration in an element of the Silk Road login page, which revealed its internet protocol (IP) address and thus its physical location.

The government response consists of first the DOJ filing, and then the affidavit from the FBI tech team (PDF). The affidavit is more interesting since it delves into the “tech” of how the server was uncovered. Breaking it down:

The first three sections go into the background and experience of the team investigating. The fourth briefly explains what Tor is, its purpose and how it works. The fifth section opens with:

In order for the IP address of a computer to be fully hidden on Tor, however, the applications running on the computer must be properly configured for that purpose. Otherwise, the computer’s IP address may “leak” through the traffic sent from the computer. See, e.g., Tor Project, Guide on How to Tor-ify Various Applications, wiki/doc/TorifyHOWTO (“Tor does not protect all of your computer’s Internet traffic when you run it. Tor only protects your applications that are properly configured to send their Internet traffic through Tor.”).

This is true – there are many, many ways that a Tor configuration can leak and reveal details about a user that could lead to them being identified. The cited wiki page on the Tor project website lists a number of the potential leaks. One problem – the page they link to and cite refer to Tor clients – not hidden services. The leak issues and attack vectors on that page are for end users of Tor browsing the web or hidden services (it goes into how to use an isolating proxy, how to torify certain applications such as email and irc clients, etc.), they don’t apply to Tor hidden services and servers.

The only page for hidden services is on the main Tor project website, and all it says about “leaks” for servers is:

You need to configure your web server so it doesn’t give away any information about you, your computer, or your location. Be sure to bind the web server only to localhost (if people could get to it directly, they could confirm that your computer is the one offering the hidden service). Be sure that its error messages don’t list your hostname or other hints. Consider putting the web server in a sandbox or VM to limit the damage from code vulnerabilities.

The reason why there isn’t a longer page on hidden service leaks is because there isn’t much to add. Tor operating as a hidden service doesn’t leak information directly, the risk is at the application layer. The advice found at the Tor website, as well as in similar tutorials such as at the Whonix project, are all about setting up your web server so that it doesn’t do anything silly – such as include its IP address in the server signature. This is an entirely separate class of “leaks” to those described on the Tor wiki page cited in the FBI affidavit.

The affidavit goes on to say:

During the course of the FBI’s investigation of the Silk Road website, the SR Server was located by myself and another member of the CY-2 squad of the FBI New York Field Office as a result of such a leak.

They couldn’t have been using a leak described in the cited Tor wiki page, since they only apply to Tor clients. The FBI indictment and affidavits make no mention of the Silk Road server being used as a client, but it does describe other servers that Silk Road administrators were using as either Tor clients or bridges. The first step in setting up a hidden service on Tor is to disable the client functionality (and even were it left enabled, it would only be listening on localhost as default and would not be used).

Further, onto sections 6, 7 and 8 – :

6. The IP address leak we discovered came from the Silk Road user login interface.


7. In or about early June 2013, another member of CY-2 and I closely examined the traffic data being sent from the Silk Road website when we entered responses to the prompts contained in the Silk Road login interface. This did not involve accessing any administrative area or “back door” of the site. We simply were interacting with the website’s user login interface, which was fully accessible to the public, by typing in miscellaneous entries into the username, password, and CAPTCHA fields contained in the interface. When we did so, the website sent back data to the computer we were using – specifically, the Silk Road homepage, when we used valid login credentials for undercover accounts we had on the site, or an error message, when we used any username, password, or CAPTCHA entry that was invalid.

8. Upon examining the individual packets of data being sent back from the website,3 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. This IP address (the “Subject IP Address”) was the only non-Tor source IP address reflected in the traffic we examined. The Subject IP Address caught our attention because, if a hidden service is properly configured to work on Tor, the source IP address of traffic sent from the hidden service should appear as the IP address of a Tor node, as opposed to the true IP address of the hidden service, which Tor is designed to conceal. When I typed the Subject IP Address into an ordinary (non-Tor) web browser, a part of the Silk Road login screen (the CAPTCHA prompt) appeared. Based on my training and experience, this indicated that the Subject IP Address was the IP address of the SR Server, and that it was “leaking” from the SR Server because the computer code underlying the login interface was not properly configured at the time to work on Tor.

These are the key pieces of information – the actions the agents took to uncover the IP address. This description raises more questions than it answers.

Anybody with knowledge of Tor and hidden services would not be able to read that description and have a complete understanding of the process that the agents followed to do what they claim to have done. Were the Silk Road site still live today, and in the same state it was as in back in June 2013 when the agents probed the server, you wouldn’t be able to reproduce or recreate what the agents describe in the affidavit.

This is why there are so many different theories now on how they achieved what they claim to have achieved. The first conclusion to come out of this filing was the “leaky CAPTCHA” theory. This theory does not stand up to scrutiny because the Silk Road image CAPTCHA was hosted on the same server and at the same hidden URL as the Silk Road website. It was not, contrary to some reports, a third-party CAPTCHA. The CAPTCHA image was produced by a script that sat alongside the login and authentication endpoints.

The CAPTCHA being hosted on the same server and endpoint as the main Silk Road application caused the site problems. Since generating a CAPTCHA is resource intensive, there was a DoS attack against Silk Road which did nothing more than continuously request CAPTCHA images. The site was later modified to use cached versions of the CAPTCHA images, but these too were served from the same host and onion as the web application.

Note: I would cite more sources here, but a lot of this is from my own memory. I spent a lot of time investigating and testing the security of Silk Road (for sport) and became familiar with both its architecture and operation over the entire duration that the first site was up. I have Burp sessions of Silk Road stored somewhere which I will have to dig up – if anybody else has any screenshots or mirrors of Silk Road from this time i’d love to hear from them.

The idea that the CAPTCHA was being served from a live IP is unreasonable. Were this the case, it would have been noticed not only by me – but the many other people who were also scrutinizing the Silk Road website. Silk Road was one of the most scrutinized sites on the web, for white hats because it was an interesting challenge and for black hats since it hosted so many bitcoin (with little legal implication if you managed to steal them).

The second theory, that the agents “discovered” the real IP address by just looking at packet captures produced by a sniffer is similarly impossible. This also would have been discovered much sooner and noticed by most of the internet very quickly.

There is another related hole in the FBI theory related to the “packet sniffer.” If you are observing a hidden site on Tor, it means you are routing all of your traffic in that session over the Tor network (using your local SOCKS or HTTP proxy server). 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).

No matter how much the agents entered “miscellaneous entries” into the login form fields, and no matter what they caused the server to respond, at no time would it have been possible for a layer 3/4 sniffer to see the real IP address – it only ever would have seen Tor nodes, even if it had been accessing the real IP address.

Filling the login form with junk could only ever have altered what appeared in the application layer, and it is at the application layer that the FBI uncovered the IP address.

A More Likely Scenario

Since the FBI explanation doesn’t hold up to the IP address being revealed at lower layers, and since “typing in miscellaneous entries into the username, password, and CAPTCHA fields” (aka fuzzing) could only alter application-layer data, we need to find an explanation for what the FBI did that fits both the reality of how Tor, hidden services and the Silk Road application work and what the FBI are describing in their legal affidavit.

The FBI affidavit wouldn’t mention fuzzing if it wasn’t required to, so this must play an important part of their method. We know that the Silk Road server didn’t simply volunteer its IP address to every visitor, but we do know that the Silk Road application suffered from numerous security flaws during its lifetime.

Ross Ulbricht was not an experienced programmer and was learning how to develop web applications and write PHP at the same time as he was implementing the Silk Road web application. He (according to the DOJ) posted a question to Stack Overflow asking how to connect to a hidden service using PHP and Curl. The lax security of the web application lead to Silk Road being hacked a number of times and the personal data of users and vendors being leaked (DPR paid off at least one hacker who threatened to release data).

A much more plausible explanation is that the FBI discovered a security exploit or information leak in the login page, in the same way a number of other people discovered similar security holes or information leaks in both the login page and the Silk Road application itself.

There is a history of users reporting such security exploits and information leaks in Silk Road on various forums. On the 27th of March 2013 a user posted on reddit “WARNING: The Silk Road Revealed it’s Public IP Last Night”:

I am a penetration tester by trade, and while I do not use SR, I do occasionally conduct informal tests of the security of various Tor Hidden Services.


Last night, while SR was down for maintenance, a brief few moments allowed a certain set of circumstances that caused me to be able to view the public IP of the httpd server of Silk Road. This isn’t an obvious flaw, but it is extremely simple if you know where to look – the server basically will publish a page containing all of the configuration data of the httpd server including the public IP address.

I referenced that thread in my answer on Stack Exchange on how the Silk Road server may have been discovered shortly after the site was taken down.

“If you know where to look”, as mentioned in the comment, is a suggestion that a hidden URL was found, or the login form was forced to error and produce some debug output.

Further, on the 3rd of May 2013 there was a similar warning from another user on reddit, “Should we be worried? Showing on login page”


If this isn’t familiar to you, it is a var_dump of PHP’s $_SERVER variable. It would suggest somebody was debugging a problem on the server and editing live code, using the var_dump function to debug a problem (and inexperienced programmer would both edit on a live server and use var_dump to debug).

Further, these two dates and IP leaks are supported in the FBI’s own affidavit. In a footnote they mention:

After Ulbricht’s arrest, evidence was discovered on his computer reflecting that IP address leaks were a recurring problem for him. In a file containing a log Ulbricht kept of his actions in administering the Silk Road website, there are multiple entries discussing various leaks of IP addresses of servers involved in running the Silk Road website and the steps he took to remedy them. For example, a March 25, 2013 entry states that the server had been “ddosd” – i.e., subjected to a distributed denial of service attack, involving flooding the server with traffic – which, Ulbricht concluded, meant “someone knew the real IP.” The entry further notes that it appeared someone had “discovered the IP via a leak” and that Ulbricht “migrated to a new server” as a result. A May 3, 2013 entry similarly states: “Leaked IP of webserver to public and had to redeploy/shred [the server].” Another entry, from May 26, 2013, states that, as a result of changes he made to the Silk Road discussion forum, he “leaked [the] ip [address of the forum server] twice” and had to change servers.

Ulbricht made his diary entry on the 25th of March, the first leak was posted to reddit on the 27th. The second leak was posted to reddit on the 3rd of May, the exact date that Ulbricht notes in his diary.

The FBI agents state that their investigation was carried out “In or about early June 2013”, and that they had the IP by the 12th of June – since that is when they sent the request for a mirror of the server to be made by the authorities in Iceland (where the server was located).

The FBI investigation and uncovering of the IP address was taking place at the exact same time bugs that were known to expose the IP address of Silk Road were present on the site. A more likely scenario for how the FBI uncovered the real IP address would thus be that they either saw the debug information, or – more likely – took advantage of a security vulnerability in the login page and forced the server to output its $_SERVER variable (which includes the real IP (although it shouldn’t)).

This would explain why the FBI included the statement about “typing in miscellaneous entries into the username, password, and CAPTCHA fields”, because they needed to enter an exploit command to prompt the server to either dump or produce the IP address variable.

In this scenario, the description of packet sniffers and “inspecting each packet” is all a distraction from what the FBI really did. Technically, saying that a packet sniffer revealed the true IP address of the server is true – what isn’t mentioned is the packet sniffer was picking up responses from a request to the login page that was forcing it to spit out the IP address as part of a bug.

The FBI have good reason to not mention any bugs or forcing the server to do anything, and to pretend that they simply picked up the IP address from the wire, since such actions would raise concerns about how lawful their actions in uncovering the IP address were. What we do know is that their description of “packet sniffing” for the IP through a “leak” is impossible.

Thanks to: harisec, thegrugq and the ever useful Silk Road timeline by moustach for links and tips.


1. If you still believe that the server was discovered in the way the FBI described it – try it. I did. I setup a virtual machine with a web server running a Tor hidden server. I then accessed the hidden server over Tor and looked at the traffic. No matter how much I intentionally misconfigured the server, or included scripts from clearnet hosts, I never observed traffic from a non-Tor node or a “real” IP address.

2. Many enquiries in various comment threads about how best to setup a hidden service so that application layer bugs won’t expose your real IP address. The answer is to host the web application in a virtual machine that is on a private network isolated behind a gateway that will only forward Tor traffic. This also works for Tor clients (to prevent malware based attacks such as the that used by the FBI). I’ll likely write up details for both client and server isolated VM setups in the future.


  1. I think they’re (the FBI) talking about Apache’s response header and not TCP/IP packets headers; thus, and adding the multiple rookie misconfigurations by Ulbricht, it’s pretty much plausible.

    • In terms of Apache’s response headers, no, this is not possible, as it was never configured to listen or respond to its public WAN address – only localhost.

      • How can you be so sure?

        Your analysis itself has some major holes in it. Firstly, it makes a lot of assumptions that the Tor site was set up close to correctly. The editorial admits that his programming skills in their infancy, but seems to assume that nothing was wrong elsewhere. I’d suggest that not only was he not a fantastic programmer, but didn’t quite know how to set up a server.

        You really have to work hard to hide your address. NATing, web server configuration, session based cookies, login pages, server side applications, TCP headers, etc. It isn’t always as simple as viewing resulting HTML.

        What it overlooked is that his app had a number of entry points, and it is entirely possible that just one section, the portion they described, was more poorly written than the rest.

        • > You really have to work hard to hide your address

          No, you don’t. The tutorials how to do are that short cause its very simple. Apache on localhost, done. Getting a hidden server running is way more simple then the client side.

          What isn’t simple is to get the application-logic secure, more so when using PHP as unexperienced developer.

          100% sure the FBI lied once more or, in case its discovered, didn’t told the full truth. Unfortunately they left the parts out that *are* questionable and by doing so active prevent defense against there possible illegal actions.

          And guess what? That way of “not telling the full truth but some variant” is a common pattern as we know by the Snowden-leaks. Only a fool would assume there is any control if even courts, the legal protection, is played that way.

          There we are, doomed with a government which doesn’t found itself bound to any laws. You don’t think thats a problem?

  2. My guess is that they instrumented the Tor proxy server as their “packet sniffer” in order to capture data about requests before it goes into the Tor network (and after they pop out). In that case if a temporary misconfiguration in the PHP script served the image via a public IP address, the request would be going into the Tor network via the proxy server and popping out at an exit node somewhere else in the world to go to that public IP, but if you instrumented the Tor proxy you’d see that this is happening.

    In other words, yes, their method is plausible if you’ve instrumented the Tor proxy server. In fact, the Tor proxy server may even have such a debug mode already available if certain Java properties are set on the command line, I know I usually put such debug modes in communications software that I write (i.e. to dump data immediately before encryption / after decryption), because encrypted communications are *hard* and there are occasionally times when I have to figure out why some weird thing is happening. If you think about it for a minute, a traditional packet sniffer would be useless for debugging encrypted communications, so you *have* to actually put a Tor packet sniffer at the Tor proxy level…

    • * Tor is written in C, not in Java
      * Why would you “instrument” a packet sniffer in the Tor proxy to snoop traffic to/from your browser when you can simply do it at the browser level (there are browser add-ons for this).

  3. Maybe the NSA is recording all tor traffic a la the bahamas and just replayed the reddit poster’s Tor traffic and picked out the IP.

    I’m kidding of course.

    I think.

    • Tor hidden services don’t use SSL/TLS because communication is already peer-to-peer encrypted in Tor.

  4. Subject IP address sounds to me like a field in the TLS *certificate*, which I don’t see mentioned in your analysis.

  5. don’t pick on FBI for doing their jobs to protect the citizens. instead help them not contradict their ways, noh?

    • @anonymous I don’t know if you understand, this is a matter of whether the methods the FBI used to discover the SR server’s IP were legal, which if they weren’t could taint their entire investigation and have implications for the trial of those involved

  6. “I’ll likely write up details for both client and server isolated VM setups in the future. ”

    looking forward to it. thank you for the excellent perspective in this post.

  7. Fabulous Reverse Engineering FBI. You got the NSA to tell you then you moved in and cracked it so that you didn’t need to admit how you got it. Yeah the method works. It is right up there with the rest of the lies the surveillance state is pulling on us. They sell us on their legality and even post a few apologists to say it is so. It didn’t work that way. The process was highly illegal.

  8. While I agree that the FBI’s explanation as they gave it is impossible, I see 2 possible explanations for how their explanation would make sense. I don’t know why they would glaze over these details, but:

    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.

  9. Considering the current Administration, and especially the current Attorney General: They are pathological liars and are incapable of telling the truth. Since you presented that their explanation might be a half-truth, I would say that is as close as anyone will get. More than likely, like the DEA, they get illegal information from the NSA, and use something that might work to obsfucate their criminal behavior.

    • Not sure what the current administration has to do with anything discussed here. The previous administration was shown to have conducted illegal surveillance on judges, lawyers and members of Congress. Does that somehow suggest Bush and Cheney flew planes into the WTC?

  10. Or maybe Tor was compromised by the NSA long ago, and had not been as anonymous as we think for some time.

  11. If your looking to figure out how they did this then I recommend going to this site and trying it out. It’s a great learning tool and as a developer I recommend everyone who ever wants to build a website at least going through the basics.

    As for how they did this … Unless the developer was very new to web development and php it shouldn’t be possible and even if they were new it would still require some techniques that have gotten people in trouble with the law in the past … The true methods for how they got the IP address will have to be explained to a better degree if this goes to trial and if it does I’m sure during the jury selection the defense will try to get a few software developers.

  12. Great analysis, thank you.

    It feels rather petty to mention this but the $_SERVER output in your screenshot would have been from print_r rather than var_dump, judging by the format.

    Not what you might call a serious issue with the article!

  13. F U, dude. Too many people already “help” the FBI. Despite this “help,” it seems they can’t pour water out of a boot even with the instructions written on the bottom.

  14. I administrate it’s successor, Silk Road 2.

    For a DNS leak to occur like this, it would require the captchas be fetched from a third party source (not locally) outside of Tor traffic. I knew those stylesheets back to front and know for a fact the captchas were stored locally. The only IPv4 address they would see is (loopback).

    If that were the case and it somehow got past our very in-depth pen-testing, the headers would only reveal the IPv4 or FQDN address of the server hosting the captcha images. The FBI would then need a warrant to search that server’s logs for connections from the Silk Road server. Even if that were somehow the case, they would have only found the IPs of various Tor nodes.

    If you want a mirror of the original Silk Road’s source code to see how impossible this explanation is, we know of only two entities that have it. The FBI has a snapshot and MIT has the full source.

    If the defence had any sense, they would demand proof of concept for this explanation.

  15. Be sure to enable and configure SELinux so that Apache or whatever cannot be tricked into running ifconfig to leak your IP or run other commands which might give you away.

  16. Moral of the story is to be a better criminal. Actually he is innocent until proven guilty. Google is a search engine, Silk Road is a search engine, The Pirate Bay is a search engine. Same. Same.

    Anyway, with enough TOR exit nodes under the FBI control (i.e. spinning up millions of instances) they could have captured the traffic. Remember that there was a recent security flaw in SSL. Heartbleed.

    • “Anyway, with enough TOR exit nodes under the FBI control (i.e. spinning up millions of instances) they could have captured the traffic.”

      This needs further explanation.

      If this works then the one thing the gov probably has is a huge numbers of instances if they want to spin them up so TOR is vulnerable.

    • Even if they controlled every single exit node on the tor network it wouldn’t have helped then since EXIT NODES ARE NOT INVOLVED WITH HIDDEN SERVICES.

  17. Another hypothesis that isn’t considered here is that FBI had access to several exit nodes, and that captcha was not configured properly as an hidden service. This could have led to the disclosing of the real IP with a bit of effort.

  18. would be interesting to learn how fbi decrypted the laptop hd to obtain logs mentioned

    • that’s an easy one. they waited until he logged into his laptop in the library before they literally tackled him. since he had already typed the decryption passphrase – everything was in plain text. the latest move in computer forensics (180 degree turnaround from previous protocol that required an immediate shutdown of machine to preserve chain of custody of data) is to try to catch machines that are running. also the encryption key is stored in RAM (otherwise a password would be required for every disk access) and RAM analysis is a hot topic now. technologies are even being developed to analyze RAM after shutdown. Much like the idea of a paper clip staying magnetized for a period after having been attached to a magnet.

  19. According to the official report, they typed in the ip address and made a direct connection to the server. I don’t believe this is true based on my own research. I scanned every ipv4 address with port 80 open in search of the server just a month before they reportedly found it. My research found no results. My conclusion at the time was that the website was not publicly visible on port 80 as the official documentation seems to suggest. However, the security of the website was poorly managed, so I wouldn’t be surprised if there were actually many leaks.

    • This interested me too.

      The idea that a tor site could be compromised by simply scanning all the internet ip addresses to locate a matching server response seems a time consuming but not difficult task.

      If it would work it would be a TOR deal killer.

    • Also there statement about the captcha doesn’t make sense if you read the criminal complaint. It mentioned that Ross configured the site to only accept access from a single non Tor address, a VPS he owned. He did because the hidden service was under a ddos attack and this was the only way to connect. The FBI did not become aware of this until after they imaged the server.

        • My previous comment references bottom of pg 27-28 and the footer of pg 28 of the criminal complaint ( I’m on my mobile so I can’t copy and paste so I’ll briefly summarize.

          On May 24,2013 DPR was notified by a user about an IP leak (the VPN Ross used). His last connection to the VPN was on June 3, 2013. By the time the feds imaged the server on July 23,2013 the code was “commented out”.

          Those dates fit in nicely with the feds timeline, but I don’t know enough about servers to comment further. Is it possible that when he commented out the IP address he inadvertently disabled the whitelist which allowed all traffic? I still not sure how this would affect the captcha though.

  20. Is it possible the guy was debugging and testing his config and server from the same up where the server ran so his website was spilling his “camefrom” ip rather than the server ip? But they happened to be the same.

  21. > The FBI agents state that their investigation was carried out “In or about early June 2013″, and that they had the IP by the 12th of June – since that is when they sent the request for a mirror of the server to be made by the authorities in Iceland (where the server was located).

    So according to this, the date the FBI discovered the IP was between June 1 and June 12. And the first mirror snapshot was taken on June 12 or very shortly thereafter. The defense should have access to the mirror snapshots since they are part of the prosecution’s evidence. If the source code for the login page didn’t change between June 1 and June 12, then it can be definitely shown whether it was possible to make the login page spit out the real IP during that period.

    The mirror snapshot would contain the modified timestamp of the login page and the shell history for all users among other evidence. While a timestamp and shell history file can be modified, the combination of the timestamp and a lack of a command showing any modification to it (while other files on the system do show updated modification times) would shift the likelyhood strongly toward it not being modified during that time. Especially considering DPR thought the server was safe during that period. Plus any upload logs or revision control logs. Bottom line is, there is a solid chance the login page wasn’t modified during that time and that it’s possible to confirm definitely that a real IP leak was possible or not.

    Another thing to note is that the var_dump of $_SERVER does not magically reveal the IP addresses configured on the server. HTTP_HOST will always return what is requested in the Host: HTTP header, and SERVER_ADDR will return the IP address the current virtualhost is bound to (and will always return the same as HTTP_HOST when the Host: header is an IP address). In no case would they reveal any other IP address configured on the system. If it can be shown that the web server configuration was never bound to the real IP during the period in question (using the same method as above for the login page), that would also be definite proof that the real IP couldn’t have been leaked through a var_dump of $_SERVER.

  22. As someone who has thoroughly explored Tor hosted ‘hidden services’ I can say that the FBI explanation is highly suspicious. I wouldn’t go so far as to say it is a lie, but it is definitely not the whole truth. Fuzzing the login page may have allowed for a var_dump of the real IP, but it is highly unlikely. Also, I have checked older versions of Silk Road source and found the CAPCHAs to be hosted locally. Maybe I simply dont have old enough version of the SR source but the idea that the IP was leaked in a header and then a direct connection made seems improbable. While I wouldn’t rule this out, the idea that you could get the IP without conducting what I would term ‘illegal’ hacking is bullshit. Either the server was dangerously misconfigured at the application level or the FBI used an exploit/injection.

Comments are closed.


  • The silk road and the selective application of the law. | Diary of a free man September 15, 2014

    […]  The Silk Road case is just the most recent high-profile example of the US government “cheating” at the laws of society in order to get the results they want. There has been a lot of discussion by the security community on the FBI’s explanation of how it legally identified the server used to host The Silk Road. The consensus seems to be that the FBI is lying and the method they purportedly used is not feasible. […]

  • FBI claims no illegal techniques used in Silk Road case, security experts disagree | Bitcoinx September 15, 2014

    […] dissenting voice comes from Australian security consultant Nik Cubrilovic, who claims that users — and hackers — would have noticed a leaking IP data long before t…. Cubrilovic calls the FBI’s version of events “unreasonable,” and says that the […]

  • FBI: No Illegal Techniques Used in Silk Road Investigation - Bitcoins Channel September 15, 2014

    […] example, Australian blogger and hacker Nik Cubrilovic initial minute his critique of a filing on 7th September, observant a array of issues with a logic […]

  • » FBI’s Story of Finding Silk Road’s Server Sounds a Lot Like Hacking Mutiny Radio September 15, 2014

    […] “The idea that the CAPTCHA was being served from a live IP is unreasonable,” Cubrilovic writes in a blog post. “Were this the case, it would have been noticed not only by me, but the many other people who […]

  • FBI’s Story of Finding Silk Road’s Server Sounds a Lot Like Hacking | Nagg September 15, 2014

    […] “The idea that the CAPTCHA was being served from a live IP is unreasonable,” Cubrilovic writes in a blog post[4]. “Were this the case, it would have been noticed not only by me, but the many other people who […]

  • Analyzing the FBI’s Explanation of How They Located Silk Road | Official site of DJ Michael Heath September 15, 2014

    […] by LordRinzler [link] [comment] …read […]