Use littleBits and cloudBit to set up an environment where you can evaluate security concerns. Plus, learn about security evaluations and threat agents. Read Chapter 7 from Abusing the Internet of Things.
With the announcement of the first-generation iPhone in 2007, Apple single-handedly disrupted the smartphone industry. From an external viewpoint, the iPhone announced in 2007 may very well have been the first version of the finished product visible to the public. However, the initial product idea that eventually led to the iPhone was a touch-sensitive tablet that would allow users to do away with a physical keyboard. Once Steve Jobs saw the prototype of the tablet, he decided he wanted to implement the technology on a smartphone first.
Prototypes help us think through the relevancy of our ideas by helping us focus our intellectual capacities on the intention of our conceived product. The great thing about creating prototypes is that the process can help us quickly realize potential roadblocks to the design of the final product early on. Prototyping, just as in the case of Apple and Jobs, can also help us test different versions of an idea, which may result in a whole other form factor than what we originally planned.
Learn faster. Dig deeper. See farther.
Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.
There are numerous platforms and kits available that allow individuals to prototype ideas for IoT products with minimal cost and effort. In this chapter, we are going to focus on the littleBits platform since it is one of the simplest and most elegant prototyping solutions in the market. The littleBits module includes magnets that can be snapped together like LEGO bricks, which allows us to construct a prototype in mere seconds. We will use the cloudBit module to build a simple wireless doorbell that can send alerts via SMS message.
Once we have completed designing our prototype, we will take a look at security issues that are relevant to the littleBits platform so that we are aware of security controls we will have to put in place during subsequent iterations of our product prior to production. The goal of this exercise is to simulate real-world processes companies go through, from initial prototype to production, so we can think through how to embed security controls at the right times.
The consideration of how to secure an IoT device includes context, such as how the product may be used, and what types of threat agents are likely to abuse it for malicious purposes. For example, a sophisticated gang of terrorists may want to gain and maintain access to IoT devices that serve critical infrastructure, such as connected cars and lighting systems. On the other hand, threat agents such as cyberbullies are likely to abuse device functionalities to harass others. In this chapter we will step through designing a prototype and begin to formulate our thinking around security controls that leverage use cases and the intentions of potential threat agents.
Introducing the cloudBit Starter Kit
The cloudBit Starter Kit is a great way to start tinkering with IoT product ideas that require remote connectivity (i.e., communication via the Internet). It is a simple and elegant kit that can be used to brainstorm the feasibility of ideas and test out use cases prior to expending too much effort on a full-blown solution. The kit consists of five prototyping modules and a USB power module (Figure 1-1).
The USB power module powers the cloudBit projects. It can be powered using a USB cable or a wall adapter (Figure 1-2), both of which are included in the kit.
The long LED (light emitting diode) module can be used to provide lighting. It is called long because the light is tethered by a cable, which allows you to place it in different places within the body of the prototype hardware or another object. The servo module is a controllable motor that swings back and forth or continuously in a specific direction (clockwise or anticlockwise). The sound trigger module listens to noise levels in the environment and can be programmed to activate other modules when the noise rises above a defined threshold. The button module (Figure 1-3), as the name suggests, is a simple button that, when pressed, activates other modules.
The cloudBit module (Figure 1-4) is clearly the star of the show. It is basically a small computer that is powered by the Linux operating system. It includes WiFi functionality that can be easily configured to connect to the free littleBits cloud infrastructure that we will learn about in the following sections.
Once connected, the cloudBit module sends data to the littleBits cloud, which can be used by remote applications to control modules connected to the cloudBit.
Setting Up the cloudBit
The first order of business is to set up the cloudBit to connect to WiFi so that it can contact and connect with the littleBits cloud infrastructure. To do this, we need to first sign up for a littleBits account), as shown in Figure 1-5.
Once we have named our module, we are asked to power on the cloudBit (Figure 1-7). To do that, we attach the wall adapter to the USB power module, and then attach the USB power module to the cloudBit.
Note that littleBits modules have magnets on their sides, making it easy for them to snap together with other modules. They are also color-coded. Blue-colored modules are power modules, such as the USB power module, that help power the circuit. Red indicates input; these modules accept input from the user or the environment (an example is the button module). These modules in turn send signals to modules that are colored green to indicate output. These modules perform an action (an example is the servo, which is a motor that can rotate in a particular direction). Orange-colored modules are called wires; they are used to expand the reach of the project. An example here is the cloudBit module, which is used to provide remote connectivity to the prototype. The order in which the modules are snapped next to each other is important: power modules always come first, and input modules only affect output modules that come after them.
Once the cloudBit is powered on, the light underneath the word Status on the module will start flashing. At this point, we need to press the button titled STATUS LIGHT IS FLASHING (Figure 1-7).
Per the instructions, we hold down the setup button until the light blinks blue, and then let go until it stabilizes to a steady blue color. Once that happens, we click the BLUE LIGHT IS STEADY button shown in Figure 1-8. At this point, the cloudBit will start up its own WiFi network in the form of littleBits_Cloud_… that we can connect to (see Figure 1-9).
Once we have connected to the WiFi network exposed by the cloudBit, our browser will locate the module and query it for other WiFi networks it can detect (Figure 1-10).
At this point, we will select our home WiFi network, which is TouchOfClass in this example (see Figure 1-11).
After clicking on Save, we are asked to connect back to our home WiFi network (TouchOfClass). The cloudBit module is now configured and connected to the littleBits cloudinfrastructure.
Designing the SMS Doorbell
Now that we have our cloudBit module configured, we can use it to prototype a doorbell that sends us an SMS message when pressed. We will use the IFTTT (If This Then That) platform first mentioned in not available to handle the interaction between the cloudBit and the phone that will receive the SMS message. Go to https://ifttt.com/join to create an IFTTT account if you don’t already have one. After that, go to https://ifttt.com/littlebits to activate the littleBits channel. Activating the channel will authorize IFTTT to interact with the cloudBit using the littleBits network (Figure 1-12).
Now we are ready to create an IFTTT recipe that will send an SMS message to our phone when our doorbell is pressed. Go to https://ifttt.com/myrecipes/personal/new to create a new recipe. Click on “this” and type in little to search in the list of triggers. (Triggers are basically events that trigger a reaction; i.e., they are the “this” part of an IFTTT recipe, while an action channel [example: SMS] is the “that” part of the recipe.) Select littleBits from the list, and then click on “Input received,” which will make the recipe run when another input module (such as a button module) sends a signal to the cloudBit. Select our cloudBit, named SMS_Door_Bell (Figure 1-6), from the list of authorized cloudBits, and then click on Create Trigger (Figure 1-13).
Now, type sms (Figure 1-15) and choose it as an action channel.
Click on Activate to activate the SMS channel. You will be asked to enter a valid cellular phone number capable of receiving SMS messages (Figure 1-16). Click on Send PIN to have the number sent to your phone. Once you receive the PIN, enter it into the website, click on Activate, and then click on Done below the SMS Activated! message. Then click on Continue to the next step.
Now click on Send me an SMS under the Choose your Action section. You can now edit the message you will receive when someone rings the doorbell. In Figure 1-17, we see an example of a custom SMS message that will result in the text “Hey, someone pressed me! -Sincerely, SMS_Door_Bell.”
Click on Create Action, pick a title for the recipe, and then click on Create Recipe. That’s it—our recipe is active!
Oops, We Forgot the Button!
Wait a second. We forgot to add the button module to represent the doorbell. Oops! Our project isn’t very complete if there isn’t an actual button to represent a doorbell. But fear not: instances like these are the reason that littleBits is such an elegant prototyping platform. We are going to add in a button without losing any of the work we have already done.
If you look closely at the button module (Figure 1-3), you will see that it has a right arrow on its top. This means that the module to its right will receive a trigger when the button is pressed. Therefore, the button module needs to be on the left side of our cloudBit.
Pull the cloudBit away from the USB power module; this will power it off. Connect the button module to the power module, and then connect the cloudBit on the right side of the button module. The project should now look like Figure 1-18.
Press the button and you should get an SMS on your cell phone, as shown in Figure 1-19.
Even though we forgot to add in the button module initially, our oversight was easy to fix by simply plugging in the module afterward. We didn’t have to take any additional steps with reconfiguring cloudBit or reprogramming our recipe. This makes littleBits a powerful prototyping platform.
We now have a working prototype of a wireless doorbell that sends an SMS message when pressed. Now is a good time for us to pause and think about security. An IoT product that is susceptible to vulnerabilities can put potential customers at risk and also taint the perception of the manufacturing company. To approach our analysis, we will first go through security issues we have identified in other IoT products and see if our prototype is vulnerable to similar issues. We will then discuss additional security mechanisms that can be implemented to further secure the prototype and leverage existing IoT security frameworks to make sure our approach is comprehensive.
WiFi Insecurity, Albeit Brief
One of the first things we did to create a working prototype was to configure the cloudBit to hop onto our home WiFi network by supplying credentials to the network (Figure 1-11). The finished product will also require the customers to input their WiFi credentials in a similar fashion. It is therefore important for us to understand the potential abuse cases for this design.
We had to join the temporary WiFi network exposed by our cloudBit to configure it. Once on the cloudBit network, our browser connected to the cloudBit web server (with an IP address of 10.0.0.1) and requested the resource http://10.0.0.1/scan-wifi, the output of which is shown in Figure 1-20.
Once the browser obtains the list of networks from the cloudBit, it renders it to the user (Figure 1-10). When the user selects his home network and enters his credentials (Figure 1-11), the web browser sends the following HTTP request to the cloudBit on the local network:
POST /set-wifi/ HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2)
AppleWebKit/600.3.18 (KHTML, like Gecko) Version/8.0.3 Safari/600.3.18
After sending the response, the cloudBit will hop on the TouchOfClass WiFi network using the credential topsecretpassword. This lets the cloudBit reach the littleBits cloud infrastructure, allowing us to control the module from the http://control.littlebitscloud.cc website.
The security issue to keep in mind here is that the temporary WiFi network exposed by the cloudBit is not secured or encrypted. This means that anyone within range of the temporary network can also join the network. Furthermore, the POST /set-wifi/ request to the cloudBit is not encrypted using TLS or any other mechanism, allowing a rogue party that has joined the network to easily capture the user’s home network WiFi credentials.
The risk of this issue is relatively low, since the attacker has to be within the vicinity of the network and has to act within the window of time when the user configures his cloudBit. However, as we have discussed in previous chapters, any computing device that has been remotely compromised and is within vicinity can continuously scan for temporary cloudBit WiFi networks and hop onto them to capture credentials—that is, an attacker with access to a computing device infected with malware can automate this process by building the attack vector into the malware code. As IoT devices multiply in our society, malware authors are going to increasingly design their malware to take advantage of time windows such as these. Malware may infect a particular device and rely on an already established WiFi connection, the password to which may be stored in encrypted form. Therefore, obtaining the clear-text password to the WiFi network can provide an added advantage to remote attackers.
Sneaking in Command Execution
In not available, we discussed various scenarios in which access to the filesystem can help tinkerers and potential malicious entities discover how to bypass security controls and uncover potential vulnerabilities. The cloudBit runs the Linux operating system and includes a Secure Digital (SD) card that contains the filesystem. In this section, we will attempt to mount this card and take a look at what’s inside.
Power off the project by separating the cloudBit from the button module. Carefully remove the micro SD card implanted in the cloudBit, and then insert the card into a laptop equipped with a micro SD card reader. The card should mount automatically in most modern distributions. In OS X, you will need to install OSXFuse and fuse-ext2, after which the disk should automatically mount in /Volumes/littleRoot/.
It’s a good idea to create a list of files that you can scroll through. Run the following command in OS X:
$ ls -lR /Volumes/littleRoot/* ~/Desktop/littleRoot.txt
Then go through ~/Desktop/littleRoot.txt to look for interesting files, such as etc/wpa_supplicant/cloudbit.conf:
Here we have a situation in which the WiFi password is stored in clear text. What’s more, the pre-shared key (PSK) hash, calculated using the ssid and password, is also present. This creates a situation in which anyone with access to the doorbell can easily access the filesystem and gain access to the customer’s home WiFi network. Stronger controls that store the key in a secure hardware processor (such as the Apple A7 processor) would be a better solution. Even though the product at hand is a mere doorbell, the security of the user’s entire internal network could be put at risk by storing credentials such as the WiFi password in the clear. Using the littleBits platform for prototyping is a good way to uncover issues like this, so you can start to figure out your security requirements early on.
The /srv/http directory contains files for the web server that is activated when the cloudBit is in setup mode. We can put executable scripts in this directory to have commands run for us on the live instance of the cloudBit. Let’s give it a shot:
[bash]$ cd /Volumes/littleRoot/srv/http/set-wifi
Now put the following file (ps_netstat.cgi) into this directory:
Now unmount the micro SD card and insert it back into the cloudBit. Once the cloudBit powers on, hold down the setup button for a few seconds until the LED light blinks blue, and then let go; the light will stop blinking. Join the temporary littleBits_Cloud_… WiFi network and browse to http://10.0.0.1/set-wifi/shell.cgi. You will see the output from the ps and netstat commands, as shown in Figure 1-21!
This is a crafty way to execute live commands on the cloudBit to analyze more details about the device’s operation at runtime. The designers of the cloudBit do not want people to directly execute local commands on it, since that may destroy the integrity of the product. As such, it does not come with any way to remotely log into the Linux system running on it. In this case, however, we have found a way to circumvent their intentions and execute local commands. This is yet another example of the types of security issues we need to think about during the prototyping stage: is it important that external parties be unable to tinker with the live system? In this case, the issue is that the filesystem is accessible by mounting the memory card, which in turn allows anyone with access to the product to analyze the system in real time. The solution here is not to impose obscurity in order to disallow such tampering, but to further protect the product from a remote vulnerability in the web server or other services that can lead to compromise of not just the doorbell, but also other important IoT devices (such as lighting and door locks) that may share the local network.
The AccessToken can be used to interact with the cloudBit remotely. For example, the link in the form of https://api-http.littlebitscloud.cc/devices/DeviceID/input?access_token=AccessToken&token_type=bearer displays the status of the cloudBit. This resource uses the cloudBit API to query the status of the cloudBit every second. The first sequence of output shown in Figure 1-23 lists the value of percent as 100 because the button attached to the cloudBit was pressed, causing positive input to be sent to the cloudBit. The second sequence lists the value as 0, indicating that the button is not being pressed anymore.
We needed both the DeviceID and the AccessToken to query information about the cloudBit from the API. However, if we only knew the AccessToken, we could obtain the DeviceID by querying the devices associated with the user in this way:
The value of id returned from the curl command is the DeviceID that is associated with the user’s account. This proves that the secrecy of the value of the AccessToken ultimately guards access to the cloudBit. The cloudBit API advertises no way for developers to request a new AccessToken. Without this functionality, the provided AccessToken will persist forever. Given that the littleBits and cloudBit platforms are not intended for production use, there is low risk with regard to the prototype itself. However, designers should bake in methods for the final product to be able to expire and refresh the AccessToken. This will prevent the token from persisting forever, which increases the chances that it can be compromised.
Let’s add a buzzer module to our prototype. As shown in Figure 1-24, we attach the buzzer module by snapping it into the right side of the cloudBit. Now our prototype will be able to send an SMS message when the button is pressed as well as activate a local audio buzzer, just like a traditional doorbell. This further illustrates how powerful the littleBits prototyping platform is: designers can add and change functionality based on new ideas in a matter of seconds.
In order for our prototype to send an SMS message and activate the buzzer, we have to create an extra IFTTT recipe that will need to select the cloudBit for both the input and output sections (Figure 1-25).
The final product may include a smartphone app that will have to store the token to the local filesystem. If the app or the phone is compromised in any way, attackers can gain access to the token. Another scenario could be the compromise of all issued AccessToken values that are stored on the littleBits servers. This could allow an attacker to control all cloudBit modules that are online. Once the initial prototype is complete, thinking through such scenarios will help designers understand the importance of implementing mechanisms for tokens to expire and be refreshed. If a malicious entity gains access to the token, a simple command such as the following will cause the prototype’s buzzer to sound infinitely in a screeching tone:
Imagine waking up in the middle of the night with your doorbell screeching at you nonstop. Some may have the courage to immediately check who is at the front door, only to be further confused upon realizing there is no one there but the doorbell is still ringing. These are the types of use cases—and abuse cases—designers need to begin to understand early on in the prototyping process so that every subsequent iteration of their product lowers the probability of that product being abused to harm or inconvenience their customers.
Beware of Hardware Debug Interfaces
IoT devices often include hardware ports that are useful for debugging; they require physical access to the device. Tinkerers and security researchers have found that it is often possible to change the functionality of devices by using physical debug interfaces to modify the firmware. It is also often possible to uncover stored secrets such as encryption keys that may be stored on the device. If the same encryption key is used on all other devices of the same type, attackers can use this information to compromise the integrity of other devices by having one-time access to a candidate device and extracting the information.
Universal Asynchronous Receiver Transmitter (UART) chips are commonly found on microcontrollers and often leveraged to implement debug functionality. They use serial (one bit at a time at a specified rate) communication to transmit information between an attached client device and the microcontroller. The first order of business is to locate the VCC (power), GND (ground), RX (receive), and TX (transmit) pins, as shown in Figure 1-26.
Along with visual inspection, a multimeter is used to measure voltages to identify UART pins. The multimeter should be set to continuity mode, which is a feature present in most multimeters. This mode lets us test the resistance between two points on the board. If there is low resistance, it means that the two points are connected electrically and the multimeter will emit a tone. If the two points have high resistance between them, it means that the circuit is open and the multimeter will not emit a tone.
To identify the ground pin, find an area on the board that has metal shielding (this appears as a metal cover over parts of the board) and place the black-colored multimeter probe on it. Next, place the red probe on a pin that you suspect is the ground pin. If the multimeter emits a tone, it means that the pin is connected to ground and so it is the ground pin. The UART exposes four or more pins, so look for areas on the board that have four or more pins next to one another.
If the red probe is placed on the power pin, the multimeter will emit a short beep rather than a continuous tone. It is useful to identify the power pin, so we know it is not a transmit or receive pin.
A transmit pin will cause the multimeter to show a voltage value of around 3.3V, which is common for the UART. As the transmit pin transmits data (often when the device has been powered on and it is booting firmware), the voltage drops to 0V and then back to 3.3V. The multimeter will average the sampled voltage, which will dip down when data is being transmitted, especially when the device has just been powered on.
Identifying the receive pin is more difficult: the best course of action is to identify it by eliminating the ground, power, and transmit pins.
In order to communicate with the UART, a simple UART-to-USB adapter can be used. The ground pin on the board should be connected to the ground of the adapter, while the transmit and receive pins should be switched.
A simple communications program such as Minicomcan be used to connect and interact with the UART. However, we will have to tell Minicom exactly what baud rate to use. (Baud is the unit for how many bits are transferred in a second.) The baudrate tool can be used to automatically detect the baud rate and connect to the device.
The “Reverse Engineering Serial Ports” tutorial walks through how to locate UART pins and connect to the UART of a hardware device in order to gain access to the system shell on the device.
The Exploitee.rs website is a great resource that provides photos of identified UART pins and baud rates for many popular devices. This information can be used to obtain UART access to configure the devices, obtain firmware, and update firmware on devices in order to insert additional features or bypass security controls and limitations designed by the manufacturer.
The cloudBit module website states: “We’ve left pads on the bottom of the board so that you can connect to the cloudBit’s serial console using 3.3V UART (8-N-1, 115,200 baud) and poke around.” Readers who have the UART hardware and software tools outlined in this chapter can use the baud settings listed (8-N-1, 115,200 baud) to tinker with their cloudBit’s UART interface.
Another popular hardware debug interface is implemented by the Joint Test Action Group (JTAG). There are various JTAG pin combinations. Most JTAG interfaces have five basic pins: TDI (Test Data In), TDO (Test Data Out), TCK (Test Clock), TMS (Test Mode Select), and TRST (Test Reset). Identifying these pins can be tedious, but the popular JTAGulator hardware tool can automatically identify them. Joe Grand, the creator of the tool, explains how to use JTAGulator in a YouTube video.
The LIFXlightbulbs were found to use the JTAG interface by security researchers who used the interface to uncover a security vulnerability. Unlike the Philips hue system, the LIFX architecture does not require a hub. Instead, one lightbulb is connected to the WiFi network and is deemed the master bulb. Other bulbs connect to the master bulb using the 6LoWPAN standard (the name stands for IPv6 over Low Power Wireless Personal Area Networks). This allows the bulbs to use low power, especially when not illuminated, and to extend their network via a mesh network to reach bulbs past the range of WiFi.
The researchers used the JTAG interface to obtain the firmware stored on the lightbulbs. This firmware contained a global encryption key that was the same in all LIFX lightbulbs. This symmetric encryption key is utilized to encrypt and decrypt communication between all lightbulbs from this company. Armed with this information, the researchers demonstrated that they could inject arbitrary instructions into any LIFX mesh network, allowing them to command the lights. In this case, the attacker would have to be within 30 meters of the LIFX bulbs, since the attack is conducted on the local network.
Interfaces such as UART and JTAG can be used to uncover security issues such as global shared encryption keys, which are a bad idea since attackers can exploit the architecture once the key is compromised. In the case of our cloudBit prototype, we came across an issue in which the local WiFi network was stored in clear text on disk. Stored secrets in hardware platforms are a common issue, and attackers are bound to attempt to uncover them. In order to help promote better hardware security, the Trusted Computing Group (TCG) has published and continues to update the Trusted Platform Module (TPM)standard. The specifications provided by TCG allow hardware designers to construct a secure hardware processor that can offer great reliability in storing secrets such as passwords and encryption keys.
As designers and architects come closer to validating a proposed version of their device past the initial prototyping stage, hardware security—including the availability of functionality via UART and JTAG—becomes a concern. It should be assumed that ethical security researchers as well as attackers will tinker with debug access on hardware and will eventually gain access to the interface. One important item to remember is that in the case of LIFX, the issue wasn’t that the JTAG interface exposed the encryption key, but the fact that using the same encryption key in every lightbulb is an insecure design. IoT product manufacturers should also think through secrets (such as WiFi credentials) that their devices must protect responsibly. Standards and processors that implement TPM can and should be used to enable hardware to store secrets more reliably so that they are not present in the firmware or accessible using hardware debug interfaces.
Abuse Cases in the Context of Threat Agents
Coming up with potential abuse cases requires context with regard to the possible threat agents who may act on vulnerabilities. A threat agent is an individual or a group of people who may want to exploit vulnerabilities for personal gain. Threat agents have differing levels of skills, resources, and intentions. For example, a gang of attackers with financial backing may employ persistent and sophisticated tactics against specific assets, whereas a disgruntled employee may leverage confidential knowledge to cause a disruption in service or loss of proprietary information. The following sections contain examples of popular threat agents.
Nation-States, Including the NSA
Nation-state attackers are groups of highly sophisticated attackers that are funded by their governments. Given the amount of financial backing and support available to them, they are highly persistent and will continuously attempt to penetrate their target until they are successful. They employ tactics that are difficult to detect, and they are determined to maintain access to the compromised infrastructure for long periods of time. This type of threat agent came to mainstream attention after the set of attacks carried out against major corporations in late 2009 that came to be named Operation Aurora. The targets included major organizations such as Google, Adobe Systems, Juniper Networks, Rackspace, Yahoo!, Symantec, Northrop Grumman, Morgan Stanley, and Dow Chemical. The Chinese government was blamed for the attack, while the Chinese government in turn blamed the US for indulging in conspiracy.
The US National Security Agency (NSA) is also a candidate for this category of threat agent. Classified information leaked by the famous whistleblower Edward Snowdendemonstrated extensive efforts by the NSA to spy on US citizens as well as to launch targeted attacks against foreign targets. The ethical implications of Snowden leaking the information may be debatable, but the information he leaked helped the world realize the lengths to which a government agency can go to spy on citizens and launch cyberattacks.
In February 2015, researchers from Kaspersky Labs disclosed a powerful strain of malware that could install a backdoor on the firmware of hard drives manufactured by companies like Seagate, Toshiba, and Western Digital. This backdoor is hard to detect since it intercepts every attempt to read the hard drive to find the malicious code. The researchers noted that portions of the code in the backdoor are similar to modules found in the design of Stuxnet. They further noted that infected machines were found in countries that are common US spying targets, such as China, Iran, Pakistan, and Russia.
The increased popularity of IoT devices will definitely be an area of interest to the organizations funded by nation-states. They are known to want to steal trade secrets and obtain access to critical facilities. They are likely to attempt to compromise entire platforms supporting IoT infrastructure by targeting supply chains to inject malicious code in hardware or software, or by remotely targeting the devices that offer Internet connectivity.
While terrorists are known to focus on physical attacks to promote terror, it is only a matter of time before they increasingly begin to leverage vulnerabilities in infrastructure accessible to the Internet. One recent example of this was the 2013 attack against the New York Times, Twitter, and the Huffington Post by supporters of the Syrian government called the Syrian Electronic Army. The attackers were able to compromise the credentials used to set up DNS records for the domain names of the websites to cause disruption of service.
Cyberterrorists will be drawn to the notion of leveraging IoT devices to promote fear and disruption. Targeted attacks are likely to focus on individuals or families who are well known so that the attacks will obtain maximum news coverage, thereby promoting fear. Life-sustaining health devices such as pacemakers are increasingly configurable remotely and have been demonstrated to be vulnerable to attacks.
The emergence of of smart cities, where similar technologies are used in tandem to reduce resource consumption and promote well-being, are also going to be of interest to this group. High-rise condominiums and homes that support the concept of smart cities are likely to use the same hardware products to increase efficiency and interoperability. This means that a known vulnerability in a remotely accessible IoT device can be leveraged across the city. Such scenarios are likely to be abused by these threat agents to promote terror by causing blackouts, locking or unlocking doors, controlling cars, and making fire alarms go off. It is therefore crucial for designers to think through the motives of possible agents who could be leveraging their devices.
For example, it is clear how important it is for IoT-based lighting system architects to consider ways in which their systems might be targeted and used by malicious agents and to design security proactively.
Private criminal organizations have been known to be quite resourceful and sophisticated. The primary motive of this type of agent is financial gain by stealing money or intellectual property (which can be sold to the victim’s competitors).
In February 2015, the security firm Kaspersky announced that it had uncovered criminal activity by an organization that was able to steal $1 billion from banks around the world by infecting computers with malware. Banks targeted included ones in Russia, the US, Germany, China, Ukraine, Canada, Hong Kong, Taiwan, Romania, France, Spain, Norway, India, the United Kingdom, Poland, Pakistan, Nepal, Morocco, Iceland, Ireland, the Czech Republic, Switzerland, Brazil, Bulgaria, and Australia. The average attack yielded the criminals $10 million. The thieves were even able to seize control of banks’ ATMs and order them to dispense cash at a predetermined time.
Connected devices are fantastic targets for private criminal organizations because they can help them gain a foothold into the target’s internal network. This access can be further leveraged to attack workstations on the internal network to obtain access to intellectual property and financial data. For example, attackers have been able to compromise home refrigerators that have Internet connectivity. The attackers then used the compromised refrigerators to send out malicious emails to other potential victims to grow their botnet. The term thingbotis gaining popularity to describe botnets that include IoT devices that can be leveraged to attack organizations and targeted individuals.
Disgruntled or Nosy Employees
This group includes employees of an organization who may be disgruntled, nosy, or whistleblowers. It is always easy to obtain access to devices that are on an internal network that one already has access to. Many organizations do not do a good job of designing role-based access controls that restrict employees’ access to company information, given the added cost of implementing and maintaining such controls. And in many cases, disgruntled employees already have legitimate access to sensitive data based on their duties.
The data leak surrounding the 2014 attack on Sony Pictures caused the company to halt the theater release of the movie The Interviewbecause the attackers threatened physical damage to movie theaters as well as leakage of additional data. Initially, the attack was attributed to North Korea since the plot of the comedy movie included the assassination of leader Kim Jong-un. However, later speculation by industry experts has lent credibility to the notion that the attack was probably carried out by disgruntled individuals who were former employees and knew the weaknesses of the company’s network infrastructure, which allowed them to access company data. The attackers obtained and released copies of executive emails, including the one pictured inFigure 1-27. In this email, a Sony executive and a prominent film producer exchanged messages about President Obama that are racist in nature. Both the executives later issued a public apology for engaging in the conversation.
Actions committed by certain threat agents can lead to the compromise of personal or corporate reputations, which in turn can lead to negative effects on the careers of exposed individuals who have been targeted. Loss of brand reputation can also lead to loss of consumer confidence that can have a long-term and sustained effect on business.
IoT manufacturers must think through how disgruntled employees with access to customer information can put confidential information at risk. Employees involved in customer support often have access to customer accounts so that they are able to troubleshoot situations to serve support requests. Customer support agents in the case of an Internet-connected door lock company are likely to be able to lock or unlock doors remotely. This could make them attractive targets for a social engineering attack, whereby the support representative may be tricked into opening a door lock belonging to someone else. This situation could also be abused by disgruntled agents who could cause havoc by having all door locks that are online unlock, thereby flooding the customer support lines, damaging the company’s reputation, and putting customers at physical risk.
Employees who are part of the design and supply chain processes should only be given access that pertains to their role. The supply chain process should be securely engineered to make sure employees are not able to tamper with software or hardware to install spyware or backdoor programs. For example, an employee with access to source code that is used to push out firmware updates for a baby monitor might try to sneak in a backdoor account that could be leveraged later to control and gain access to every baby monitor produced by the company.
Abuse case analysis for this category of threat agent should include third-party contractors and partners as well. It is important for IoT product designers to think through potential abuse cases in the context of threat agents so that they are able to build controls into the devices, as well as the backend infrastructure and processes supporting the products.
Groups and individuals in this category—a blend of the words hack and activist—leverage weaknesses in technology to promote a political agenda, often related to human rights and freedom of information. The group known as Anonymous is one of the best examples of hacktivists. They define themselves as “a very loose and decentralized command structure that operates on ideas rather than directive.” The group’s name originated from the 4chan website, where users share various categories of images with one another. The website doesn’t require registration, and users who post messages are tagged with the label “Anonymous.”
In 2008, Anonymous launched Project Chanology, which was an effort to retaliate against the Church of Scientology for censorship. A private video starring actor Tom Cruise discussing the virtues of Scientology was posted online by the Gawker website. The video was initially hosted on YouTube, and the Church of Scientology sent a copyright infringement notice to have it removed. Anonymous considered this unfair censorship and launched various denial of service attacks against Scientology websites in protest. They also prank-called the church and sent in fax messages with black paper to drain the ink from the church’s fax machines.
In November 2010, WikiLeaks released hundreds of thousands of leaked US diplomatic cables. Worried about possible legal threats from the US government, Amazon pulled the plug on hosting the WikiLeaks website. PayPal, MasterCard, and Visa also cut off service to the organization. As a result, members of Anonymous announced Operation Avenge Assange in support of Julian Assange, founder of WikiLeaks. The group launched denial of service attacks against PayPal, MasterCard, and Visa, but could not gather enough resources to bring down the Amazon infrastructure.
In early 2011, Aaron Barr, the CEO of the cybersecurity company HBGary Federal, claimed to have used social media platforms such as Facebook and Twitter to find out the actual identities of some members of Anonymous. In response, members of Anonymous exploited a SQL injection vulnerability on one of HBGary’s systems and obtained full-blown access. They compromised Barr’s Twitter account and even claimed to have remotely wiped his iPad. They also released thousands of confidential emails that contained internal communications as well as details of HBGary’s customers. This led to the resignation of Barr and the closure of HBGary Federal.
Hacktivist activity is often centered on disrupting businesses and targeting individuals to gain media coverage and public attention. As such, IoT devices installed in the workplace and at home will be lucrative targets for these threat agents. Homes of specific individuals will be targeted to compromise physical safety by abusing potential vulnerabilities in connected door locks and lighting systems. IoT devices such as baby monitors and smart TVs are also likely to be targeted to obtain and leak confidential information. Both consumers and designers of connected devices need to think through risks posed by hacktivists to make sure the proper security controls are engineered and configured.
Vandals have been the best-known group of threat agents since the dawn of the Internet. They aren’t interested in financial gain. Their primary objective is simply to prove that a system can be compromised, and they often like to take credit for demonstrating it. Even though their intention is not to cause harm beyond obtaining a brief moment of fame, the outcomes of their actions often do cost individuals and corporations money and result in distress and loss of reputation.
The vandals also were able to compromise Tesla’s Twitter account and posted inappropriate tweets, including some promising free cars (Figure 1-29).
The group compromised the Twitter account of Elon Musk (CEO of Tesla) as well and tweeted messages from his account (Figure 1-30).
In response, Tesla issued the following press release:
This case is under investigation, here’s what we know: Posing as a Tesla employee, somebody called AT&T customer support and had them forward calls to an illegitimate phone number. The impostor then contacted the domain registrar company that hosts teslamotors.com, Network Solutions. Using the forwarded number, the imposter added a bogus email address to the Tesla domain admin account. The impostor then reset the password of the domain admin account, routed most of the website traffic to a spoof website and temporarily gained access to Tesla’s and Elon’s Twitter accounts.
Some customers may have noticed temporary changes to www.teslamotors.com on their browsers or experienced difficulty when using our mobile app to access Model S. Both were due to teslamotors.com being re-routed.
Our corporate network, cars and customer database remained secure throughout the incident. We have restored everything back to normal. We are working with AT&T, Network Solutions, and federal authorities to further investigate and take all necessary actions to make sure this never happens again.
Most likely, the attackers were able to gain access to the legitimate Twitter accounts of Tesla Motors and Elon Musk by redirecting email bound for the teslamotors.com domain and resetting the Twitter passwords. Imagine how much other information they could have (and probably did) capture from redirecting corporate emails bound to Tesla.
While the attack was in progress, according to messages on the company’s message board (Figure 1-31), Tesla car owners could not use the company’s iOS app. The app (discussed in Chapter 6) also allows Tesla Model S owners to locate, lock, unlock, and even start their cars using their iPhones without having to have their key fobs. Given the increasing popularity of and reliance on smartphones, in the future many car owners are going to be increasingly dependent on their phones to unlock and start their cars rather than carrying key fobs, so the potential impact of such a lockout will only grow.
The ability of these attackers to gain access to the entire domain of teslamotors.com using a simple social engineering attack (posing as a company employee) demonstrates how easy it can be to disrupt the security of major corporations. Instead of vandalizing the website and Twitter accounts, the attackers could have surreptitiously maintained access for a prolonged period to steal intellectual property and financial data. The type of overt vandalism they engaged in is bound to receive an immediate response from the security operations personnel at the company that is being attacked, causing the loophole to be closed. Attackers who want to cause severe financial and business damage are unlikely to take such obvious actions, because they want to maintain access for as long as possible. Vandals, however, thrive on media attention and feel good about being able to demonstrate loopholes. Their motives may be petty, but the companies they target pay the price of brand damage nonetheless.
In our discussion of the Tesla Model S in Chapter 6, we saw that these cars use their always-on 3G cellular connections to receive software updates that can affect physical functionality. Current and potential car owners may consider other car manufacturers after having read about this attack in the media, questioning Tesla’s ability to protect its infrastructure from simple social engineering attacks such as these. They might also be concerned about danger to their physical safety should attackers abuse situations like this to affect the functionality of their cars, possibly resulting in accidents. Competitors to Tesla may use this situation to lure car buyers toward their products.
From the perspective of the IoT, cloud platforms that are relied upon by endpoint devices are likely targets for vandals. Imagine if attackers were able to social engineer the domain registrar for the SmartThings platform we looked at in Chapter 4 to reroute traffic through their systems. A compromise such as this could allow the vandals to have all smoke detector alarms powered by SmartThings to go off at the same time. Another scenario could involve an audio file being broadcast on a particular manufacturer’s baby monitors, all around the world. IoT vendors consider possible attack vectors that might be exploited by these threat agents and make sure they have thought through monitoring requirements that can help them detect attacks against their cloud platforms and against other partners (such as domain registrars) they rely upon.
According to the 2013 Youth Risk Behavior Surveillance System survey, 15 percent of high school students in the US had been bullied over the course of the previous year. Given the prevalence of technology in the lives of kids today, cyberbullying can happen at any time and be perpetrated by anyone. It can be difficult to trace the source of such bullying since messages and images can be posted on social media sites anonymously or using a fake identity. Cyberbullying can lead to lower self esteem and health problems for the victim.
Various government agencies have come together to create a website against bullying, including cyberbullying, to promote awareness of the issue and to provide a mechanism for victims to seek help:
In one tragic case, a boy named Ryan Patrick Halligan hanged himself at the age of 13 as a result of cyberbullying. Ryan was bullied at school because of his learning disabilities and was teased about an ongoing rumor that he was gay. He became friends with a girl who expressed interest in him via instant messaging. She later told him he was a “loser” in front of a group of kids at school. Ryan then began communicating with a friend on websites, and they exchanged ideas about how to commit suicide based on information they found online. Ryan sent a message to this friend stating that he had been seriously contemplating suicide, and killed himself two weeks later. Ryan’s father lobbied for legislation in the state of Vermont and successfully persuaded the state government to enact a Bullying Prevention Policy Law and a Suicide Prevention Law (Act 114). Other states have also pushed to enact laws against cyberbullying based on Ryan’s story.
Unfortunately, there are many other stories like Ryan Halligan’s, and the prominence of cyberbullying is bound to increase given the amount of access children have to mobile devices and social media platforms. The cases we see now usually leverage laptops, mobile phones, email, instant messaging, and Facebook. However, IoT devices such as lighting, connected door locks, and security systems can and doubtless will be leveraged by perpetrators to commit acts of bullying. From the consumer angle, parents will have to become aware of how connected devices in their homes can be abused and do their best to monitor their kids’ behavior and access to these devices.
Product manufacturers should also think through possible ways they can allow parents to configure devices that are used by kids to alert them of suspicious activity. For example, we’ve seen how IoT door locks can allow users to grant others access to their homes via a companion iPhone app. Kids who use their iPhones to unlock their doors when they return from school should not be allowed to give others access to their homes. Access to certain IoT devices can also be limited based on time and the GPS location of children with smartphones that can track this information.
Ultimately, technology can put children at risk and promote acts such as bullying, but it can also be leveraged to monitor and promote safety. These are important issues that designers of products should think through to ensure that they are helping kids to lead safer and healthier lives, while taking into account real threats such as cyberbullying.
There have been many unfortunate cases of children being “groomed” and sexually abused by predators who use online chat forums and instant messaging to find and communicate with minors. Similar to bullies, these abusers are bound to leverage technology that will include IoT devices to get in touch with and communicate with minors.
Device manufacturers have a profound responsibility to implement and encourage the use of parental control features in products where appropriate so that children are protected from suspicious activity, as well as mechanisms for the parents to be alerted when such activity is detected. One example of this is the ability of parents to monitor and control applications that are installed on Smart TVs that may allow children to communicate with strangers. As with the other threat agents, the designers of products should think through who their target audience may be and embed methods for parents to lock down functionality if their products are likely to be used by minors.
Bug Bounty Programs
Tinkerers and security researchers often uncover security vulnerabilities by investing their own time and resources. Sometimes vulnerabilities are discovered by accident, yet in most situations the researchers get a thrill out of uncovering security lapses. In many cases, the researchers want to do the right thing and report the issues they discover to the product vendors. Some companies have done a good job of advertising how researchers can contact them to report security vulnerabilities, but many companies do not advertise how they wish security issues to be reported to them. This often causes researchers to contact customer support staff, who may not be equipped to route the information to the right individuals.
Companies such as Microsoft have set up bug bounty programs that pay researchers up to $100,000 USD depending upon the severity of the issues they uncover. The case for such high rewards is that the organizations would have to pay staff or contractors the same amount or more to do the sophisticated research done by the individuals who submit information to bug bounty programs. Categorizing the awards based on severity easily aligns with the goal of lowering the risk for the company and its shareholders.
There are also companies such as HackerOne (Figure 1-32) that facilitate and coordinate bug bounty programs. A company can join the program and have researchers report security issues using the HackerOne website. HackerOne claims that it will not look at the actual vulnerability being reported, since that is private communication between the researcher reporting the issue and the company being reported to. Once the issue is resolved, HackerOne can help the company disclose the vulnerability publicly.
It is terribly important that IoT vendors clearly establish a mechanism for researchers to submit findings of vulnerabilities. Without a clear process, there is little inducement for researchers to spend time reporting issues they uncover. Even though not all companies pay bounties, it makes business sense to do so because it offers an incentive for researchers to discover any vulnerabilities in a company’s products before malicious attackers do and lowers the probability of the issues becoming public before they are fixed—which could put customer information, safety, and the revenue of the business at risk.
The littleBits platform that we looked at at the beginning of this chapter let us quickly and easily design our prototype SMS doorbell. We were able to leverage the IFTTT platform to gain the ability for our device to send SMS messages. Within moments of completing our prototype, we were able to uncover security issues relating to WiFi security, command execution on the device, and the persistence of the access token used by the cloudBit module to authenticate and authorize queries and commands. Even though the littleBits platform is only designed to help with initial prototyping, it is also a good way to uncover security concerns early on. As we’ve learned, it is easier and cheaper to implement countermeasures early in the design process than it is to try to bake security in at a later stage.
We also looked at ways people could potentially tamper with hardware-based debug interfaces to obtain access to functionality that may compromise the integrity or confidentiality of a product. These situations can put users of the entire product line at risk, as in the case of the LIFX lighting system that exposed a universal symmetric encryption key found in all of the company’s devices.
As we saw, even at the prototyping stage it is extremely important to think through how different threat agents may want to abuse vulnerabilities. For example, a disgruntled employee working in customer support with access to the locations of connected cars may want to expose GPS data of famous celebrities who own those cars, to tarnish the reputation of the employer. On the other hand, hacktivists may want to target IoT devices owned by specific individuals who are against their political agendas, to cause disruption in services or to expose private information that may embarrass the targets.
The architecture and design of connected devices are also bound to be of interest to tinkerers and security researchers. It is vital for IoT manufacturers to provide a clearly advertised process for individuals to report security issues, and often a useful policy to offer rewards to be paid upon verification. In most cases, the cost of the reward is less than the price companies would have to pay in terms of revenue losses arising from the negative effects on their brands and the loss of their customers’ privacy and trust.