Why are connected device risks more inherent with APIs?
I recently purchased a Bluetooth speaker. All the prior Bluetooth speakers I owned had two connectivity modes: pairing with phones or tablets via Bluetooth, or physically plugging in an Aux cable.
This model of Bluetooth speaker was different — it demanded a Wi-Fi connection. I was curious and allowed a temporary connection to my home Wi-Fi. First, it downloaded and installed updated firmware, and then it suggested I install a mobile app to utilize its features fully.
An increasing number of IoT devices require this sort of connectivity — Bluetooth is too limited in range and thus does not allow truly remote operation, and of course, who doesn’t want the ability to unlock their smart lock from work to let a maintenance guy in?
Unfortunately, this convenience comes at the cost of security. Most of these devices will use RESTful API calls to communicate back to the cloud, and it is often much harder to secure this kind of communication than a simple user portal. The most common attacks against these devices fall into two categories:
- Attacks against the device itself
- Attacks against the API
Attacks against devices
The primary challenge with device attacks remains identity. How do you identify the device? After all, it’s not a person that utilizes a username/password combination and some sort of multifactor authentication to log into a portal.
A properly secured IoT device requires a robust primary key infrastructure (PKI) with a private key unique to each device to authenticate to the cloud API. If a device lacks these PKI elements, it may be quite easy for a malicious user to reverse engineer the authentication schema used by the device either by gaining access to internal storage or by examining network flows by inserting a proxy in the path.
The knowledge obtained in this step enables an attacker to gain access to other devices managed by the same vendor. While the ramifications may be minimal in the case of a single Bluetooth speaker, it’s concerning when it comes to other connected devices such as smart locks or connected baby monitors.
Attacks against APIs
On the other side of the coin, there are the attacks that target the API itself. To support users spread across multiple geographical regions, APIs must be available to the public internet and thus are available to attackers as well. The attackers can throw the same assortment of attacks against an API as they would against an actual web application or portal. SQL injections and stored cross-site scripting attacks work just as well in RESTful API JSON payloads as they do in HTTP arguments of an old-school web application. Unfortunately, APIs historically do not receive the same level of security testing, and many web application firewalls do not support checking JSON payloads.
Most vendors also let the convenience benefits obfuscate security consequences. If I look at a webpage of smart lock vendors, I find statements like, “Our mission is to make our customers’ lives more simple and secure by offering unprecedented visibility and control over their front door.”
What these statements lack are the details on how they protect organizations from an attack — no mention of independent security testing, no SOC2 reports, nothing. Without those considerations, you may as well be giving your house keys to the internet. You would never leave the keys to your physical front door lying around, and you should ensure the same approach with your connected version.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.