U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
1–10 of 73 posts
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#2Some researchers at Yale have been working on a project [1], due to be presented this weekend, that disables the FBI from gaining any meaningful information via Javascript exploits. The idea is to contain each "pseudonym" in its own virtual "nymbox", and only that one box. Read the paper for more, it's interesting.
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#3At this point I feel I'm missing something as we now have two legal documents going "Nuh uh!" - "Yuh huh!"
FBI's Explanation[1] states (Page 4, Footnote #5) that the admin himself kept logs explaining that there were frequent IP leaks due to misconfiguration of the web server.
At this point aren't we lead to believe that he showed multiple cases of mismanagement. From this can we not call bullshit on the very definitive declaration by the defense that the webserver was explicitly configured to deny external connections?
[1] https://www.scribd.com/doc/238844570/FBI-Explanation-of-Silk-Road-vulnerabilityRe: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#4the FBI lied? no way.
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#5Well, fuck. Regardless of the rest, if the government's story changed in a factual way before vs. after the government acquired the Silk Road server ... well, further confirmation that parallel construction is in use and the "foreign tools" are being used in domestic cases.
"the account by former Special Agent Tarbell in his Declaration differs in important respects from the government’s June 12, 2013, letter to Icelandic authorities. For example, that letter (which is Exhibit A to the government’s opposition papers) suggests the possibility of an alternative method for the government’s identifying and locating the Silk Road Server; "
+
"The Government’s response to Mr. Ulbricht’s omnibus motion filed September 5, 2014, contains a Declaration from former FBI Special Agent Christopher Tarbell, attached hereto as Exhibit 2 (Dkt #57). The Declaration contains a vague explanation of how the IP address of the Silk Road server was initially discovered. For instance, former SA Tarbell asserts that, “[w]hen 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.” Tarbell Decl. at ¶ 8. As explained below, based upon the Nginx server configuration files provided in discovery, that was not possible. "
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#6Some researchers at Yale have been working on a project [1], due to be presented this weekend, that disables the FBI from gaining any meaningful information via Javascript exploits. The idea is to contain each "pseudonym" in its own virtual "nymbox", and only that one box. Read the paper for more, it's interesting. [1] http://arxiv.org/pdf/1312.3665.pdf
I also have an idea to stop the FBI from gaining any meaningful information via Javascript exploits: PGP or Ed25519 sign all .js files and have a browser that only executes signed code.
Not only do you need to obtain access to the server, you also need the private key of its operator. (Which should be kept offline for signing.) If they don't surrender the key, then you cannot compromise their visitors.
This can also be a mitigation for drive-by malware exploits and whatnot.
(I emailed this to LiberationTech last year, no one took any interest in the idea.)
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#7the FBI lied? no way.
according to the defendant.
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#8Quite an interesting read. Summary? Silk Road used a pair of nginx servers, one as front-end, one as back-end. The server images (captured forensically) show that the then-in-place configuration made it impossible for the FBI agent to do what he claims, that is, connect to the back-end by using the server's IP address (the allow/deny settings forbade this). The log files on the servers lack entries to support FBI claims.
Furthermore, FBI agents describe using other techniques to obtain information, e.g., fuzzing and packet sniffing. Not only do server logs NOT contain any evidence of this, but the agents did not preserve any evidence of their packet sniffing activities, despite having training in forensic investigation techniques and claiming expertise in these areas.
While it is possible that there were bugs in either the Ubuntu 12.04 hosts or the nginx servers themselves that would have allowed these activities to occur, unlogged, I suspect it would now be up to the prosecution to establish reasonable grounds for believing this to be the case. Likewise, while it is possible that the handful of lines of log pertaining to FBI activities might have been removed from the several million (yes, you read that correctly) lines of log later captured in forensic image, that does strain credulity; again I suspect the prosecution would have to establish that, somehow.
I've no particular interest in this case or in Silk Road, but I cannot help but conclude that the lawyer filing this brief just seriously schooled the FBI.
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#9At this point I feel I'm missing something as we now have two legal documents going "Nuh uh!" - "Yuh huh!" FBI's Explanation[1] states (Page 4, Footnote #5) that the admin himself kept logs explaining that there were frequent IP leaks due to misconfiguration of the web server. At this point aren't we lead to believe that he showed multiple cases of mismanagement. From this can we not call bullshit on the very definit…
Considering the FBI's explanation didn't make any sense to begin with this isn't that surprising. How were they getting non-Tor traffic out of the server at all? The IP leaks were never a result of Tor misconfiguration but were instead due to things like exploits allowing examination of PHP variables storing internal information. There is no reason to believe the FBI could have gotten the IP of any of the servers by looking at packet headers as they've claimed.
Re: U.S. v. Ross Ulbricht: Declaration of Joshua J. Horowitz [pdf]
#10Some researchers at Yale have been working on a project [1], due to be presented this weekend, that disables the FBI from gaining any meaningful information via Javascript exploits. The idea is to contain each "pseudonym" in its own virtual "nymbox", and only that one box. Read the paper for more, it's interesting. [1] http://arxiv.org/pdf/1312.3665.pdf
I also have an idea to stop the FBI from gaining any meaningful information via Javascript exploits: PGP or Ed25519 sign all .js files and have a browser that only executes signed code. Not only do you need to obtain access to the server, you also need the private key of its operator. (Which should be kept offline for signing.) If they don't surrender the key, then you cannot compromise their visitors. This can also…
It's an interesting idea, but currently quite impractical as there's no infrastructure for it.
The most secure way right now is to isloate your Tor browsing activities to a virtual machine which is only able to access the internet via Tor.
Create a VM to act as a middle node with 2 NICs, the first of which will connect to the internet and the second of which will connect to the other VM. Disable any unnecessary services, expose only Tor's proxy to the second NIC.
Create the other VM with 1 NIC in the virtual network with the Second NIC on the other VM.
This enforces Tor-only access for the second VM. Any activity must go over Tor or it may not access the internet.
Snapshot the VMs. Always restore the snapshots when beginning a new session.
Setting this up takes some time, but nearly guarantees an exploit cannot escape.
I also recommend disabling unnecessary services which may expose the host to attack (ie: file sharing and video and mouse acceleration) through the second VM. It may be more secure to use a low-level emulation (QEmu, VirtualBox or VMWare with hardware acceleration disabled) rather than a hypervisor-based VM solution for this.