A recent study analyzed the firmware images of more than 4000 embedded devices -- Internet gateways, routers, modems, IP cameras, VoIP phones, etc - and discovered that they share the same hard-coded SSH (Secure Shell) host keys or HTTPS (HTTP Secure) server certificates. 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 cryptographic keys (public keys, private keys, certificates) in firmware images. The most common use of these static keys is SSH Host keys (keys required for operating a SSH server) and X.509 Certificates used for HTTPS (default server certificate for web based management).

In total, the analysis found more than 580 unique private keys distributed over all the analysed devices. When correlating those keys with data from public Internet scans, the researchers 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.

SSH Host keys have been embedded, essentially "baked in" the firmware image (operating system) of devices and are mostly used for providing HTTPS and SSH access to the device. This is a problem because all devices that use the firmware use the exact same keys.

Some keys were only found in one product or several products in the same product line. In other cases the sresearchers found the same keys in products from various different vendors.

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.

The researchers suggest vendors make sure that each device uses random, unique cryptographic keys. In the case of CPE devices, both the ISP and the vendor have to work together to provide fixed firmware for affected devices.

Furthermore ISPs have to make sure remote access via the WAN port to CPEs is not possible. In case the ISP needs access for remote support purposes, setting up a dedicated management VLAN with strict ACLs (no CPE to CPE communication) is recommended.

End users should change the SSH host keys and X.509 certificates to device-specific ones. This is not always possible as some products do not allow this configuration to be changed or users do not have permissions to do it (frequent in CPE devices). The required technical steps (generating a certificate or RSA/DSA key pair etc.) are not something that can be expected of a regular home user.