Internet of Things Security Going into 2021Follow article
Do you remember the days when children were seen and not heard? No, me neither. I do remember the days when embedded computers weren’t seen and generally weren’t heard from either. They just got on with their job unless there was a problem.
Times change, and the ability to communicate, especially wirelessly, has opened up so many applications to embedded microcontrollers that (depending on whose statistics you use) around 7.6 billion IoT devices were hooked up to the internet by the end of 2019 – about 1 for every person on the planet. It has also opened a slippery can of worms, trying to keep these communications only between those who are supposed to be communicating.
In this article, I will give my perspective on the top security issues for designers at each conceptual layer of an IoT application going into 2021. So, we can limit the length to something you might actually read, we will only discuss one or two of the more common (or more interesting) issues out of the myriad available for each layer. If you think I’m wrong on anything or you have more to add, I would love to hear from you in the comments!
Before we get to our security issues, let’s take a moment to define what we are talking about, so we all start on the same page.
The term ‘Internet of Things’ or ‘IoT’ can be a little nebulous and can mean different things depending on who you ask. In the context of this article, I am using the term to refer to low-power computing devices (both in energy usage and computing capability) embedded into things most people would not recognise as a computer. They are distributed but have some kind of networking capability so they are not isolated - but that doesn’t necessarily mean they are using Internet Protocol (IP).
It is also worth noting that the architecture of IoT has also been evolving with the introduction of new technologies:
IoT has followed the general model of the computing world, where processing was originally on massive, expensive mainframes with dumb terminals. As processing became cheaper, it allowed useful work to be moved away from the mainframe and onto connected workstations and finally to networked desktops using servers mostly for data storage.
The original IoT architecture was about connecting low power devices to the cloud where the collected data could be processed. As microcontrollers have become more powerful, direct interaction between nodes to form meshes or grids for cooperative computing is becoming commonplace; with more of the heavy processing happening much closer to the edge in what has become known as Fog computing - simply cloud computing done much ‘closer to the ground’. This is essential for any kind of control over real-time, low-latency applications; especially where you have huge numbers of IoT devices creating massive volumes of data.
Any IoT application can be broken down into (more or less) four broad layers, as shown in Figure 2. Breaking the application into these layers allows us to think a little more clearly about the attack surfaces that are presented to malicious actors at each stage but also to think about where genuine misunderstanding or unintended misuse can occur.
As an introduction to our thoughts, let’s consider two separate incidents affecting IoT applications at the sensor layer – in this case in self-driving cars. In 2018, SoraNews24 reported that the logo of the Tenkaippin ramen store chain in Japan was confusing Honda’s SENSING AI software, which thought it was seeing a ‘Do Not Enter’ sign. This was obviously a case of genuine misunderstanding, but this kind of input error can lead to indeterminate results.
Perhaps more concerning was the second incident, reported in IFLScience, where hackers were able to make a Tesla on autopilot swerve into oncoming traffic using just stickers on the road. Luckily, this was being done by researchers rather than malicious actors but, just as with the previous example, engineers have to consider that when AI gets out into the wild, it will – without doubt – encounter input that it hasn’t been trained for. Reacting to this kind unexpected data input gracefully (and not fatally) is an essential consideration for any IoT application.
Figure 3 provides an outline list of the kinds of attack an IoT application may be subjected to at each layer. The sharp-eyed among you will have noticed that I have slipped in a 5th element (nothing to do with Milla Jovovich, unfortunately) which I have called the ‘Gateway Layer’. This is not related to the application directly but is concerned with securely adding an IoT element into a deployed system.
As I mentioned, we will only discuss one or two attacks per layer but the list will allow you to look up any of the other attacks that you may want to find out more about.
Starting at the sensor layer, individual nodes may be vulnerable to being captured or replaced. Sometimes it is enough to simply add an extra node that looks to be just another one amongst thousands. Once a compromised node is part of the network, the door is open to many of the other attacks.
In terms of false data injection, we have already seen with the self-driving car examples that this can be achieved even when nodes are not directly under the control of an attacker. But once under an attacker’s control, the best-case scenario is that a node is only used for a relatively harmless spoof, like the Lime Scooters hack in 2019.
However, the most common reason that someone may want to control your node has nothing to do with your network: the aim is building a ‘bot’ army (or ‘botnet’) that can be used in a distributed denial of service (DDoS) attack at the network layer.
In a DDoS attack, target servers are flooded with bogus service requests from thousands of zombie nodes that are orchestrated from a command and control server, that has usually also been hacked. Hacking groups in control of a botnet will often perform attacks for hire, so (for example) an unscrupulous business may pay a group to bring down a competitor’s website on the day this competitor launches a new product, preventing legitimate users from accessing the site and ruining the launch.
Although DDoS attacks are not specific to IoT devices, they have tended to be vulnerable to use in this way due to weak configuration – such as hardwired passwords (i.e. unchangeable) or published default passwords on devices that do not force users to change them on first use.
The most famous of these attacks is probably the Mirai botnet that was used to attack the DNS servers of Dyn, bringing the internet for the whole of the US east coast to a grinding halt. In February this year, Amazon Web Services managed to mitigate, what at the time of writing, is the largest recorded attack at 2.3 terabits per second!
Routing attacks are where malicious nodes will try to redirect the data they receive. One method is known as a sinkhole attack, where the rogue node will offer a ‘shortest route’ path that will get other nodes to route traffic through this node. This can be combined with a wormhole – where an attacker uses an out-of-band connection (i.e. a direct connection that isn’t part of the standard dataflow) to connect to another device, effectively bypassing the network security, allowing data to be stolen.
The man-in-the-middle attack is a way of exploiting the MQTT protocol’s publish-subscribe model of communications. The MQTT broker acts as a proxy between the publishing and subscribing clients, decoupling them and allowing messages to be sent without needing information about the destination. If an attacker can get control of the broker, then they have complete control of the dataflow with the clients being none the wiser.
This layer deals with services provided to the user. Let’s face it: users will always be the designer’s biggest security problem. Most users do not understand (or care to learn about) the technology – it might as well run on magic – but they expect it to work and will be litigiously annoyed to find that their private data is strewn across the dark web.
At this layer, the IoT application needs to protect users from being the breach in security as well as securing against data theft (hint: properly configure your AWS S3 storage buckets) or loss of application control by the user.
Malicious code injections: hackers are adept at finding the easiest methods to get into a system. If a system is vulnerable to malicious scripts or redirections because it doesn’t check code properly then this is where attackers will hit. An example of this is (CVE)-2018-10933 that documents a bug in the secure shell protocol library (libssh) where, because of a shared structure in client-side and server-side code, a rogue client could gain access to authenticated connection simply by declaring SSH2_MSG_USERAUTH_SUCCESS i.e. by claiming authentication, regardless of the authentication result!
The most common method of malicious code injection is XSS or cross-site scripting to get a mischievous script into what would otherwise be a trusted website.
A gateway layer can serve a number of purposes. This is where multiple (perhaps heterogeneous) nodes are connected locally by protocols such as Bluetooth Mesh, Zigbee, Z-wave or even LoraWan, before connecting this data to the cloud. As such, the gateway is where protocols are translated for communication between different layers. This can also mean decrypting and re-encrypting data flows into and out of this layer.
Gateways are a key component for secure onboarding of new nodes. They act as intermediaries between new devices and the managing services so they must protect all the encryption keys that pass through them. Gateways could be susceptible to man-in-the-middle or eavesdropping attacks in order to capture these keys during on-boarding. Of course, the onboarding process could make it easier for hackers by just broadcasting useful configuration information.
Another key role of the gateway layer is in firmware updates. As IoT devices tend not to have the resources to download and install their own updates, the gateway will be used to download and apply updates. This makes the gateway responsible for recording the current an new version of firmware and checking the validity of signatures. It is also a good idea not to brick your devices with an update.
The security of networked computers has tended to follow the philosophy of penetrate, then patch with bug bounties being offered in the hopes that the good guys find the vulnerabilities first. Maybe an element of this can be carried forward into IoT.
My own feeling is that perhaps there is a gap in the market for entrepreneurial security firms to run some standard tests on IoT equipment to certify that it, at least, doesn’t have any of a standard set of dumb flaws (like hardwired passwords) that make them a doddle to hack.