IoT devices are re-using cryptographic keys, leaving in danger millions of devices

Researchers from SEC consult analyzed more than 4000 firmware’s embedded devices, where is included devices belonging to 70 vendors. The findings are astonishing!

Researchers from SEC consult analyzed more than 4000 firmware’s embedded devices, where is included devices belonging to 70 vendors. The categories of devices analyzed include Internet gateways, routers, modems, IP cameras, VoIP phones, etc. SEC Consult was analyzing specifically the cryptographic keys (public keys, private keys, certificates) in firmware images of these devices, and concluded that most common keys are

• SSH Host keys, that are required for operating a SSH server.

• 509 Certificates used for HTTPS which is the default server certificate for web based management.

These keys are generally used to access the IoT devices via SSH and HTTPS.

The experts analyzed 4000 firmware and found around 580 unique private keys, the use of Scans.io and Censys.io allowed them to discover that the same set of keys was widely re-used, on 580 keys, 230 are actively used.

• “the private keys for more than 9% of all HTTPS hosts on the web (~150 server certificates, used by 3.2 million hosts)”
• ” the private keys for more than 6% of all SSH hosts on the web (~80 SSH host keys used by 0.9 million hosts)”

Embedded cryptographic key

The firmware running on the IoT device came with embedded keys used mainly for HTTPS, and SSH connections, this bad practice exposes end users to risk of attacks. Attackers can easily find the key and access a huge quantity of IoT devices that share it.

The experts at SEC consult also discovered:

• “Some keys are only found in one product or several products in the same product line”
• “In other cases, we found the same keys in products from various different vendors.”

The researchers mentioned real cases that demonstrate the alarming habit:

• “A certificate issued to a “Daniel”, email (kiding@broadcom.com) is used in firmware from Actiontec, Aztech, Comtrend, Innatech, Linksys, Smart RG, Zhone and ZyXEL. More than 480.000 devices on the web are using this single certificate.”
• “A certificate issued to Multitech in Bangalore, India is used in firmware from Aztech, Bewan, Observa Telecom, NetComm Wireless, Zhone, ZTE and ZyXEL. Over 300.000 devices on the web are using this certificate”.
• “A certificate issued to “MatrixSSL Sample Server Cert” is used in WiMAX gateways from Green Packet, Huawei, Seowon Intech, ZTE and ZyXEL. All affected devices use the same code base, which is likely developed by ZyXEL. At least 80.000 devices on the web are using this certificate.”

Millions of devices exposed

SEC Consult’s researchers also uncovered another fact, many of these devices are directly accessible on the internet with insecure configurations and a used example is the case of Ubiquiti Networks, “who have remote management enabled by default in most products.”

Many Seagate GoFlex (80.000) are exposing HTTPS and SSH, and the blame should go the Seagate Share feature sets up port forwarding via UPnP.

In another case, the ISP exposes their clients’ IoT device by leaving their modems, routers and gateways with HTTPS and SSH remote administration features enabled by default.

The ISPs include, CenturyLink (500,000 exposed devices), TELMEX (1 million devices), Telefonica (170,000 devices), China Telecom (100,000 devices), VTR Globalcom (55,000 devices), Chunghwa Telecom (45,000) and Telstra (26,000 devices).

The counties with most affected hosts are:

SEC consult found more than 900 products from 50 vendors vulnerable, the list includes IoT devices proposed by:

ADB, AMX, Actiontec, Adtran, Alcatel-Lucent, Alpha Networks, Aruba Networks, Aztech, Bewan, Busch-Jaeger, CTC Union, Cisco, Clear, Comtrend, D-Link, Deutsche Telekom, DrayTek, Edimax, General Electric (GE), Green Packet, Huawei, Infomark, Innatech, Linksys, Motorola, Moxa, NETGEAR, NetComm Wireless, ONT, Observa Telecom, Opengear, Pace, Philips, Pirelli , Robustel, Sagemcom, Seagate, Seowon Intech, Sierra Wireless, Smart RG, TP-LINK, TRENDnet, Technicolor, Tenda, Totolink, unify, UPVEL, Ubee Interactive, Ubiquiti Networks, Vodafone, Western Digital, ZTE, Zhone and ZyXEL.

To avoid situations like these, the vendors have to ensure that each IoT device has its own unique cryptographic keys.

For the ISPs, if they need remote access for support purposes, they should set up a dedicated management VLAN with strict ACLs.

End users should change the SSH host keys and X.509 certificates of their IoT devices, an operation that is not allowed by some products, and in some cases users lack technical knowledge to change the settings.

All the problems emerged from the analysis have been reported by SEC consult to the CERT/CC which in August 2015 started informing device vendors, chipset manufacturers and affected ISPs. Some of them are already working on the fixes.

About the Author Elsio Pinto

Edited by Pierluigi Paganini

(Security Affairs –  IoT Devices, security)