Forgot your password?
typodupeerror

Comment: Re:Too bad we can't trust them (Score 1) 142

by blueg3 (#47860967) Attached to: Feds Say NSA "Bogeyman" Did Not Find Silk Road's Servers

Inbound with Tor is not so bad, but it requires a two-machine setup that's nontrivial for a non-sysadmin to do correctly. Getting the server's outbound (new connections, not return traffic) to transit over Tor exclusively is less easy. Ideally, you don't make outbound connections from your server.

You know Silk Road actually used reCAPTCHA, yes?

Comment: Re:Too bad we can't trust them (Score 1) 142

by blueg3 (#47854519) Attached to: Feds Say NSA "Bogeyman" Did Not Find Silk Road's Servers

You hit login 100 times

That's a coy way of saying they were trying to do SQL injection and it didn't work.

and it spits out the IP address for no reason.

In the course of trying to do SQLi, they generated a ton of different error message. The HTML source of one of the error message contained the server's real IP address. Pretty easy mistake to make if you unwisely put your hidden-service Web server and your Tor proxy on the same physical machine (thereby running your Web server on a device that has a public IP address).

Such a configuration might be necessary if, for example, your website integrates a third-party system (like a captcha) and that third party happens to block Tor traffic.

Comment: Re:Server doesn't have client's real IP address (Score 1) 142

by blueg3 (#47854431) Attached to: Feds Say NSA "Bogeyman" Did Not Find Silk Road's Servers

They're saying the server leaked its own IP address. Unless you've set up your system so that your Tor hidden server is on a computer not connected directly to the Internet and it connects to a physically-separate Tor node that blocks any network flows other than ones going over the Tor proxy, then any Tor hidden server also has a leakable IP address. A Web server error message (or embedded error message from a third-party service, for example), header, or other piece of data might then contain the server's IP address.

That's pretty thin information by itself. But if any part of your server is configured to listen on all network interfaces (instead of, say, localhost), then someone making an HTTP request to that IP address gets a page from your server. That's fairly damning evidence.

Comment: Re:I don't buy it (Score 1) 151

by blueg3 (#47603163) Attached to: Planes Can Be Hacked Via Inflight Wi-fi, Says Researcher

Hardcoded credentials aren't necessary. What they *mean* is that the *reason* for hardcoded credentials is "support". "Necessary" here doesn't actually mean "necessary", but rather, "deemed to be the best choice". Of course, it might really be the best choice. There's certainly a cost associated with making the support more complicated. You have to weigh that against the difficulty of using the hardcoded credentials and what you can do with them. There are lots of potential tradeoff points, from "using hardcoded credentials was the stupidest choice you've ever made" to "it's technically offensive, but also the best option".

Comment: Re:Do cellphone chargers require USB negotiation? (Score 1) 205

by blueg3 (#47576225) Attached to: "BadUSB" Exploit Makes Devices Turn "Evil"

Sure. Depending on your device (iPhone works differently from the standard USB fast-charging spec), you should be able to easily look up what resistors need to go where. (As mentioned, non-iPhone devices use an informal standardized spec. A circuit diagram of something like a Samsung charger should show you.)

Comment: Re:Oh think of the fun when drivers update firmwar (Score 1) 205

by blueg3 (#47576195) Attached to: "BadUSB" Exploit Makes Devices Turn "Evil"

What sneakernet issue? Be more clear. USB devices do not contain installable software, except for the obvious and well-known case of a mass-storage device happening to contain files that can be intentionally or inadvertently executed by the end user after the MSD is connected.

Comment: Re:Do cellphone chargers require USB negotiation? (Score 1) 205

by blueg3 (#47575523) Attached to: "BadUSB" Exploit Makes Devices Turn "Evil"

You just need a resistor or two. Almost any USB-charged device will charge at 500 mA if it is connected to a dumb charger (no data lines), but in order to charge at a higher current (as many devices do), it needs to sense that it's connected to a charger that supports the higher current draw. So that it can be implemented without real USB-supporting electronics, that's just done with some simple electrical components. So you can make a charger that blocks the data lines but permits full-speed charging.

If you're okay with the slow version, just go out and buy a "power only" USB cable. They already exist. Alternately, this.

Comment: Re:How is this viable as an attack medium? (Score 4, Interesting) 205

by blueg3 (#47574581) Attached to: "BadUSB" Exploit Makes Devices Turn "Evil"

1. A ton of USB devices are actually implemented as general-purpose components with programmable firmware (attached to whatever support hardware, like a network card or a webcam, is necessary). So they're more common than you think.

2. Smartphones are an excellent reprogrammable USB device that lots of individuals have.

3. This is difficult enough to really engineer well that it is probably a bigger threat as a targeted attack against a big organization for now. Until someone does the engineering to make it easy to deploy widely. Then, it'll be a threat for everyone. Kind of like automated hacking of consumer-grade routers to modify the firmware to participate in an Internet-wide portscan. It's the Metasploit effect: it's not a big problem until someone makes it automated, then it is.

If it smells it's chemistry, if it crawls it's biology, if it doesn't work it's physics.

Working...