Abusing the Internet of Things (2015)
Chapter 7. Secure Prototyping: littleBits and cloudBits
With the announcement of the iPhone in 2007, Apple single handedly disrupted the smart phone industry with the first generation version of the product. 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 smart phone 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 like in the case of Apple and Jobs, can also help us test different versions of our idea that may turn into a whole other form factor than what we originally planned.
There are numerous platforms and kits available that allow individuals to prototype ideas for IoT products at low 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 on the market. The littleBits module includes magnets that can be snapped together like Legos, which allows us to construct a prototype in mere seconds. We will use the cloudBit module to facilitate a simple 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 siumlate 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 effort required to secure an IoT device includes context such as how the product may be used as well as what type 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 cyber bullies 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 5 prototyping modules and the USB power module (Figure 7-1).
Figure 7-1. The USB power module
The USB power module powers the cloudBit projects. It can be powered using a USB cable or a wall adapter (Figure 7-2), both of which are included in the kit.
Figure 7-2. The USB power adapter and cable
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 the light in different places within the body of the prototype hardware or another object. The kit also includes the servo, a controllable motor that swings back and forth or continuously in a specific direction (clockwise or anti-clockwise). 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 7-3), as the name suggests, is a simple button that when pressed activates other modules.
Figure 7-3. The button module
The cloudBit module (Figure 7-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.
Figure 7-4. The cloudBit module
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 (https://littlebits.cc/signup) as shown in Figure 7-5.
Figure 7-5. Signing up for a littleBits account
After signing up for an account, we can name our cloudBit module by going to http://control.littlebitscloud.cc (Figure 7-6).
Figure 7-6. Naming our cloudBit module
Once we have named our module, we are asked to power on the cloudBit (Figure 7-7). To do that, 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 (example: Button). These modules in turn send signals to following modules that are colored green to indicate output. These modules perform an action, such as 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, such as 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 effect output modules that come after them.
Once the cloudBit is powered on, the light underneath the word “Status” on the module will start flashing. Press the button titled “Status light is flashing” Figure 7-7.
Figure 7-7. Booting up the cloudBit
We now see the screen shown in Figure 7-8.
Figure 7-8. Configuring cloudBit
Per the instructions, 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, click the “Blue light is steady” button shown in Figure 7-8. At this point, the cloudBit will start up it’s own WiFi network in the form of “littleBits_Cloud_…” that we can connect to (see Figure 7-9).
Figure 7-9. Connecting to the cloudBit WiFi network
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 7-10).
Figure 7-10. WiFi networks detected by cloudBit
At this point, we will select our home WiFi network, which is TouchOfClass in this example (see Figure 7-11).
Figure 7-11. Selecting WiFi network and entering credentials
After clicking on “Save”, we are asked to connect back to our home WiFi network (TouchOfClass). The cloudBits 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 the doorbell is pressed. We will use the IFTTT (If This Then That) platform first mentioned in Chapter 1 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. Activiating the channel will authorize IFTTT to interact with the cloudBit using the littleBits network (Figure 7-12).
Figure 7-12. Turning on the littleBits Channel on IFTTT
Now we are ready to create an IFTTT recipe that will send an SMS 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 from 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 7-6) from the list of authorized cloudBits, and then click on Create Trigger (Figure 7-13).
Figure 7-13. Selecting our cloudBit for the recipe
Next, click on “that” (Figure 7-14).
Figure 7-14. Click on “that” to select our cloudBit as the recipe trigger
Now, type SMS (Figure 7-15) and choose it as an action channel.
Figure 7-15. Selecting the SMS 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 7-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”.
Figure 7-16. Activating the SMS action channel
Now click on “Send me an SMS” under the “Choose your Action” section. You can now edit the message you will recieve when someone rings our doorbell. In Figure 7-17, we see an example of a custom SMS message that will result in the text “Hey, someone pressed me! -Sincerely, SMS_Door_Bell”.
Figure 7-17. Customizing the trigger SMS message
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 is not much of a doorbell 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 7-3), you will see that it has a right arrow on its top. This means that the module on 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 7-18.
Figure 7-18. Doorbell prorotype using the cloudBit
Press the button and you should get a SMS on your cell phone as shown in Figure 7-19.
Figure 7-19. SMS message alert from IFTTT
Even though we forgot to add in the button module initially, our oversight was easy to fix by simply plugging in the module afterwards. We didn’t have to take any additional steps with re-configuring cloudBit or re-programming our recipe. This makes littleBits a powerful prototyping platform.
Security Evaluation
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 company. To approach our analysis, we will first go through things we have learnt from security issues 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 by supplying credentials to the network (Figure 7-11). The finished product will also require the customer to input their WiFi credentials in a similar fashion. It is 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 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 7-20.
Figure 7-20. cloudBit query to obtain list of WiFi networks in range
Once the browser obtains the list of networks from the cloudBit, it renders it to the user (Figure 7-10). When the user selects their home network and enters their credentials (Figure 7-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 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 credentials “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 cloudBits 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/ 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 or her 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, i.e. 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 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 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, the potential consequences, and make an informed business decision on implementing security mechanisms to lower the risk to customers.
Sneaking in Command Execution
In Chapter 5, we discussed various scenarios where access to the file system 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 file system. 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 the ~/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 where the WiFi password is stored in clear text. What’s more, the PSK hash (calculated using the ssid and password) is also present. This creates a situation where anyone with access to the doorbell can easily access the file system 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. Since the cloudBits platform is merely for prototyping, uncovering issues like this is a good way to start to figure out 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>'
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 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/ps_netstat.cgi. You will see the output from the ps and netstat command, as shown in Figure 7-21!
Figure 7-21. Successful execution of the ps and netstat commands
This is a crafty way to execute live commands on the cloudBit to analyze more details in the device that are occurring in run-time. The designers of cloudBit do not want people to directly execute local commands on it since it may destroy the integrity of the product and as such it does not come with any way to remotely log in to the Linux system running on it. In this case, we have found a way to bypass their intention and execute local commands. This is yet another example of security issues we need to think about during the prototyping state: is it important that external parties be unable to tinker with the live system? In this case, the issue is that the file system 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 case here is not to impose obscurity as the intention of disallowing such tampering, but further protecting the product from a remote vulnerability in the web server or other services that can lead to compromise of not just the doorbell, but 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 AccessToken that is assigned to your cloudBit (Figure 7-22).
Figure 7-22. AccessToken assigned to the cloudBit
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 7-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.
Figure 7-23. Information about the connected cloudBit using the cloudBit API
We needed both the DeviceID and 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 littleBits and cloudBits platforms are not intended for production use, there is low risk 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 chance that it can be compromised.
Let’s add a buzzer module to our prototype. As shown in Figure 7-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 when the button is pressed as well as activate a local audio buzzer just like a traditional doorbell. This illustrates how powerful the littleBits prototyping platform is: designers can add and change functionality based on new ideas in a matter of seconds.
Figure 7-24. Buzzer module added to the SMS Doorbell prototype
In order for our prototype to send an SMS and activate the buzzer, you will have to create an extra IFTTT recipe that will need to select the cloudBit for both the input and output sections (Figure 7-25).
Figure 7-25. Additional IFTTT recipe to sound buzzer
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 issues 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. In the case where 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 after 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 earlier on in their prototyping modules so that every subsequent iteration of their product lowers the probability of their products 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 device 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.
UARTs (Universal Asynchronous Receiver Transmitter) 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 7-26.
Figure 7-26. UART communication pins
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. UART exposes four or more pins, so look for areas on the board that have four or more pins next to each other.
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 even 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.3, which is common for UART. As the transmit pin transmits data (often when the device has been powered on and it is booting firmware), the voltage drops to 0 and then back to 3.3. 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, and 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.
TIP
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 that 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 called JTAG, which stands for Joint Test Action Group. 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 become tedious, but the popular JTAGultor hardware tool can automatically identify the pins. Joe Grand, the creator of the tool explains how to use JTAGulator in this YouTube video.
The LIFX lightbulbs were found to use the JTAG interface by security researchers who used the interface to uncover a security vulnerability. The LIFX architecture does not require a hub like the Philips hue system. 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 (it 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 LIFX lightbulbs. 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 abusing this issue 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 cloudBits prototype, we came across an issue where 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 they 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 light bulb is insecure design. IoT product manufacturers should also think through secrets (such as WiFi credentials) that their device must protect responsibly. Standards and processors that implement TPM can and should be used to leverage hardware to store secrets more reliably so that they are not present in the firmware or accessible using hardware debug interfaces.
SIDE CHANNEL ATTACKS
In addition to debug interfaces and the secure storage of secrets in hardware, IoT hardware designers should also take into account side channel attacks, where information gained from the physical aspects of the system is leveraged to break security controls and potentially steal secrets such as passwords and encryption keys. Power analysis of a computing system has been a popular flavor of side channel attack. The ChipWhisperer suite of hardware and software tools can be used to analyze a particular device for information leakage by analyzing its power consumption. Researchers have also been able to use acoustics, i.e. the noise computing devices use during operation, to extract and decipher encryption keys. The concept of side channel attacks has been known and exploited in the past and it is important for IoT designers to make sure they understand the various ways their hardware may leak information that can potentially be abused to exploit the system.
Abuse Cases in the Context of Threat Agents
Coming up with abuse cases requires context to the threat agent 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 and intentions. For example, a gang of attackers with financial backing may employ persistent and sophisticated tactics against specific assets, while a disgruntled employee may leverage confidential knowledge to cause disruption in service or loss of proprietary information. The following sections contain examples of popular threat agents.
Nation States, Including the NSA
These are groups of highly sophisticated attackers that are funded by their governments. Given the amount of financial baking and support available to them, Nation State attackers are highly persistent and 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 threat agent came to mainstream attention after the set of attacks against major corporations that was named Operation Aurora. The attack was aimed at major corporations 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 United States for indulging in conspiracy.
The National Security Agency (NSA) is also a candidate for this category. Classified information, leaked by the famous whistleblower Edward Snowden, demonstrate extensive efforts by the NSA to spy on US citizens as well as 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 cyber attacks.
Snowden confirmed that the NSA 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 cyber-weapons and is an example of how malware can cause physical damages to affect critical systems.
In February of 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. Kaspersky 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 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 for the websites to cause disruption of service.
Cyber terrorists will be drawn to the notion of leveraging IoT devices to promote fear and disruption. Targeted attacks are likely to include individuals or families who are well known so that the attacks will obtain 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 for a few years now.
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 groups to promote terror by causing blackouts, locking or unlocking doors, controlling cars, and making fire alarms to go off. It is therefore important for designers to think through the motives of possible agents who could be leveraging their devices.
It is clear how important it is for an IoT based lighting system architect to think through such situations so that they are able to design security by proactively estimating ways their products may be leveraged by malicious agents.
Criminal Organizations
Private criminal organizations have been known to be quite resourceful and sophisticated. The primary motive of this agent is financial gain by stealing intellectual property (and selling it to the victim’s competitors) or money.
In February of 2015, the security firm Kaspersky announced that they had uncovered criminal activity by an organization that was able to steal one billion dollars from banks around the world by infecting computers with malware. Banks targeted included ones in Russia, USA, Germany, China, Ukraine, Canada, Hong Kong, Taiwan, Romania, France, Spain, Norway, India, the UK, Poland, Pakistan, Nepal, Morocco, Iceland, Ireland, Czech Republic, Switzerland, Brazil, Bulgaria, and Australia. The average attack yielded the criminals ten million dollars. The thieves were even able to seize control of banks ATMs and ordered them to dispense cash at a pre-determined 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. Attackers 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 access to company information based on an employee’s role given the added cost of implementing and maintaining such controls. In many cases, disgruntled employees already have legitimate access to 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 damages 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 includes the assassination of 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 that allowed them to access company data. The attackers obtained and released copies of executive emails, including the one pictured in Figure 7-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.
Figure 7-27. Internal email message between Sony Pictures executive leaked as part of the attack
Actions committed by certain threat agents can lead to the compromise of personal or corporate reputation, 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 may put confidential information at risk. Employees who are part of design and the supply chain process 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 can sneak in a backdoor account that he or she can later leverage to control and gain access to every baby monitor produced by the company.
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 ability could be a target of a social engineering attack where the support representative may be tricked into opening a door lock belonging to someone else. This situation can also be abused by the agent (who is disgruntled) to cause havoc by having all door locks that are online to unlock, thereby increasing customer support calls, and putting customers at physical risk.
Abuse case analysis for this agent should include third-party contractors and partners. It is important for IoT product designers to think through abuse cases in the context of threat agents so that they are able to build controls into the devices as well as the back-end infrastructure and processes supporting the products.
Hacktivists
A blend of the words “hack” and “activist”, groups of individuals in this category 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 each other. 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 fax machines.
In November of 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. The group could not gather enough resources to bring down the Amazon infrastructure.
In early 2011, Aaron Barr, the CEO of the cyber-security 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 at the workplace and at home will be a lucrative target for this threat agent. 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 abuse cases posed by Hacktvists to make sure the proper security controls are engineered and configured.
Vandals
Vandals are the most well known group since the dawn of the Internet. They aren’t interested financial gain. Their primary objective is 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, distress, and loss of reputation.
In April of 2015, the website of Tesla Motors was vandalized to display the content shown in Figure 7-28 (courtesy of Reddit).
Figure 7-28. Twitter website compromised by vandals
The vandals also were able to compromise Tesla’s Twitter account and posted inappropriate tweets along with one promising free cars (Figure 7-29).
Figure 7-29. Twitter account of Tesla Motors was also compromised
The group compromised the Twitter account of Elon Musk (CEO of Tesla) as well and tweeted messages from his account (Figure 7-30).
Figure 7-30. Twitter account of Elon Musk was hacked by the vandals
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 attacker was able to gain access to the legitimate Twitter account of Tesla and that of Elon Musk is by redirecting email bound for the teslamotors.com domain and resetting the Twitter password. Imagine how much other information this attacker 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 7-31), Tesla car owners could not use the company’s iOS app to locate or unlock their cars . The iOS app allows Tesla owners to locate, lock, unlock, and even start their cars using their iPhones without having to have their key fob. Given the increasing popularity and reliance of smart phones, many car owners are going to be increasingly dependent on their phones to unlock and start their cars rather than carry the key fob. This attack is a good example of how the simplest of social engineering attacks can affect the ability of car owners to be able to use their cars.
Figure 7-31. Tesla owners were unable to use the iOS app while the attack was in progress
Gaining access to the entire domain of teslamotors.com using a simple social engineering attack demonstrates how easy it can be to disrupt the security of major corporations. Instead of vandalizing the website and Twitter accounts, the attacker could have surreptitious maintained access for a prolonged period to steal intellectual property and financial data. Vandalizing a popular website and Twitter accounts is bound to receive immediate response from the security operations personnel at the company that is being attached, causing the loophole to be closed. Attackers who want to cause severe financial and business damage are unlikely to vandalize popular websites 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. Companies such as Tesla pay the price of brand damage nonetheless. Current and potential car owners may consider other car manufacturers after having read about this attack in the media.
In previous chapters, we’ve seen that Tesla uses its always-on 3G cellular connection to receive and install software updates that can affect the physical functionality of the car. Owners and potential buyers are likely to question Tesla’s ability to protect their infrastructure from simple social engineering attacks such as these and be concerned about danger to their physical safety should attackers abuse situations like this to effect the functionality of their cars that may result in an accident. Competitors to Tesla may use this situation to lure car buyers towards their products.
From the perspective of IoT, cloud platforms that are relied upon by endpoint devices are likely to be a target by vandals. Imagine if a vandal were able to social engineer the domain registrar for the SmartThings platform to re-route traffic through his or her systems. A compromise such as this could allow the vandal 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 monitor around the world. IoT vendors must make serious note of this threat agent 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.
Bullying
According to the 2013 Youth Risk Behavior Surveillance Survey, 15% of high school students in the United States between grades 9 and 12 were bullied in the past year. Given the prevalence of technology in the lives of kids today, cyber bullying 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. Cyber bullying leads to lower self esteem and health problems for the victim.
Various government agencies have come together to create a website against bullying, including cyber bullying, to promote awareness of the issue and to provide a mechanism to seek help: http://www.stopbullying.gov/cyberbullying/.
Ryan Patrick Halligan, hanged himself at the age of 13 as a result of cyber bullying. Ryan was bullied in 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 began communicating with a friend on instant messaging and they both exchanged ideas on 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 Suicide Prevention Law (Act 114). Other states have also pushed to enact laws against cyber bullying based on Ryan’s story.
Unfortunately, there are many other stories such as Ryan Halligan’s, and the prominence of cyber bullying 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. IoT devices such as lighting, connected door locks, and security systems can and will be leveraged by perpetrators to commit bullying. From the consumer angle, parents will have to become aware of how connected devices in their homes may 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 other’s access to their homes via a companion iPhone app. Kids who use their iPhones to unlock their home whens 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 the child, assuming he or she has their own smart phone 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 make sure they are promoting kids to lead safer and healthier lives while taking into account real threats such as cyber bullying.
Predators
There have been many unfortunate cases of children been lured and sexually abused by predators who use online chat forums and instant messaging to find and communicate with minors. Similar to bullying, 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 encourage parental control features in products where appropriate so that children are protected from suspicious activity as well as a mechanism 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 product is 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 issue to the product vendor. Some companies have done a good job of advertising how researchers may contact them to report security vulnerabilities, but many companies do not advertise how they wish security issues be reported to them. This often causes researchers to contacting customer support, which may not be equipped to route the information to the right individuals.
In 2013, a researcher tried to report a security issue to Facebook that allowed anyone to post on anyone else’s Facebook page (even if they were not friends). The researcher actually reported the issue by following instructions on Facebook’s own vulnerability reporting process, but the Facebook security team responded with “sorry this is not a bug”. The researcher then posted details of the vulnerability on Mark Zuckerberg’s (CEO) Facebook profile. Within minutes, the security engineering team at Facebook contacted the researcher and worked with him to understand and fix the issue.
Companies such as Microsoft have set up bug bounty programs that pay researchers up to $100,000 US dollars depending upon the severity of the issue. The case for such a high reward is that the sophisticated research done by individuals who submit information to bug bounty programs would have cost Microsoft the same amount or more to uncover themselves. Categorizing the awards based on severity easily aligns with lowering the risk for the company and its shareholders.
There are also companies such as HackerOne (Figure 7-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 they 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.
Figure 7-32. Recent bug bounties paid to researchers on HackerOne
It is terribly important that IoT vendors clearly establish a mechanism for researchers to submit vulnerabilities. Without a clear process, there is little incentive for researchers to spend time reporting issues. Even though not all company pay bounties, it makes business sense to do so because it offers incentive to the researcher and lowers the probability of the issue becoming public before it is fixed, and this can put customer information, safety, and the revenue of the business at risk.
Conclusion
The littleBits platform 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 being done with our platform, we were able to uncover security issues relating to WiFi security, command execution on the device, and concerns with the persistence of the access token used by cloudBits 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 on rather than to try and bake security in at a later stage.
We also looked at ways people could potentialy tamper with hardware-based debug interfaces to obtain access to functionality that may compromise the integrity or confidentiality of the product. These situations can put users of the entire product line at risk, such as in the case of the LIFX lighting system that exposed a universal symmetric encryption key found in all of their devices.
It is also extremely important to think through how different threat agents may want to abuse vulnerabilities. For example, a disgruntled employee working within customer support with access to the location of connected cars may want to expose GPS data of famous celebrities that own his or her employee’s car 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 agenda to cause disruption in services and 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, along with any applicable reward that may be paid upon verification. In most cases, the cost of the reward is less than the price companies have to pay in terms of loss of revenue arising from the negative effect to their brand and the loss of their customer’s privacy and trust.