Thousands of routers, modems, IP cameras, VoIP phones and other embedded devices share the same hard-coded SSH (Secure Shell) host keys or HTTPS (HTTP Secure) server certificates, a study found.
By extracting those keys, hackers can potentially launch man-in-the-middle attacks to intercept and decrypt traffic between users and millions of devices.
Researchers from security firm SEC Consult analyzed firmware images for over 4,000 models of embedded devices from more than 70 manufacturers. In them they found over 580 unique private keys for SSH and HTTPS, many of them shared between multiple devices from the same vendor or even from different ones.
When correlating those 580 keys with data from public Internet scans, they found that at least 230 keys are actively used by over 4 million Internet-connected devices. Around 150 of the HTTPS server certificates they recovered are used by 3.2 million devices and 80 of the SSH host keys are used by 900,000 devices.
The remaining keys might be used by many other devices that cannot be accessed from the Internet, but are still vulnerable to man-in-the-middle attacks inside their respective local area networks.
SSH host keys are used to verify the identity of a device that runs an SSH server. When users connect to such a device for the first time over the encrypted SSH protocol, they get prompted to save the device’s public key, which is part of a public-private key pair.
On subsequent connections, the server’s identity will be verified automatically based on the public key stored on the user’s SSH client and the private key stored on the device.
If an attacker steals the device’s SSH host private key and is in a position to intercept the user’s connection attempts, he can impersonate the device and trick the user’s computer to talk to his machine instead.
A similar attack is possible if attackers gain access to a device’s HTTPS private certificate, which is used to encrypt communications between users and its Web-based management interface.
Furthermore, if attackers can capture encrypted HTTPS traffic between users and a legitimate device and know that device’s HTTPS private key, they can decrypt the traffic at a later time to extract usernames, passwords and other authentication tokens.
SEC Consult’s analysis revealed that many embedded device manufacturers hard-code the same private keys across their own products. However, there were also cases where the same keys were found in products from different manufacturers.
Those situations are typically the result of vendors building their firmware based on software development kits (SDKs) received from chipset makers, without bothering to change the keys that are already present in those SDKs.
For example, a certificate issued to a person named “Daniel” with the email address kiding@broadcom.com was found in firmware from Actiontec, Aztech, Comtrend, Innatech, Linksys, Smart RG, Zhone and ZyXEL, the SEC Consult researchers said. The certificate comes from a Broadcom SDK and is used by over 480,000 devices on the Internet, they said.
In another case, a certificate issued to a company called Multitech from Bangalore, India, was found in firmware from Aztech, Bewan, Observa Telecom, NetComm Wireless, Zhone, ZTE and ZyXEL. That certificate was tracked to an SDK for ADSL2+ routers from Texas Instruments and is used by over 300,000 devices on the Web.
Another 80,000 devices, mostly WiMAX gateways from Green Packet, Huawei Technologies, Seowon Intech, ZTE and ZyXEL, use a “MatrixSSL Sample Server Cert” certificate.
There are several reasons why so many devices are accessible from the Internet via HTTPS and SSH. These include insecure default configurations by manufacturers, automatic port forwarding via UPnP, and provisioning by ISPs, which configure their subscribers’ devices for remote access and management, the researchers said in their report.
“Vendors should make sure that each device uses random, unique cryptographic keys,” the researchers said. “These can be computed in the factory or on first boot. In the case of CPE [customer premises equipment] devices, both the ISP and the vendor have to work together to provide fixed firmware for affected devices.”
Where possible, users should change the SSH host keys and HTTPS certificates on their devices. Unfortunately, this requires technical knowledge beyond that of an average home user and is, in many cases, impossible, especially on devices that have been locked down by ISPs.