Recent IoT threats and lessons learned
The most obvious IoT-security threats are illustrated by several recent IoT attacks. Each attack occurs in a well-understood context such as commissioning a gateway to a service, adding users and devices, or device operation. Each stage has well-documented mitigations against the threats. Attackers nonetheless exploit simple and well-documented flaws in poor products.
Figure 1: IoT Device Lifecycle (Source: Greenwave)
#1 Mirai-based IoT Botnets
Recent large-scale “IoT botnet” attacks exploit well-documented problems like commissioning using a well-known password. From this poor, well-document flaw, Mirai malware infected HD video cameras and players. It used “UPnP Firewall Traversal” in home routers to get outside-in access. A botnet can easily recruit a device that runs with a well-known password and automatically opens the home firewall. Last fall, these botnets directed HD video streams from their “owned” devices against the websites of Krebs on Security, Dyn, and others, effectively denying access to them for extended periods of time in a large-scale distributed denial of service (DDoS) attack.
This Mirai botnet exploited commissioning flaws in retail video devices; another exploited an operations-management flaw in 900,000 European service-provider gateways that were successfully attacked through their management service. Once again, a well-known password is the problem and “secure commissioning” is the cure that protects the device with a properly-constructed, secret password or other strong authenticator to device login. This is widely practiced by all but a few vendors that instead dump poorly-designed products onto the Internet market.
#2 Adding Users and User Privileges
The obvious lesson from the IoT botnet is that network products such as cameras and home routers must restrict access by outsiders. This is basic to IoT devices. But IoT services are more complex and have multiple user roles and privilege levels beyond the single “admin.” For example, all family members may be allowed to check the battery levels of devices such as door locks, but only Mom can change the door-lock code.
An IoT door lock is often on a specialized battery-powered network, and users connect to it through a gateway. IoT platforms such as Samsung SmartThings have gateways to specialized networks like Z-Wave and ZigBee - each with their own device interface and privileges. Uniting multiple interfaces into one is done by a “semantic gateway,” which is embedded in an IoT hub, residential gateway or other network device.
Figure 2: Semantic Interoperability between IoT Products (Source: Greenwave)
In the figure above, a door lock has a single privilege level: “admin” has full access to change the door-lock code, check the battery and read a log of when the door was opened or code changed. But the IoT app on the user’s smartphone has a richer interface with more users, roles and privileges: The user interface to the “Semantic Gateway” has one privilege level to change the code (high privilege) and another to check the battery (low). Users and privileges are mapped to the IoT device interface, which is more primitive. Thus, there is a risk of “privilege escalation” if a bug allows a user with rights to read the battery to change the code.
Security researchers demonstrated privilege escalation in one commercial IoT platform in a lab using a specially-crafted - but otherwise ordinary - Android app. This is a big threat: semantic gateways are big in IoT; often there’s no single fix to “privilege escalation” whether it’s a bug in the design, in a standard or single implementation. Regardless, vulnerability analysis is needed to catch the problems before they are released; training and secure development processes are needed to catch the problems before they are introduced into software or hardware.