Slashdot Mirror
Database of Private SSL Keys Published
Trailrunner7 writes "A new project has produced a large and growing list of the private SSL keys that are hard-coded into many embedded devices, such as consumer home routers. The LittleBlackBox Project comprises a list of more than 2,000 private keys right now, each of which can be associated with the public key of a given router, making it a simple matter for an attacker to decrypt the traffic passing through the device. Published by a group called /dev/ttyS0, the LittleBlackBox database of private keys gives users the ability to find the key for a specific router in several different ways, including by searching for a known public key, looking up a device's model name, manufacturer or firmware version or even giving it a network capture, from which the program will extract the device's public certificate and then find the associated private SSL key."
Presumably it will allow an attacker the ability to listen passively for traffic between a router administrator and the router itself, allowing the attacker to gather login credentials and use them to whatever ends they intend.
So you'll have no problem posting all your passwords, social security number, bank account numbers, and so on publicly, then. Right?
What a fool believes, he sees, no wise man has the power to reason away.
Encryption is only as strong as the idiots who implement it. The Soviets learned that the hard way during the early part of the Cold War, when they accidentally reused random one-time pad encryptors. That led to the NSA's VENONA project, and we decrypted a pretty good amount of Soviet diplomatic and spy traffic before they were tipped off.
No, like most people who say that ... he only supports someone else's information being made public.
Lost at C:>. Found at C.
1) Router administrator negotiates an HTTPS or SSH session with a router or other hardware
2) Attacker is either listening passively or is a man in the middle (via ARP poisoning or what have you). Because they have the private key, they can advertise themselves as being the router without raising the alarm with your SSH client or browser
3) You provide credentials to the router (or MITM). The credentials are logged by the attacker
4) You proceed to do whatever you intended to do in the router's configuration, and log out.
5) Some time later, the attacker logs into the router as you, and makes nefarious changes to the router configuration (such as uploading compromised firmware which logs traffic, or has a backdoor, etc). Any changes done look like they've been done by the router administrator.
I don't know how likely this is in a work scenario though; I haven't searched the database for common mid-level to enterprise routers/remotely configurable switches. More than likely, in a work situation, you'd be using hardware which generates a key pair upon initial configuration. The scenario above is more likely to apply to SOHO, or to consumer wireless hardware in the home.
Information shouldn't be kept private
Apple ran into something similar a long time ago for Mac OS X Server. The servermgrd daemon uses a self-signed SSL cert by default to secure communications with remote management tools. About four or five versions back the certificate was identical across all installations because it was contained in the installer package. Someone had to go down and show them that you could read all of the traffic by using sslsniff and the private key from your own copy of the installer. They changed to an individual, automatically generated certificate shortly thereafter.
--Paul
that's the SSH key. The article is talking about the SSL key used by the embedded web server, ie. when you go to https://192.168.1.1/ . TFA also specifically says this DOES affect DD-WRT.
DD-WRT, at least, installs with no SSL certificate in place and auto-generates one the first time it starts up.
This is really the correct solution, and a number of home routers actually do it.
Of course, there's a tradeoff. If you use a fixed certificate, you can have it legitimately signed. Then, if someone does a man-in-the-middle attack, you get the browser warning that they're using a self-signed certificate. Unless, of course, they're using the real fixed certificate. If, on the other hand, you use an autogenerated certificate, then the self-signed cert browser warning always appears (as you can only autogenerate self-signed certificates). The user learns that clicking through this warning is a necessary part of changing their router configuration. Then, any man-in-the-middle attack works, since anyone can make a self-signed certificate. (Yes, if they or the browser store the original cert and compare it to the new one, then this is no longer an issue.)
Realistically, I think this is a non-issue. If you're using home routers, they should only be configurable from the wired LAN, and only trusted people should be on that network.
I'd think it would only be *to* the device
That, and I think the attacker has to be on the network you're using to administer the device.
For a home router, with remote administration hopefully disabled, that would be your local net. So, if you have an attacker in your living room https: // 192.0.0.1 (or whatever) won't be any saver than http: // 192.0.0.1
This has zit to do with certification authorities, because the certificate would not be recognized as valid by any browser, because the DNS name would not match. And no certification authority worth their salt would sign a certificate for 10.0.0.1 or similar nonsense.
So, the solution would be D. generate a unique private/public key pair for each device, and have the user manually accept the certificate as an "exception" on first usage. Which he has to do anyways, even if all routers use the same certificate.
Moderators, please don't mod articles about certificates if you don't understand how certificates work.