Bench Talk

The Internet was not built with security in mind. It was built predominantly by researchers looking to pass around scientific data. The assumption was that only good players would ever have access to the systems that eventually gave rise to the Internet we all know today. We have made significant progress with security in the decades since the Internet first became accessible to the public, but the cat and mouse game between the good guys and bad guys continues.

Meanwhile more and more devices, beyond just computers and servers, are relying on the Internet as a communications and remote control backbone. The sum of these new devices, colloquially referred to as the Internet of Things, leverage the same protocols we use to message each other or conduct financial transactions. The difference now is that instead of just data being passed around, devices that control physical objects and processes in the real-world (more affectionately referred to as “meatspace”) are communicating over the same Internet.

Embedded systems that make up the Internet of Things (IoT) are constantly becoming more powerful from a computing perspective. Still, they are limited when compared to the modern desktop or even smartphone architectures. These limited resources force us to make design choices that might not be the best from a security perspective. To illustrate the inherent risks, we are going to demonstrate how it is possible to inject fake data packets into a sensor’s data stream. What are the inherent strengths and weaknesses of IoT security from a “black hat“ hacker’s perspective? We have not given you enough information to attempt this in the real world, just enough to give you an idea of how this happens. Here goes:

Imagine a hypothetical embedded platform, let’s call it the Hypothetical Embedded Platform or “HEP” for short (I know, very original). It has a 32-bit processing core, plenty of analog and digital I/O pins, and Wi-Fi built in. It comes with a very well-documented Application Program Interface (API) to connect our device to the HEP Computing Cloud where the data is stored for downstream processing.

CONNECT THE EMBEDDED DEVICE TO THE INTERNET

The first thing we must do is tell our new HEP how to talk to our Wi-Fi network. That means supplying the SSID and the encryption key of our wireless network. In addition, we must also spell out the server address and port of the web service we will be interacting with (for our example that will be the fictitious HPE Computing Cloud). Lastly, we must also authenticate who we are to the HEP Computing Cloud web service. This is usually handled in the real-world by assigning a unique key to each embedded device (HEP_DEVICE_ID in our example). Also, an event name is given since an embedded device could be repurposed for different uses later. The event name helps to prevent data from different use cases from getting dumped together into one log file.

#include <”WiFi.h”>

#include <”TemperatureSensor.h”>

const char * SSID = “mynetwork”;

const char * WPA_KEY = “ABC123”;

const char * HEP_DEVICE_ID = “A7FG390H463”;

const char * EVENT_NAME = “temperatureReading”;

const char * SERVER = "api.hep.com";  
uint16_t PORT = 80;  

WiFi TCPConnection;

TemperatureSensor tempSensor1

TCPConnection.networkConnect(SSID, WPA_KEY);

SEND SOME DATA TO THE CLOUD

At this point our HEP embedded device should be connected to our local wireless access point. However, we haven’t done anything useful yet like taking a sensor reading and pushing it the cloud. To do so let’s take a look at an example of using the API, specifically the use of the POST command.

Int temperatureReading = tempSensor1.getTemp();

TCPConnection.serverConnect(SERVER, PORT);

String temperatureMessage = "POST /trigger/”+HEP_DEVICE_ID+”/event/”+EVENT_NAME+”?value="+temperatureReading+" HTTP/1.1\r\nHost:api.hep.com\r\nUser-Agent:HEP\r\n\r\n";

TCPConnection.sendMessage(temperatureMessage);

TCPConnection.disconnect();

In an ideal world, this code would run forever, blissfully updating a log file on the server with the temperature detected at the node sensor. The server would assume that, given the security features we implemented in our code (e.g. WPA2 Wi-Fi encryption, a unique and random alphanumeric device ID, and a user defined event name), that all data received is coming from our hardworking embedded device.

THE HACK (IN THREE EASY STEPS!)

Sadly, this is not the case. A nefarious individual would not be stopped if they desired to hack our HEP-based temperature sensor device. The attack vector laid out does require some assumptions, and while not necessarily likely, it is possible.

1. A hypothetical bad guy would use one of a handful of freely available packet sniffing applications to watch the packets as they pass along our wireless network.
2. His (or her) goal is to crack the WPA2 key so they can read the information contained in the packets. With the key in hand, the bad guy can read all packets going across our wireless network.
3. Next, the bad guy collects the packets and determines which packets contain our HEP temperature-message traffic. Once they know the IP address of the HEP device, they can focus on collecting those specific packets until they understand our POST message format. Or they could read the readily accessible API documentation that would be available online.
4. The two most important pieces of information they need would be HEP_DEVICE_ID and the EVENT_NAME. With that information, they can go anywhere in the world, connect to any network, fire up a command line interface and issue a cURL command that would look something like this:

curl -X POST https://api.hep.com/.....<insert stuff here>…./temperatureReading?value=500

With a single line of code, a hacker has injected a false sensor reading of 500℉.  That’s it. That’s all that is needed to do a basic packet injection type of hack. In this particular example, depending on what actions are triggered by our temperature sensor data, the bad actors could do real damage in the real world. Imagine we were using a service like IFTTT.com and have setup a recipe to open windows in our house if the temperature exceeds a certain value. By injecting the fake packets, the hacker could falsely trigger that recipe and gain physical access through the now open windows in our home.

Most people don’t know how to find specific information needed to create a hack, others do not have access to computers (although smartphones are essentially 32-bit computers with different operating systems and so forth.) Still others may be able to learn how to hack and have access to computers but have the morals, ethics, and common sense to refrain from trying. But with 7 billion people in the world, and with millions (billions?) of unencrypted devices on the web, it is very apparent to see that the odds are not in our favor to maintain security by the lucky chance of not being found in the first place.

The above example is just one of many possible challenges that need to be overcome to make IoT secure.