Re-Using Same Encryption Keys
In its survey of IoT devices, the company studied 4,000 embedded devices from 70 different hardware vendors, ranging from simple home routers to Internet gateway servers, and discovered that…
…over 580 unique private cryptographic keys for SSH and HTTPS are re-shared between multiple devices from the same vendor and even from the different vendors.
The most common use of these static keys are:
- SSH host keys
- X.509 HTTPS certificates
SSH host keys verify the identity of a device that runs an SSH server using a public-private key pair. If an attacker steals the device’s SSH host private key, he/she can impersonate the device and trick the victim’s computer to talk to his computer instead.
The same happens in the case of websites if an attacker gains access to the device’s HTTPS private certificate, which is actually used to encrypt traffic between users and its Web-based management interface.
The attacker can then decrypt the traffic to extract usernames, passwords and other sensitive data with the help of device’s HTTPS private key.
MILLLLLIONS of Devices Open to Attacks
When scanned the Internet for those 580 keys, the researchers found that at least 230 crypto keys are actively being used by more than 4 Million IoT devices.
Moreover, the researchers recovered around 150 HTTPS server certificates that are used by 3.2 Million devices, along with 80 SSH host keys that are used by at least 900,000 devices.
The remaining crypto keys might be used by various other devices that are not connected to the Internet, but could still be vulnerable to man-in-the-middle (MITM) attacks within their respective local area networks.
As a result, potentially Millions of Internet-connected devices can be logged into by attackers, or their HTTPS web server connections can silently be decrypted by MitM attackers, using these crypto keys and certs once they’re extracted from their firmware.
Where Does the actual Problem Reside?
The issue lies in the way vendors build and deploy their products. Typically, the vendors built their device’s firmware based on software development kits (SDKs) received from chipmakers…
…without even bothering to change the source code or even the keys or certificates that are already present in those SDKs.
There are many reasons why this large number of devices are accessible from the Internet via HTTPS and SSH. These include:
- Insecure default configurations by vendors
- Automatic port forwarding via UPnP
- Provisioning by ISPs that configure their subscribers’ devices for remote management
“The source of the keys is an interesting aspect. 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 vendors,” Sec Consult wrote in its blog post.
List of Vendors that are Re-Using Encryption Keys
Although SEC Consult identified more than 900 vulnerable products from roughly 50 manufacturers, the actual number could be even higher considering that its study only targeted firmware the company had access to.
According to SEC Consult, these are the companies that were found reusing encryption keys:
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.
Most Affected Countries
Here’s the list of Top 10 countries that are affected by SSH/HTTPS encryption key reuse:
- United States
- Mexico
- Brazil
- Spain
- Colombia
- Canada
- China
- Russian Federation
- Taiwan
- United Kingdom
SEC Consult has “worked together with CERT/CC to address this issue since early August 2015.” and it recommends vendors to use securely random cryptographic keys for each IoT-capable device.
Moreover, ISPs are advised to make sure that there is no possibility to remotely access CPE (customer premises equipment) devices via WAN port. In case they need access for remote support purposes,“setting up a dedicated management VLAN with strict ACLs is recommended.”
