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.
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;
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();
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";
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.
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.
Michael Parks, P.E. is the co-founder of Green Shoe Garage, a custom electronics design studio and embedded security research firm located in Western Maryland. He produces the Gears of Resistance Podcast to help raise public awareness of technical and scientific matters. Michael is also a licensed Professional Engineer in the state of Maryland and holds a Master’s degree in systems engineering from Johns Hopkins University.
Privacy Centre |
Terms and Conditions
Copyright ©2022 Mouser Electronics, Inc.
Mouser® and Mouser Electronics® are trademarks of Mouser Electronics, Inc. in the U.S. and/or other countries.
All other trademarks are the property of their respective owners.
Corporate headquarters and logistics centre in Mansfield, Texas USA.