European security consultancy SEC Consult has spent time over the past few years looking at embedded devices on the internet.
Embedded devices are what you might call the high end of the Internet of Things (IoT) – or, to use the cynic’s description: tiny computers, usually built down to a price, embedded in houselhold devices for which form, function and price come way ahead of security, if security is even considered at all.
SEC Consult has examined thousands of devices such as internet gateways, routers, modems, IP cameras, VoIP phones, and more, from over 70 vendors.
The researchers took two approaches:
- Analyse device firmware images for cryptographically-related content. (Many devices are Linux-based, so the firmware and its source code are supposed to be public.)
- Perform internet scans to examine devices that are connected to the internet. (This is not hacking, just looking for services that are already explicitly available from the public side of the network.)
One of the things they looked for was cryptographic keys for the SSH and TLS protocols.
SSH is typically used to secure remote logons or file copying; TLS is typically used to secure web traffic using HTTPS.
Both these protocols use what’s called public-key cryptography, where the server generates a special keypair when it is installed or first starts up, consisting of:
• A public key, which you tell to everyone, used to lock transactions to and from the server.
• A private key, the only way to unlock data that was locked with the public key.
The idea is simple: by having a two-key lock of this sort, you don’t have to share a secret key with the other end before you first communicate, and you don’t have to worry about sharing that secret key with someone who later turns out to be a crook.
The vital part of this two-key system is the rather obvious requirement that you keep the private key private, thus the name private key.
Generally speaking, your private key is for you to use on your server, to secure your (and your customers’) traffic.
If you let anyone else get a copy of your private key, you’re in real trouble, because they could set up an imposter site, and use your private key to convince visitors that they were you.
Or they could intercept traffic between you and your customers, and use your private key to unscramble it later on.
Carelessness with a private key is like letting someone else borrow your signing seal. (These are still widely used in the East, though they have long died out in the West.)
With your signet ring on his finger, a crook could sign a completely fake document in our name, or open up a sealed document you’d already sent and then re-seal it so the recipient would never know.
You’d think, therefore, that private keys on embedded devices would be something any vendor would take seriously: one device, one key, generated uniquely and randomly, either on first use or securely in the factory.
But SEC Consult found the following rather alarming facts:
- 3.2 million devices were using one of just 150 different TLS private keys.
- 0.9 million devices were using one of just 80 different SSH private keys.
Remember, these were all keys that the researchers found uncontroversially by looking, without any hacking, whether white-hatted, grey-hatted or black-hatted.
In other words, we should assume that every cybercrook worth his salt (yes, that’s a pun!) already has these 230 digital signet rings handy, ready to wield them whenever convenient.
Worse still, as SEC Consult points out, it’s extremely unlikely that all of the millions of devices mentioned above were supposed to be accessible, whether by TLS or SSH, over the internet, especially since many of the TLS-protected web services, and most of the SSH ones, relate to administration and configuration of the device itself.
On most networks, administration access is supposed to be limited to users on the internal network, if only to reduce the number of places from which a crook could try connecting.
WHAT TO DO?
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 – 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.