Secure prototyping with littleBits and 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.

After signing up for an account, we can name our cloudBit module by going to http://control.littlebitscloud.cc (Figure 1-6).

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).

We now see the screen shown in Figure 1-8.

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 cloud infrastructure.

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).

Next, click on “that” (Figure 1-14).

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.

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
Host: 10.0.0.1
Accept: */*
Proxy-Connection: keep-alive
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Origin: http://control.littlebitscloud.cc
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
Connection: keep-alive
Content-Length: 92
Referer: http://control.littlebitscloud.cc/
DNT: 1

ssid=TOUCHOFCLASS&mac=771FA1263FEC&security=wpa2&encryption=on
&password=topsecretpassword

Here is the response from the cloudBit:

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Authorization, Content-Type, If-None-Match
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: WWW-Authenticate, Server-Authorization
Access-Control-Max-Age: 86400
Content-Type: application/json; charset=utf-8
Date: Sun, 08 Mar 2015 05:34:07 GMT
Server: lighttpd/1.4.35
Content-Length: 20

{ "success": true }

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.

One solution here is to embed a unique private key in each instance of the product, which may be expensive. Another option is to have a serial number printed on the device that is used as a private key to encrypt the actual WiFi password. The user will have to supply the WiFi password as well as the device’s serial number, which will be encrypted by the web browser (using JavaScript) and sent to the cloudBit, which can then decrypt it using its own serial number as the key. There are various ways encryption can lower the risk of this issue. The important thing is for product manufacturers to acknowledge the potential risk, and the potential consequences, and make informed business decisions about on implementing security mechanisms to lower the risk to customers.

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:

network={
        ssid="TOUCHOFCLASS"
        #psk="youcann0tguessme!"
        psk=3f6380509ca89b4c5506fd39e7a3a8b2d5cda338b51accbad1f1850fefbabd47
        key_mgmt=WPA-PSK
}

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:

#!/bin/bash

echo "Content-type: text/html"
echo ""
echo ""

echo '<html>'

echo '<body>'

echo '<pre>'

ps -aux

echo "<br><br><br>"

netstat -na


echo '</pre>'

echo '</body>'
echo '</html>'

And set the right permissions:

[bash] chown 33:_appstore ps_netstat.cgi
[bash] chmod 755 ps_netstat.cgi

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.

One Token to Rule them All

Once the cloudBit is configured, you can browse to http://control.littlebitscloud.cc and click on Settings to get the value of the DeviceID and the AccessToken that are assigned to your cloudBit (Figure 1-22).

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:

$ curl -i -XGET -H "Authorization: Bearer [AccessToken DELETED]" -H
"Accept: application/vnd.littlebits.v2+json"
https://api-http.littlebitscloud.cc/devices

HTTP/1.1 200 OK
accept-ranges: bytes
access-control-allow-headers: Authorization, Content-Type, If-None-Match
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: *
access-control-expose-headers: WWW-Authenticate, Server-Authorization
access-control-max-age: 86400
cache-control: no-cache
content-type: application/json; charset=utf-8
Date: Thu, 02 Apr 2015 04:51:49 GMT
Content-Length: 272
Connection: keep-alive

[{"label":"SMS_Door_Bell","id":"[DELETED]","user_id":[DELETED],"is_connected":
true,"ap":{"ssid":"TOUCHOFCLASS","mac":"[DELETED]","strength":"99","server_id"
:"DfhIt25l","socket_id":"F1PDVb2Il","status":"2"},"subscriptions":[],
"subscribers":[],"input_interval_ms":750}]

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:

$ curl -i -XPOST -H "Authorization: Bearer [AccessToken DELETED]:
application/vnd.littlebits.v2+json"
https://api-http.littlebitscloud.cc/devices/[DeviceID DELETED]/output
-d percent=100 -d duration_ms=-1

HTTP/1.1 200 OK
access-control-allow-headers: Authorization, Content-Type, If-None-Match
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: *
access-control-expose-headers: WWW-Authenticate, Server-Authorization
access-control-max-age: 86400
cache-control: no-cache
content-type: application/json; charset=utf-8
Date: Thu, 02 Apr 2015 05:49:08 GMT
Content-Length: 16
Connection: keep-alive

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 Minicom can 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.

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 LIFX lightbulbs 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.

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 Snowden demonstrated 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.

Snowden confirmed that the NSA had worked with the government of Israel to write the famous Stuxnet worm. Stuxnet targeted the Iranian nuclear program by infecting computers and destroying roughly a fifth of Iran’s nuclear centrifuges by causing them to spin out of control. This is one of the most famous cyberweapons and is an example of how malware can cause physical damage to affect critical systems.

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.

Terrorists

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.

Criminal Organizations

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 thingbot is 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 Interview because 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 in Figure 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.

Hacktivists

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

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.

In April 2015, the website of Tesla Motors was vandalized to display the content shown in Figure 1-28 (courtesy of Reddit).

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.

Cyberbullies

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.

Predators

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.