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.
#3 Adding Devices: How ZigBee Lost its Network Key
One way to mitigate privilege escalation, therefore, is security testing before deployment, particularly of semantic gateways. These products commission IoT devices onto a specialized IoT network. Because many IoT devices and networks are optimized for efficiency and not functional richness, security differs on each, and some are insecure. Today, for example, a hacked device can impersonate a ZigBee ZLL device with a stolen key.
Newer systems like Apple Homekit, Z-Wave S2, and Zigbee/Thread use elliptic-curve cryptography and user-based commissioning, instead of a pre-shared secrets. They are secure, but the majority of legacy IoT products on the market are not.
#4 Operating a Public Baby Cam
The mitigation to disclosing device secrets, therefore, is to follow published, best-practices cryptography when cryptography is needed. That applies to data encryption. The poster child for unsafe data handling is a baby-cam that sends plaintext video on unencrypted networks like open Wi-Fi. Video from a child’s bedroom should not be available to neighbors or Internet stalkers. Similar flaws exist in video doorbells. All network data needs to be encrypted.
Network encryption is necessary but not sufficient for IoT privacy. IoT gateways, border routers, hubs and other “middleboxes” expose data between encrypted connections. Network-connection security (such as SSL or TLS) ends at the IoT or cloud gateway that receives data on one TLS connection, processes the unencrypted data, and sends them on a second TLS connection. More message data is exposed than need be during processing, which violates the principle of least privilege and leaks private information. Good security practice forbids it and offers end-to-end message-level encryption to enforce it. Message-level encryption is an emerging technology in IoT security.
Meeting a Minimal Standard and Raising the Bar
Unlike other services, IoT includes specialized edge devices that run on low-powered and lossy networks. These have their own unique security methods – or none at all. Unlike smartphones and PCs, most IoT edge devices lack screens or rich user interfaces, which makes methods like secure commissioning harder to do. Secure commissioning procedures can be challenging to design and implement, but many products have done so and how to do it is well documented for any vendor who cares to look.
Several recent attacks exploit risks from substandard products that run with an well-known password or mishandle unencrypted data. These problems need not occur and should be addressed by regulation, liability laws, or industry self-policing. Whatever the solutions to today’s problems, however, we can expect that IoT attacks will become more sophisticated as defenses become more effective.
Mark Baugher is the Principal Security Engineer at Greenwave Systems, a leading international IoT software provider and services integrator partnering with Verizon, TCP, NXP, IBM, E.On, and others. Mark is a highly regarded IoT security engineer having created and patented multiple technologies that played a major role in driving a smart connected future. Mark is a published thought leader and well-respected speaker at industry events (CES, IEEE Conferences, ACM International Conferences, etc.). He holds a BA degree in Economics from the University of Missouri-Kansas City and an MA degree in Computer Sciences from the University of Texas at Austin.