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.
People who use the stock firmware on APs and other embedded devices will be using cryptography that is actually easily breakable, because these devices usually do not offer the option of regenerating a private key specific to the device (and even when they do, hasty consumers won't regen a key anyway.)
Someone had to do it.
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.
So how does this affect things like dd-wrt, open-wrt, and tomato where custom firmware is in place?
"Bah!" - Dogbert
Until Linksys, D-Link, Netgear, et al get their collective heads out their arses, these types of tools are great for pen testing small business networks. Personally, I can't wait for the Android app; maybe I could hack one together and get it out there...
put the what in the where?
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.
They can get your password as you send it to the router, even though the password is encrypted.
What a fool believes, he sees, no wise man has the power to reason away.
You are at work and you decide to login to your home router's web server to look at statistics or make a change or whatnot.
A coworker sniffing your https traffic can decode it because he has the key. He can then see your administrative password and login to your router.
Someone had to do it.
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
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
I'm vaguely shocked that any home routers would be using hardcoded private keys. That would be like every Schlage front door knob having identical keys. It's not just a mistake, it's extremely negligent security 101.
The ______ Agenda
So you'll have no problem posting all your passwords, social security number, bank account numbers, and so on publicly, then. Right?
This is one of the stock answers to the "information should be free" in copyright debates. The stock counter to that is that published credentials, such as passwords and the like, have little or no legitimate use other than to defraud people who do business with the rightful owner of the credentials. But this situation is far more nuanced than the typical use of this answer. Publishing an RSA private key almost sounds like publishing passwords, as an RSA key is a credential used to sign communication between a router and an end user administrator, but it's something that the router makers are distributing anyway as part of router firmware. The parallel with Wikileaks is that creating a repository of such keys is a way of pointing out the flaw in a cryptosystem where all devices have the same private key.
From the article: "...making it a simple matter for an attacker to decrypt the traffic passing through the device". I'd think it would only be *to* the device.
SSLKeyLeaks
He who knows best knows how little he knows. - Thomas Jefferson
"...simple matter for an attacker to decrypt the traffic passing through the device" Wrong. This will only give the attacker the ability to decrypt encrypted sessions to/with the device. Encrypted traffic going through the device to another nonidentical host will use a different private key.
Netgear, Belkin and the rest might deserve it but I don't. This is really lazy on the part of router manufacturers and I'm looking for a new one right now. Hopefully I can find one where the manufacturer doesn't suffer from a common sense failure.
My DD-WRT router generates a new cert every reboot.
If your router appliance firmware generates a new keypair and certificate every time you restart it, you'd have no easy way to tell whether you generated a given certificate or the man in the middle generated it. Even key continuity management fails in such a case. Who signs such certs? What am I missing?
So you'll have no problem posting all your passwords, social security number, bank account numbers, and so on publicly, then. Right?
Not the same. This is more like calling the emperor naked. The bad guys already know that "security" is often just a theatre. This is just a blunt way to raise awareness of that fact and force vendors to start taking security more seriously.
My other account has a 3-digit UID.
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.
+1
Any device made by a sane security designer would either generate a key pair where a cert would be sent to the device maker to be certified, or have a unique private key installed at the factory where it can be signed with a CA before it ships (although this gives the issue of trusting pre-generated keys even though they are individual and different per device.)
With how brutal attacks through the Internet are, this is bordering on criminal negligence on a massive scale.
Of course, it looks like the only way to get around this (assuming the Web server on the WAN side can be disabled) is to have ssh available, ssh in to a hardened machine on the inside (that has a unique, known key), then view the config page with a browser. Even VPN connections couldn't be trusted.
Ideally, browsers should have three SSL security levels:
Self-signed SSL cert. For the average user, it shouldn't bring up a lock icon, but something different saying the site is using some basic, untrusted cryptography to communicate.
'Average users' are precisely the kind of people who have to be beaten over the head with the fact that they're connecting to a site with a self-signed certificate. Average users typically don't check for a lock icon in the first place, so they're sure as hell not going to check for a self-signed certificate icon.
The real problem is that the entire CA model is fundamentally broken, not that browsers give warnings for certificates that might be OK or might be an Elbonian hacker trying to steal your bank account.
You are at work and you decide to login to your home router's web server to look at statistics or make a change or whatnot.
Administering a home router from outside the firewall was already known to be foolhardy. How many people allow remote administration of their router? If a home server is also hosted on the router, or is protected from remote administration only by the router, then it is also placed at risk by allowing remote administration of the router.
Our router only accepts administration from behind its firewall. Our web server only accepts administration from a subset of IP addresses behind the firewall (and not including the router). Hell, even the printer is set up that way.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
I took a look at this LittleBlackBox tarball. It contains a lot of source code (sqlite, openssl, libpcap plus the the LittleBlackBox program itself which uses these libraries). I wouldn't trust any of the source code or the precompiled binaries. So that leaves you with a file called "lbb.db", which is an sqlite database. Get at that data in some other way (surely there are some sqlite tools for browsing databases or dumping them to text?)
I don't see the WRT54GL listed in there, nor Tomato firmware. Of course. The stock firmware generates the key every time you boot the thing! (Well-known, major nuisance.) Tomato generates one once which is then persisted.
Yes. In the configuration there is a way to turn off wireless config access. Dont remember where it is (probably under the administration tab) but its an enable/disable radio choice.
Procrastinating life a way at a rapid rate of speed.
If you cannot trust the key that the bank physically hands you, the bank has already been comprimised, and there is NO security that you can take to prevent abuse of the bank's system. The OP didn't say that it would provide absolute security from every possible way your accound could be hacked. Nothing ever will. It DOES remove a significant vector of attack.
Most routers can be configured to allow you to connect remotely over the Internet, using https to 'protect' your admin session. In practice, I don' know why most people would need to do this - for the most part, once you get one of those configured, you basically leave it alone forever. I suppose if you had a need to turn on port forwarding on some port, remotely, perhaps you'd want this. Maybe someone administering the router for a relative, friend, or client might want to enable it.
In any case, in the scenario above, since you aren't connecting on the local WiFi network, the WiFi encryption is irrelevant - the only thing protecting your session as it traverses the 'public' Internet is the SSL encryption.
Christmas shoppers have been mentioning netbooks to me this year. When I state that they use their CDs, they are unaffected "--that's fine, all I have is MP3s!" or "won't watch DVD's that tiny screen!"
As their only tech, I'm seeing problem-solving on them will be a pain. Live USB workarounds don't mirror Windows's standard troubleshooting CD without a bunch of research. Also, adding their Turbotax and CD software will be a pain, because everyone finally groks flash drives, but nobody distributes software uniquely with them.
What is the difference between giving them access to the wired network and giving them the preshared key for WEP or WPA2?
The difference is that many home routers have an option to only allow devices on the wired network to configure the router. Anyone connected to the wireless network, if this option is enabled, isn't in a position to be able to do a MitM attack when you change the configuration. (On wired+wireless home routers, the network appears to be a single LAN, but is usually really a pair of bridged LANs, one for wireless and one for wired.)
Now, some routers are fancier and can be set up with VLANs to permit only the machine connected to a particular Ethernet port to configure the router. That's not a common feature, nor is it trivial to set up.