In the world of communication technology, two of the events that hold special significance are the invention of ARPANET, a computer network allowing computers to exchange data even when being geographically separate, and the rise of the Internet of Things (IoT). The latter, however, was an evolving process instead of a single event. The earliest implementations of the IoT concept occurred when a couple of Carnegie Mellon University students found a way to monitor the number of cans remaining in a vending machine by allowing devices to communicate with the external world. They did this by adding a photosensor to the device that would count every time a can left the vending machine, and thus, the number of remaining cans was calculated. These days IoT devices are capable of monitoring your heart rate, and even controlling it if required in the case of an adverse event. Moreover, some IoT devices can now serve as a source of evidence during trials in court, as seen in late 2015, when the FitBit data of a woman was used in a murder trial. Other incidents include usage of pacemaker data and Amazon Echo recordings in various court trials. The journey of IoT devices from a university dorm room to being present inside human beings is fascinating, to say the least.
Kevin Aston, when he first mentioned the term Internet of Things, would probably not have imagined that these devices would soon be overtaking the entire human population in number. Aston mentioned the term in reference to radio-frequency identification (RFID) technology, which was being used to connect devices together. The definition of IoT has since changed, with different organizations giving their own meaning to the term. Qualcomm and Cisco came up with the term called Internet of Everything (IoE) , which some believe was for a marketing agenda. The term according to them means extending the concept of the IoT from being limited to machine-to-machine communication to machines communicating with both machines and the physical world.
The very first glimpse of the current day IoT was seen in June 2000 when the first Internet-connected refrigerator, the Internet Digital DIOS, was revealed by LG. The refrigerator contained a high-quality TFT-LCD screen with a number of functionalities, including displaying the temperature inside the refrigerator, providing freshness scores of the stored items, and using the webcam functionality to keep track of the items being stored. The early device that probably got the most attention from the media and consumers was the Nest Learning Thermostat in October 2011. This device was able to learn the user’s schedule to adjust different desired temperatures at different times of day. The acquisition of this IoT thermostat company by Google for US$3.2 billion was the event that made the world aware of the upcoming revolution in technology.
Soon, there were hundreds of new startups trying to interconnect all the different aspects of the physical world to devices and large organizations starting specialized internal teams to come up with their own range of IoT devices to be launched in the market as soon as possible. This race to create new so-called smart devices brings us to the present, where we are able to interact with our smart TVs at home while sipping a cup of coffee prepared by an Internet-controlled coffee machine and controlling the lights by the music playing on your smart assistant. IoT, however, is not just limited to our physical space. It also has numerous applications in enterprises, retail stores, health care, industry, power grids, and even advanced scientific research.
The policymakers of the digital world struggled with the fast pace of the rise of IoT devices, and could not come up with strict quality controls and safety regulations. This changed only recently, when organizations like GSMA came up with security and privacy guidelines for IoT devices, and the Federal Trade Commission (FTC) laid out steps to be followed to ensure safety and security. However, the delay led to widespread adoption of IoT devices in all different verticals, and it also enabled developers to ignore security considerations when it comes to these devices. It was not until the widespread effect of the Mirai botnet that the security shortcomings of these devices would be known. Mirai was a botnet that attacked IoT devices, mostly Internet-connected cameras, by checking the status of Ports 23 and 2323 and brute forcing authentication using common credentials. Unsurprisingly, many of the IP cameras exposed to the Internet had telnet available with an extremely common username and password, which was easy to find. The same botnet was also later used to take over Liberia’s Internet infrastructure as well as on DYN, which led to an attack on several popular web sites, including GitHub, Twitter, Reddit, and Netflix.
Over the past couple of years, even though security of these devices has slowly improved, it has not yet reached a point where these devices can be considered extremely safe to use. In November 2016, four security researchers—Eyal Ronen, Colin O’Flynn, Adi Shamir, and Achi-Or Weingarten—came up with an interesting proof-of-concept (PoC) worm that attacked using drones and took control of the Philips Hue smart lights of an office building. Even though the attack was just a PoC, it is not a reach to think that we would be seeing smart-device ransomware similar to WannaCry, asking us for money to open the lock on our door or to turn on a pacemaker. Nearly every smart device has been determined to have critical security and privacy issues, including smart home automation systems, wearable devices, baby monitors, and even personal sex toys. Considering the amount of intimate data these devices collect, it is scary to see how much exposure we have to cyberattacks.
The rise in security incidents in IoT devices has also led to increasing demand for IoT security professionals, both as builders and breakers. This allows organizations to ensure that their devices are protected from the vulnerabilities that malicious attackers can use to compromise their systems. Additionally, a number of companies have started offering bug bounties to incentivize researchers to assess the security of their IoT devices, with some even shipping free hardware devices to researchers. In the coming years, this trend is set to grow, and with the rise of IoT solutions in the market, there will be a heightened demand for specialized IoT security professionals in the workforce.
Previous IoT Security Issues
The best way to learn about the security of these devices is looking at what has happened in the past. By learning about the security mistakes other product developers have made in the past, we can gain an understanding of what kind of security issues to expect in the product we are assessing. Even though some terms might seem unfamiliar here, we discuss them in detail in the upcoming chapters.
Nest Thermostat
The paper “Smart Nest Thermostat : A Smart Spy in Your Home” by Grant Hernandez, Orlando Arias, Daniel Buentello, and Yier Jin, mentions some of the security shortcomings of Google Nest that allowed the installation of a new malicious firmware on the device. This was done by pressing the button on Nest for about 10 seconds to trigger the global reset. At this stage, the device could be made to look for USB media for firmware by communicating with the sys_boot5 pin. On the USB device, a malicious firmware was present, which the device then used while booting .
Jason Doyle identified another vulnerability in Nest products that involved sending a custom-crafted value in the Wi-Fi service set identifier (SSID) details via Bluetooth to the target device, which would then crash the device and ultimately reboot it. This would also allow a burglar to break into the house during the duration of the device reboot (around 90 seconds) without being caught by the Nest security camera .
Philips Smart Home
Philips home devices suffered from a number of security issues across the product range. These include the popular Philips Hue worm built as a PoC by security researchers Eyal Ronen, Adi Shamir, Achi-Or Weingarten, and Colin O’Flynn. In the PoC they demonstrated how the hard-coded symmetric encryption keys used by Philips devices could be exploited to gain control over the target devices over ZigBee. It also included automatic infection of Philips Hue bulbs placed near each other .
In August 2013, Nitesh Dhanjani, a security researcher, also came up with a novel technique to cause permanent blackouts by using a replay attack technique to gain control of the Philips Hue devices. He discovered this vulnerability after he realized that the Philips Hue smart devices were only considering the MD5 of the media access control (MAC) address as the single parameter to validate the authenticity of a message. Because the attacker can very easily learn the MAC address of the legitimate host, he or she can craft a malicious packet indicating that it came from the genuine host and with the data packets with the command to turn the bulb off. Doing this continuously would allow the attacker to cause a permanent blackout with the user having no other option than to replace the light bulb .
Philips Hue (and many other smart devices today) uses a technology called ZigBee to exchange data between the devices while keeping resource consumption to a minimum. The same attack that was possible on the device using Wi-Fi packets would also be applicable to ZigBee. In the case of ZigBee, all an attacker would need to do is simply capture the ZigBee packets for a legitimate request, and simply replay it to perform the same action at a later point in time and take over the device. We will also look at capturing and replaying ZigBee packets in Chapter 10 .
Lifx Smart Bulb
Smart home devices have been one of the most popular research targets among the security community. Another early example occurred when Alex Chapman, a security researcher from the firm Context, discovered serious security vulnerabilities in the Lifx smart bulb, making it possible for attackers to inject malicious packets into the network, obtain decrypted Wi-Fi credentials, and take over the smart light bulbs without any authentication.
The devices in this case were communicating using 6LoWPAN, which is another network communication protocol (just like ZigBee) built on top of 802.15.4. To sniff the 6LoWPAN packets, Chapman used an Atmel RzRaven flashed with the Contiki 6LoWPAN firmware image, allowing him to look at the traffic between the devices. Most of the sensitive data exchange happening over this network was encrypted, which made the product appear quite secure.
One of the most important things during IoT penetration testing is the ability to look at the product in its entirety, rather than just looking at one single component to identify the security issues. This means that to figure out how the packets are getting encrypted in the radio communication, the answer most likely lies in the firmware. One of the techniques to get the firmware binary of a device is to dump it via hardware exploitation techniques such as JTAG, which we cover in Chapter 6. In the case of Lifx bulbs, JTAG gave access to the Lifx firmware, which when reversed led to the identification of the type of encryption, which in this case was Advanced Encyrption Standard (AES), the encryption key, the initialization vector, and the block mode used for encryption. Because this information would have been same for all the Lifx smart bulbs, an attacker could take control of any light bulb and break into the Wi-Fi because the device was also communicatng the Wi-Fi credentials over the radio network, which could now be decrypted .
The Jeep Hack
The Jeep Hack is probably the most popular IoT hack of all time. Two security researchers, Dr. Charlie Miller and Chris Valasek, demonstrated in 2015 how they could remotely take over and control a Jeep using vulnerabilities in Chrysler’s Uconnect system, resulting in Chrysler having to recall 1.4 million vehicles.
Exploit code. Source: Image from official white paper at http://illmatics.com/Remote%20Car%20Hacking.pdf
Once arbitrary command execution was gained, it was possible to perform a lateral movement and send CAN messages taking control of the various elements of the vehicle, such as the steering wheel, brakes, headlights, and so on.
Belkin Wemo
Belkin Wemo is a product line offering consumers whole-home automation. Belkin Wemo is an interesting case in which the developers took precautions to prevent attackers from installing malicious firmware on the device. The firmware updates for Belkin Wemo, however, happened over an unencrypted channel that allowed attackers to modify the firmware binary package during the update. As a protection measure, the Belkin Wemo used a GNU Privacy Guard (GPG)-based encrypted firmware distribution mechanism so the device would not accept malicious firmware packages injected by an attacker. This security protection was overcome extremely easily because the device was distributing the firmware signing key along with the firmware during the update process, all over an unencrypted channel. An attacker could therefore easily modify the package, as well as sign it with the correct signing key, and the device would happily accept this firmware. This vulnerability was discovered by Mike Davis of IOActive in early 2014 and was rated a (CVSS) score of 10.0 for the criticality of the vulnerability .
Later, Belkin was found to have a number of other security issues including bugs such as SQL injection and modification of the name of the device to execute arbitrary JavaScript on the user’s Android smartphone among others. Additional research was performed on Belkin Wemo by the FireEye group (see https://www.fireeye.com/blog/threat-research/2016/08/embedded_hardwareha.html ), which involved obtaining access to the firmware and debugging console using Universal Asynchronous Receiver Transmitter (UART) and Serial Peripheral Interface (SPI) hardware techniques . This also led them to identify that via hardware access, one can easily modify the bootloader arguments, rendering the device’s firmware signature verification check useless.
Insulin Pump
A security researcher named Jay Radcliffe working for Rapid7 identified that some medical devices, specifically insulin pumps , could be suffering from a replay-based attack vulnerability. Radcliffe, a Type 1 diabetic himself, set out to research one of the most popular insulin pumps on the market, the OneTouch Ping insulin pump system by Animas, a subsidiary of Johnson & Johnson. During the analysis, he found that the insulin pump used clear-text messages to communicate, which made it extremely simple for anyone to capture the communication, modify the dosage of insulin to be delivered, and retransmit the packet. When he tried out the attack on the OneTouch Ping insulin pump, it worked flawlessly, with there being no way of knowing the amount of insulin that was being delivered during the attack.
The vulnerability was patched by the vendor, Animas, within five months, which shows that at least some companies take security reports seriously and take actions to keep consumers safe .
Smart Door Locks
A security researcher with the handle Jmaxx set out on a challenge to find security weaknesses in the August smart lock , considered to be one of the most popular and safest smart locks, used by both consumers for their homes and Airbnb hosts to allow guests to check in at their convenience. Some of the vulnerabilities that he discovered included the ability of guests to turn themselves into an admin by modifying a value in the network traffic from user to superuser, firmware not being signed, app functionality to bypass Secure Sockets Layer (SSL) pinning (enabling debug mode), and more .
At the same event, security researchers Anthony Rose and Ben Ramsey of the security firm Merculite gave another presentation titled “Picking Bluetooth Low Energy Locks from a Quarter Mile Away,” in which they disclosed vulnerabilities in a number of smart door lock products, including Quicklock Padlock, iBluLock Padlock, Plantraco Phantomlock, Ceomate Bluetooth Smart Doorlock, Elecycle EL797 and EL797G Smart Padlock, Vians Bluetooth Smart DoorlockOkidokey Smart Doorlock, Poly-Control Danalock Doorlock, Mesh Motion Bitlock Padlock, and Lagute Sciener Smart Doorlock.
The vulnerabilities discovered by Rose and Ramsey were of varying types including transmission of the password in clear text, susceptibility to replay-based attacks, reversing mobile applications to identify sensitive information, fuzzing, and device spoofing. For instance, during the process of resetting the password, Quicklock Padlock sends a Bluetooth low energy (BLE) packet containing the opcode, old password, and new password . Because even normal authentication happens over clear text communication, an attacker can then use the password to set up a new password for the door lock that would render the device useless for the original owner. The only way to reset it would be to remove the device’s battery after opening the enclosure. In another device, the Danalock Doorlock, one can reverse engineer the mobile application to identify the encryption method and find the hard-coded encryption key (“thisisthesecret”) being used.
Hacking Smart Guns and Rifles
Apart from the typical smart home devices and appliances, rifles are getting smart, too. TrackingPoint, one such manufacturer of smart rifle technology, offers a mobile application to look at the shot view and adjust it. This app was found to be vulnerable to a couple of security issues. Runa Sandvik and Michael Auger identified vulnerabilities in the smart rifle that allowed them to access admin application programming interfaces (APIs) after gaining access to the device via UART. By exploiting the mobile application, a network-based attack would allow an attacker to change the various parameters such as wind velocity, direction, the weight of the bullet, and other parameters required while preparing to shoot the bullet. When these parameters are modified, the shooter would not know that these changes have been made.
Another instance occurred when a security researcher who goes by the name Plore was able to bypass some of the security restrictions applied by IP1, a smart gun by Armatix. The smart gun required the shooter to wear a special watch provided by IP1 to fire the gun. To bypass the security restrictions, Plore initially performed radio signal analysis and found the exact frequency the gun uses to communicate. He later realized that using a few magnets, the metal plug that locks the firing plug could be manipulated, enabling the shooter to fire the bullet. Even though the use of magnets is not a high-tech attack that you might think is required to exploit IoT devices, it is a great example of how thinking outside of the box can help you identify vulnerabilities .
These vulnerabilities are meant to serve as examples to help you understand various kinds of vulnerabilities typically found in IoT devices. Later we cover various components of IoT devices including techniques for hardware, radio, firmware, and software exploitation, and you will learn more about how to use some of these techniques in the IoT devices you are researching or performing a pentest on .
Fragmentation in the Internet of Things
Because IoT is an enormous field, with every company wanting to get its share of the pie, you will often find yourself coming across various protocols and frameworks that could help developers bring their products to market quicker.
IoT frameworks are various readily available offerings that help IoT developers speed up the development process of an IoT device solution by taking advantage of the existing code base and libraries offered, reducing the time it takes to bring the product to market. Although this makes things significantly easier for developers and companies, the other side, which is often neglected, is how secure these frameworks are. In fact, based on my experiences with penetration testing IoT devices, devices using various frameworks were often vulnerable to even basic security issues. The discussions I had later with the product teams revealed that the general mindset is that if one is using a popular framework, it is often thought to be secure by design, resulting in carelessness toward assessing its security.
No matter which side you are on, the builders or the breakers, it is important to look at the security issues of the product, no matter the underlying framework or the sets of the protocol being used. For instance, you would often find developers using ZigBee thinking that it is extremely secure, leaving their products vulnerable to all sorts of radio-based attacks.
In this book, we do not necessarily focus on any given framework or technology stack, but rather look at an approach that is applicable to any IoT device solution, irrespective of the underlying architecture. In this process, however, we also cover some popular protocols (e.g., ZigBee and BLE) to give you an idea of what kind of vulnerabilities to expect and how to go about finding those security issues.
Eclipse Kura ( https://www.eclipse.org/kura/ )
The Physical Web ( https://google.github.io/physical-web/ )
IBM Bluemix (now IBM Cloud: https://www.ibm.com/cloud/ )
Lelylan ( http://www.lelylan.com/ )
Thing Speak ( https://thingspeak.com/ )
Bug Labs ( https://buglabs.net/ )
The thing system ( http://thethingsystem.com/ )
Open Remote ( http://www.openremote.com/ )
OpenHAB ( https://www.openhab.org/ )
Eclipse IoT ( https://iot.eclipse.org/ )
Node-Red ( https://nodered.org/ )
Flogo ( https://www.flogo.io/ )
Kaa IoT ( https://www.kaaproject.org/ )
Macchina.io ( https://macchina.io/ )
Zetta ( http://www.zettajs.org/ )
GE Predix ( https://www.ge.com/digital/predix-platform-foundation-digital-industrial-applications )
DeviceHive ( https://devicehive.com/ )
Distributed Services Architecture ( http://iot-dsa.org/ )
Open Connectivity Foundation ( https://openconnectivity.org/ )
Wi-Fi
BLE
Cellular/Long Term Evaluation (LTE)
ZigBee
ZWave
6LoWPAN
LoRA
CoAP
SigFox
Neul
MQTT
AMQP
Thread
LoRaWAN
To properly assess the IoT security of a given device or communication protocol, you will need various hardware tools. For instance, Ubertooth One would be required to capture and analyze BLE packets, Atmel RzRaven for ZigBee, and so on.
Now that we have a good idea of what the IoT is and the various technologies involved, let’s have a look at some of the factors leading to insecurity of these devices.
Reasons for IoT Security Vulnerabilities
Given that IoT devices are extremely complex in nature, it is highly likely that most of the devices that you encounter will have security issues. If we try to understand why these vulnerabilities exist in the first place, and how you can avoid these security issues while building a product, we need to dig deep into the entire product development life cycle, from the ideation phase until the product is out in the market.
Some of the reasons that stand out as a cause of security issues when building these devices are given next
Lack of Security Awareness Among Developers
Developers who are working on these smart devices are often less knowledgeable about, if not completely unaware of, the possible security vulnerabilities in IoT devices. Given that in large organizations, developers are often already extremely busy, it would be a great idea to have periodic meetings to discuss how developers can build secure products from scratch, including actionable tactics such as strict coding guidelines to be followed and a security checklist for any code sample they work on.
Lack of a Macro Perspective
As we see in the next chapter about the various components that constitute an IoT device, it is extremely easy for developers or security teams to forget about the fact that it is the interconnection of devices and various technologies that could lead to security issues. For instance, just looking at the mobile application might not reveal security issues, but if you combine findings from the mobile application and how the network communication works, you could possibly discover a critical security issue. It is essential for product teams to invest more time and efforts looking at the entire device architecture and performing threat modeling.
Supply-Chain-Based Security Issues
One of the causes of security vulnerabilities in IoT devices is the involvement of many stakeholders. This means that you would often find different components of devices being manufactured by different vendors, everything getting assembled by another vendor, and finally being distributed by yet another one. This, even though unavoidable in most situations, can lead to security issues (or backdoor) that could be introduced by one of them, putting the entire product at risk.
Usage of Insecure Frameworks and Third-Party Libraries
In the case of IoT devices or any other technology, you would often find developers using existing libraries and packages and introducing potentially vulnerable code samples into the secure product. Even though some organizations have quality checks on the code written by the developers, these often tend to miss the packages that the developers are using. This is also accompanied by the business requirements of an organization where the management requires products to hit the market in accelerated (often unrealistic) time frames, which puts the security assessment of the product on the back burner. Often its importance is not realized until the product suffers a security breach.
Conclusion
In this chapter we looked at what IoT devices are, the protocols and frameworks being used by these smart devices, and the reasons why these devices are often vulnerable. We also had a look at some of the previously identified security issues in popular IoT device solutions to understand what some of the vulnerabilities found in real-world devices. In the next chapter, we look more deeply into the attack surface mapping of these devices and how we can identify and possibly avoid security risks in IoT devices.