From the roof of your apartment building, you’re probably surrounded by the Internet of Things (IoT). On the street below, hundreds of “computers on wheels” drive by every hour, each of them made up of sensors, processors and networking equipment. On the skyline, apartment buildings prickle with an array of antennae and dishes connecting the many personal assistants, smart microwaves and learning thermostats to the internet. Above, mobile data centers streak through the sky at hundreds of miles per hour, leaving a data trail thicker than their contrails. Walk into a manufacturing plant, a hospital, or an electronics store and you’ll be similarly overwhelmed by the ubiquity of connected devices.
Although definitions differ widely, even among experts, for purposes of this book, the term IoT refers to physical devices that have computing power and can transfer data over networks, yet don’t typically require human-to-computer interaction. Some people describe IoT devices by what they almost are: “like computers, but not quite.” We often label specific IoT devices as “smart” — for instance, a smart microwave — although many people have begun questioning the wisdom of doing so. (See Lauren Goode’s 2018 article in The Verge, “Everything Is Connected, and There’s No Going Back.”) It’s doubtful that a more authoritative definition of IoT will arrive anytime soon.
For hackers, the IoT ecosystem is a world of opportunities: billions of interconnected devices transferring and sharing data, creating a massive playground for tinkering, crafting, exploiting and taking these systems to their limits. Before we dive into the technical details of hacking and securing IoT devices, this chapter introduces you to the world of IoT security. We’ll conclude with three case studies about the legal, practical, and personal aspects of securing IoT devices.
Why Is IoT Security Important?
You’ve probably heard the statistics: Tens of billions of new IoT devices will exist by 2025, increasing global GDP by tens of trillions of dollars. But that’s only if we get things right and the new devices fly off the shelves. Instead, we’ve seen safety, security, privacy, and reliability concerns stifling adoption. Security concerns can be as much of a deterrent as the price of a device.
Slow growth in the IoT industry isn’t just an economic issue. IoT devices in many areas have the potential to improve lives. In 2016, 37,416 people died on American highways. According to the National Highway Traffic Safety Administration, 94 percent of those deaths were caused by human error. Autonomous vehicles can drastically reduce those numbers and make our roads safer, but only if they’re trustworthy.
In other parts of our lives, we also stand to reap benefits from adding greater capabilities to our devices. For instance, in health care, pacemakers that can send data to the doctor daily will significantly reduce death from heart attacks. Yet in a panel discussion at the Cardiac Rhythm Society, a doctor from the Veteran’s Affairs system said that her patients refused to get implanted devices because they were afraid of hacking. Many people in industry, government and the security research communities fear that a crisis of confidence will delay lifesaving technology by years or decades.
Of course, as these same technologies become increasingly intertwined with our lives, we must know — not just hope — that they’re worthy of the trust we place in them. In a U.K. government-funded study of consumer beliefs about IoT devices, 72 percent of respondents expected that the security was already built-in. Yet, for much of the IoT industry, security is an aftermarket afterthought.
In October of 2016, the Mirai botnet attacks occurred, and the U.S. federal government, along with others around the world, collectively took notice. This escalating series of attacks co-opted hundreds of thousands of low-cost devices for its own purposes, gaining access through well-known default passwords such as admin, password and 1234. It culminated in a distributed denial of service (DDoS) against domain name system (DNS) provider Dyn, part of the internet infrastructure for many American giants, such as Amazon, Netflix, Twitter, the Wall Street Journal, Starbucks and more. Customers, revenue and reputations were shaken for more than eight hours.
Many people assumed the attacks had been the work of a foreign national power. Shortly after Mirai, the WannaCry and NotPetya attacks caused trillions of dollars in damage globally, partially because they impacted IoT systems used in critical infrastructure and manufacturing. They also left governments with the distinct impression that they were behind the curve in their duty to protect their citizens. WannaCry and NotPetya were essentially ransomware attacks that weaponized the EternalBlue exploit, which takes advantage of a vulnerability in Microsoft’s implementation of the server message block (SMB) protocol. By December of 2017, when it was revealed that Mirai had been designed and executed by a few college-aged kids, governments around the world knew they had to examine the extent of the IoT security problem.
There are three paths forward for IoT security: the status quo can remain, consumers can begin to “bolt” security onto devices that are insecure by default or manufacturers can build security into the devices at the outset. In the status quo scenario, society would come to accept regular harms from security issues as a necessary part of using IoT devices. In the aftermarket security scenario, new companies would fill the void neglected by device manufacturers, and buyers would end up paying more for security whose capabilities are less fit for purpose. In the third scenario, in which manufacturers build security capabilities into their devices, buyers and operators become better equipped to address issues, and risk and cost decisions shift toward more efficient points in the supply chain.
We can draw instruction from the past to see how these three scenarios, especially the last two, might work out. For instance, the original fire escapes in New York were frequently bolted to the outside of buildings. As a result, they often increased cost and harm to the occupants overall, according to an Atlantic article titled “How the Fire Escape Became an Ornament.” Today, they’re built into buildings, often the first thing constructed, and residents have never been safer from fires. Much the same as fire escapes in buildings, security built into IoT devices can bring new capabilities not possible in bolted-on approaches, such as updatability, hardening, threat modeling, and component isolation — all of which you’ll read about in this book.
Note that the aforementioned three paths forward aren’t mutually exclusive; the IoT market can support all three scenarios.
How Is IoT Security Different Than Traditional IT Security?
IoT technology differs from more familiar information technology (IT) in key ways. I Am The Cavalry, a global grassroots initiative in the security research community, has an instructional framework for comparing the two and is outlined here.
Consequences of IoT security failures might cause a direct loss of life. They could also shatter confidence in the firm or the broader industry as well as trust in a government’s ability to safeguard citizens through oversight and regulation. For instance, when WannaCry hit, patients with time-sensitive conditions such as strokes or heart attacks undoubtedly went untreated because the attack delayed care delivery for days.
The adversaries who attack these kinds of systems have different goals, motivations, methods and capabilities. Some adversaries might try to avoid causing harm, whereas others might seek out IoT systems specifically to cause harm. For instance, hospitals are frequently targeted for ransom because the potential harm to patients increases the likelihood and speed of the victims paying.
The composition of IoT devices, including safety systems, creates constraints that aren’t found in typical IT environments. For instance, size and power constraints in a pacemaker create challenges for applying conventional IT security approaches that require high amounts of storage or computing power.
IoT devices often operate in specific contexts and environments, such as homes, where they’re controlled by individuals without the knowledge or resources needed for secure deployment, operation and maintenance. For instance, we shouldn’t expect the driver of a connected car to install aftermarket security products such as antivirus protection. Nor should we expect them to have the expertise or capability to respond quickly enough during a security incident. But we would expect this of an enterprise.
The economics of IoT manufacturing drive device costs (and therefore component costs) to a minimum, often making security an expensive afterthought. Also, many of these devices are targeted at price-sensitive customers who lack experience selecting and deploying infrastructure securely. Additionally, the costs of the devices’ insecurity frequently accrue to individuals who aren’t the primary owner or operator of a device. For instance, the Mirai botnet took advantage of hardcoded passwords, embedded in chipset firmware, to spread. Most owners didn’t know that they should change their passwords or didn’t know how to do so. Mirai cost the U.S. economy billions of dollars by targeting a third-party DNS supplier that didn’t own any impacted devices.
Timescales for design, development, implementation, operation, and retirement are often measured in decades. Response time might also be extended because of composition, context, and environment. For instance, connected equipment at a power plant is often expected to live for more than 20 years without replacement. But attacks against a Ukrainian energy supplier caused outages mere seconds after the adversaries took action within the industrial control’s infrastructure.
What’s Special About IoT Hacking?
Because IoT security differs from traditional IT security in significant ways, hacking IoT systems requires different techniques as well. An IoT ecosystem is typically composed of embedded devices and sensors, mobile applications, cloud infrastructure and network communication protocols. These protocols include those on the TCP/IP network stack (for example, mDNS, DNS-SD, UPnP, WS-Discovery and DICOM), as well as protocols used in short-range radio (like NFC, RFID, Bluetooth and BLE), medium-range radio (like Wi-Fi, Wi-Fi Direct and Zigbee), and long-range radio (like LoRa, LoRaWAN and Sigfox).
Unlike traditional security tests, IoT security tests require you to inspect and often disassemble the device hardware, work with network protocols that you won’t normally encounter in other environments, analyze device-controlling mobile apps and examine how devices communicate to web services hosted on the cloud through application programming interfaces (APIs). We explain all of these tasks in detail throughout the following chapters.
Let’s look at an example of a smart door lock. Figure 1-1 shows a common architecture for smart lock systems. The smart lock communicates with the user’s smartphone app using Bluetooth Low Energy (BLE), and the app communicates with the smart lock servers on the cloud (or, as some would still say, someone else’s computer) using an API over HTTPS. In this network design, the smart lock relies on the user’s mobile device for connectivity to the internet, which it needs to receive any messages from the server on the cloud.
All three components (the smart lock device, smartphone app and cloud service) interact and trust each other, making for an IoT system that exposes a large attack surface. Consider what happens when you revoke the digital key to your Airbnb guest using this smart lock system. As the owner of the apartment and the smart lock device, your mobile app is authorized to send a message to the cloud service that cancels the guest user’s key. Of course, you might not be anywhere near the apartment and the lock when you do that. After the server receives your revocation update, it sends a special message to the smart lock to update its access control list (ACL). If a malicious guest simply puts their phone on airplane mode, the smart lock won’t be able to use it as a relay to receive this state update from the server, and they’ll still be able to access your apartment.
A simple revocation evasion attack like the one we just described is indicative of the types of vulnerabilities you’ll come across when you hack IoT systems. In addition, the constraints imposed by using small, low-power, low-cost embedded devices only increase the insecurity of these systems. For example, instead of using public-key cryptography, which is resource-intensive, IoT devices usually rely only on symmetric keys to encrypt their communication channels. These cryptographic keys are very often non-unique and hardcoded in the firmware or hardware, which means that attackers can extract them and then reuse them in other devices.
Frameworks, Standards and Guides
The standard approach to dealing with these security issues is to implement, well, standards. In the past few years, many frameworks, guidelines and other documents have tried to solve different aspects of the security and trust problem in IoT systems. Although standards are meant to consolidate industries around generally accepted best practices, the existence of too many standards creates a fractured landscape, indicating a broad disagreement about how to do something. But we can draw a lot of value from looking at the various standards and frameworks, even as we recognize that there’s no consensus about the best way to secure IoT devices.
First, we can separate those documents that inform design from those that govern operation. The two are interrelated because a device’s designed capabilities are available to operators to secure their environments. The converse is also true: Many capabilities absent in the device’s design are impossible to implement in operations, such as secure software updates, forensically sound evidence capture, in-device isolation and segmentation and secure failure states, among others. Procurement guidance documents, often issued by companies, industry associations or governments, can help bridge the two documents.
Second, we can distinguish frameworks from standards. The first defines categories of achievable goals, and the second defines processes and specifications for achieving those goals. Both are valuable, yet frameworks are more evergreen and broadly applicable because security standards frequently age quickly and work best when they’re use-case-specific. On the other hand, some standards are extremely useful and form core components of IoT technology, such as those for interoperability like IPv4 and Wi-Fi. As a result, a combination of frameworks and standards can lead to effective governance of a technical landscape.
In this book, we reference frameworks and standards, where appropriate, to give designers and operators guidance on how to fix issues that security researchers identify when they use the tools, techniques and processes we outline. Here are examples of standards, guidance documents, and frameworks:
Standards
The European Telecommunications Standards Institute (ETSI), founded in 1988, creates more than 2,000 standards every year. Its Technical Specification for Cyber Security for Consumer Internet of Things outlines detailed provisions for building IoT devices securely.
The U.S. National Institute of Standards and Technology (NIST) and the International Organization for Standardization (ISO) publish several standards that support secure IoT devices.
Frameworks
I Am The Cavalry, founded in 2013, is a global grassroots initiative composed of members of the security research community. Its Hippocratic Oath for Connected Medical Devices describes objectives and capabilities for designing and developing medical devices. Many of these have been adopted into the Food and Drug Administration’s regulatory criteria for approving medical devices. Other frameworks include the NIST Cybersecurity Framework (which applies to owning and operating IoT devices), Cisco’s IoT security framework, and the Cloud Security Alliance IoT Security Controls Framework, among others.
Guidance Documents
The Open Web Application Security Project (OWASP), started in 2001, has branched out well beyond the scope of its namesake. Its Top 10 lists have become powerful tools for software developers and IT procurement and are used to increase the level of security across various projects. In 2014, its IoT Project published its first Top 10 list. The latest version (as of this writing) is from 2018. Other guidance documents include the NIST IoT Core Baseline, the NTIA IoT Security Upgradability and Patching resources, ENISA’s Baseline Security Recommendations for IoT, the GSMA IoT Security Guidelines and Assessment and the IoT Security Foundation Best Practice Guidelines.
* * *
Excerpted from Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things by Fotios Chantzis and Ioannis Stais, to be published on March 23, 2021, by No Starch Press. Copyright © 2021 by Fotios Chantzis and Ioannis Stais. Excerpted by permission of No Starch Press. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
