Late in 2015, we wrote about a survey by a European security consultancy called SEC Consult that looked at the cryptographic safety of the average web server.
The results were worrying: 3,200,000 publicly-visible web servers were using private keys that weren’t actually private.
In fact, they were already publicly known, and detectably so.
Let’s remind ourselves why that matters.
Regular encryption algorithms, such as the widely-used and highly-recommended AES, implement symmetric encryption.
This works just like the deadlock on your front door: you turn the key one way to lock, and you turn the same key in the other direction to unlock.
This sort of system is simple, effective and quick, but has two tricky disadvantages:
- If you want someone else to be able to unlock the door, you have to trust them with a copy of the key. There’s nothing to stop them losing it, or even from making illicit copies for other people.
- To send them a copy of the key in order to set up a secure communication channel, you have to have a secure channel already. Otherwise, you can’t get the key to them without the risk of it being copied along the way.
So, in the electronic world, symmetric encryption on its own is not much use for online commerce, because the whole idea is to handle orders and payments from new customers whom you’ve never met in person, and probably never will.
That’s where public-key cryptography, also called asymmetric encryption, comes into the equation.
Invented in the UK and then independently in the USA in the 1970s, asymmetric encryption relies on two keys: a public key that locks your data, and a corresponding private key that can unlock it.
You generate public and private keys in pairs, a process that is much slower than actually using either of the keys later on, but nevertheless takes only a few seconds on a modern computer.
The mathematics of asymmetric encryption is such that:
- You can’t decipher the original data using just the public key. Only the private key can do that.
- You can’t figure out the private key from the public key. Keys can only be generated together in pairs.
Private really does mean private
Done correctly, you really can make your public key public, whereupon everyone in the world can communicate securely with you, provided that you keep your private key private.
But if someone manages to get hold of your private key, they may be able to masquerade as you in many ways:
- By setting up an imposter web server that identifies itself as your official site.
- By digitally signing software so that it looks like an official release of yours.
- By logging into third-party servers and “proving” that they are you by identifying themselves using your private key.
So, nine months after SEC Consult’s report identifying 3,200,000 web servers with private keys that were already publicly known, you might think that the warning would have sunk in.
But this time round, they found that the count had gone up to 4,500,000 servers with private keys that simply weren’t private.
How do private keys become public?
One common reason for shared private keys is when a vendor sells a home networking product, such as a router, that has a private key burned into the router’s downloadable firmware.
In other words, the vendor generates a public/private key pair, as expected…
…but then shares it with every similar device that gets shipped.
For a while, no one may notice, but once the secret’s out, anyone can get the private key, possibly for hundreds of thousands of devices at the same time, simply by buying a device of their own and extracting the private key.
Or they may well be able to recover the private key by simply downloading the vendor’s latest firmware update file and extracting the key from there.
Sharing private keys in this way just doesn’t make sense. (If it did, they wouldn’t be called private keys.)
Each device needs its own private key, ideally one that’s generated, along with its matching public key, when the device is first deployed.
That way, the private key doesn’t even exist until the device is actually installed and prepared for use.
What to do?
We need to get collectively better at this, so we’ll repeat the advice we gave last time.
If you create firmware for embedded devices:
- Don’t share or re-use private keys. If you generate firmware files for each device, customise the keys in each firmware image and use it once only. If you generate keys when the device first starts up, don’t rely on “random” data sources that are likely to be the same on every router at first boot (e.g how long since the power came on, or how much memory is installed).
- Don’t enable remote administration by default.
- Don’t let users activate a new device until they have set all necessary passwords. In other words, get rid of default passwords and keys- every crook has a list of what they are.
If you use embedded devices:
- Set proper passwords before taking the device online.
- Only turn on remote administration when genuinely necessary. Also, consider two-factor authentication for external users, to reduce the risk posed by stolen passwords.
- Verify your remote access settings. Consider using a network diagnostic tool such as nmap. You may as well scan your own network for security mistakes. The crooks will!
- Re-generate cryptographic keys, if you can, as part of installing the device. This is a way to get rid of any low-quality keys inherited by default.
12 comments on “4.5 million web servers have private keys that are publicly known!”
Sadly many these days take things for granted such as using keys that are out in the public somewhere thinking this will be okay. We need to take security more seriously these days in all aspects of life.
Why don’t those router manufacturers use a hash of the unique MAC address on each router for the private key? It would never appear in firmware and could simply be referenced by code as needed.
The MAC address isn’t a secret – it’s emitted in every wireless packet (even if the packet data is encrypted), by design. It’s meant to be unique but also a matter of public record.
Data of that sort, such as MACs on networks cards and IMEIs on mobile phones, are good examples of bad encryption key seeds. More info here:
It would still require the router/device to be able to generate the key. This means that now when someone disassembles it, they can decode the key for any router/device that uses that code. Many devices you can change the MAC address. Sounds good, but they’ve struggled with this for a long time. The bottom line is manufacturing is about making money. Sometimes getting it out the door overrides the consumer (more than we’d like.) Then legislators get involved…..:)
What does the original study have to do with web servers? Nothing?
Quoting from the survey itself (linked to above), the “number of devices on the web using known private keys for HTTPS server certificates” was 4.5M.
So, the survey was measuring “HTTPS servers on the web.” Those sure sound like “web servers” to me 🙂
I am assuming most of them were web-based GUIs or APIs for managing embedded devices like routers, rather than servers like the the ones running Naked Security…
…but they were web servers nevertheless.
While this is probably correct, the article doesn’t identify the 4.5M bad web servers as those of home routers.
The article talks about: web servers with shared private keys; segways to public/private keys; then talks about how private keys get shared.
It links the 2nd and 3rd point, but, until your comment, doesn’t clearly link the 1st and 3rd point.
Will these rogue servers be outed at some point to let the rest of us avoid them (i.e., add to safe web page filter via blacklist) if need be?
It is insane that the public is so blind to the lack of security for our information. Passwords, credit card data, social security numbers, all pretty easily accessible by a low grade hacker. Imagine what the elite hackers can do…
Let’s suppose I’ve a home router with remote administration turned on and with the default (bad, publicly known) private key. Millions of such routers around the world. I don’t really get – what is the problem? Can you hack the router because of this ? How?
Reccomendation to update the above article under “If you create firmware for embedded devices:” with:
Disable all insecure / vulnerable protocols / services such as Telnet, & UPnP/ SSDP by default. – 100’s of thousands of devices have these on the devices / or used by them. These weaknesses / holes can easily give rise to exploits of home and business Routers and their compromise & monitoring.
The article doesn’t go into general advice like this, because it’s focused on private key generation, but…
…+1 to your recommendations. Telnet! Why do we still have that at all? Same for FTP, given that as soon as you provide an SSH server on your device, you can login, copy and FTP files encrypted, essentially “for free”, via the SSH server.