Alleged Silk Road black market operator Ross Ulbricht was convicted in 2015; an appeal of his life sentence is still before the courts. In an attempt to suppress evidence obtained from the Silk Road servers, his defence accused the FBI of illegal searches and questioned whether the NSA was involved. A key aspect of this argument revolves around how the FBI located the Silk Road server in an Icelandic data centre. If illegal methods were used, the majority of evidence against Ulbricht could be excluded.
The FBI’s response, including an interesting sworn statement by former FBI Special Agent Christopher Tarbell, described how the server was located:
“The IP address leak we discovered came from the Silk Road user login interface. As noted in the Complaint, any Internet user could access the Silk Road website using free, publicly available Tor browser software. Upon typing in the address of the site (known as a .onion address) into the browser, the user would be directed to Silk Road’s user login interface, which consisted of a black screen containing a prompt for a username and password, as well as a CAPTCHA prompt, requiring the user to type in certain letters and numbers displayed in a distorted manner on the screen, in order to prove that the user was a human and not an automated computer script.
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.
Upon examining the individual packets of data being sent back from the website, 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.”
Some security researchers have publicly criticized the FBI’s explanation, suggesting critical details were omitted and that a PHP variable leak was responsible for disclosing the site’s public IP address. Even if they are correct, the same conclusions can be drawn about the site’s security architecture.
It appears that the Silk Road server had a public IP address, a web server bound to that address (or listening on all network interfaces), and relied solely on application-level configurations to perform as a Tor hidden service. IP address leaks had apparently occurred in the past; a footnote in Tarbell’s statement includes, “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.”
Given the criminal activity facilitated by the underground site, this IP address leak worked in the public interest. However, Tor hidden services are also used for legitimate purposes such as media outlets protecting sources. More generally, VPNs are commonly used to to protect sensitive servers. The practice of installing Tor or any VPN service on the same server as protected resources results in unnecessary risk.
In addition to being carefully configured, VPN-protected servers should not have a public IP address. They should use the operating system firewall to restrict network traffic. Outbound Internet connectivity for operating system and application updates, if required, should occur through an HTTP proxy with whitelisting access control. Other communications, including DNS, should be blocked by network-level controls outside the server. This should render the server incapable of direct Internet communication even if it is compromised.
VPN functionality is best provided by a dedicated VPN gateway or firewall. Tor hidden service implementations require additional protection. Tor software should be installed on a dedicated physical or virtual server with a private IP address. A NAT firewall should restrict all traffic between the Tor server and the Internet. A second firewall, or carefully configured multi-interface firewall, should allow only essential communication between the Tor server and the hopefully hidden service.
With Tor and VPNs there are no guarantees, but a proper security architecture that embraces defence in depth and multiple network zones is a solid step in the right direction.
Have a security question you’d like answered in a future column? Email email@example.com
SAMSUNG GALAXY S8 PLUS
The Samsung Galaxy S8 Plus is a beautifully crafted smartphone with nearly no bezel, curvaceous in design and reflects a…
How to: Connect to Exchange Online Using Multi-Factor Authentication
Using PowerShell to manage your Microsoft cloud services like Exchange Online and using multi-factor authentication (MFA) separately is awesome. Using…