Insecure Internet of Things (IoT) devices are used to carry out Distributed Denial of Service (DDoS) attacks. A well-known example of such a DDoS attack by an IoT botnet is the attack on Dyn DNS by the Mirai botnet. Dyn DNS operates a DNS infrastructure which was severely impacted during the attack. In an attempt to reduce the risk of insecure IoT devices, SIDN Labs began the SPIN project. In the context of the project, we evaluated the usefulness of the Manufacturer Usage Description (MUD) specification, which is currently under development.
The MUD specification is being developed by the Operations and Management Area Working Group (OPSAWG) of the Internet Engineering Task Force (IETF). The idea behind the specification is that, when an IoT device connects to a network, it tells the network what resources it needs to function properly. That information is contained in a MUD profile, which describes the device’s intended network activity using a whitelist-based approach. Since the whitelist is supposed to be exhaustive, access to other network resources can be denied without impeding the functionality of the device.
In the research reported here, we investigated MUD’s usefulness for protecting IoT devices against hacking attempts. We also investigated whether the usability of an IoT device as a DDoS attack medium was reduced by enforcing a profile. However, since the MUD specification is a work in progress, it has not been implemented on any device. Therefore, to enable us to perform measurements on MUD profiles, we created a tool that observes the network behaviour of an IoT device and generates a corresponding MUD profile. Our tool performs three tasks:
it collects information
it generates a profile using that information,
it can enforce a profile.
Approach
The first step is to collect the necessary information. The MUD profile contains a whitelist specifying the intended network behaviour of the device. Simply put, it consists of a list of domain names or IP addresses that the device can communicate with. For each domain name or IP address in the list, additional information can be provided, such as the transport layer protocol (e.g. TCP or UDP) and other characteristic information, such as port numbers. The information is collected on the home router. The home router is a good place to collect the information, since the home router is able to observe all traffic between the hosts in the local network and the internet.
When collecting and analysing flow information, we had three aims:
to determine whether any device in the flow is a local network device (by inspection of ARP and NDP);
to identify the device that initiated the connection (using the SYN flag in the TCP header); and
to match IP addresses in flow records with the corresponding DNS queries sent prior to the flow. Often, a connection is initiated using a host name (such as example.nl) and then resolved to an IP address, using the DNS. Matching the domain names with the IP addresses in the flow records involves inspecting the DNS packets which contain the relevant queries and answers.
In order to generate an accurate profile, it is necessary to collect sufficient network traffic data to ensure that all possible connections are included in the dataset. That implies collecting measurements over a long period of time. Many devices perform periodic tasks, such as checking for software updates every 24 hours. However, it is important that all an IoT device’s features are used during the measurement period, because each feature may involve different network behaviour.
Once enough measurements have been collected, the tool can generate a MUD profile of a device’s network activity. That is done by first filtering all collected flow records, keeping only flows that involve the device for which a profile is to be generated. All flow records that involve the MAC address of the device are selected. We prefer to work on the basis of MAC addresses, because IP addresses are often dynamically assigned, and a device can be associated with more than one IP address.
After a profile has been generated for the IoT device, the next step is to enforce the profile. That involves restricting the device’s network access to the behaviour specified in the profile. In our prototype, that is done by converting the profile to a set of iptables rules.
Evaluation
We implemented the system described above as a prototype. In order to determine whether the prototype met our requirements, we performed an evaluation. The evaluation addressed three questions:
Is the IoT device able to function correctly once we enforce the profile we have generated?
Once the profile is enforced, does it become harder to hack the device?
If a device does get hacked, is the device’s usability as a DDoS attack medium reduced by having a profile in force?
In order to answer the first question, we generated and enforced profiles for a number of IoT devices. We then established whether the devices still functioned correctly. For example, in the case of an internet-connected light bulb, we checked whether we could still turn the light bulb on and off with a mobile phone. To answer the second and third questions, it was necessary to know how attackers interact with IoT devices. We therefore undertook a literature study to find out more about IoT-related attacks. That led us to useful information sources, such as several scientific papers written about the Mirai botnet, detailing its characteristics. The relevant characteristics were then compared with the generated profiles.
Results
Generating profiles in the way described proved to work well for the specific-purpose devices that we evaluated during our research. Our approach will be less viable for general-purpose devices, such as mobile phones or laptops. Such devices allow the user to initiate a connection with any host, rendering the whitelist-based approach to device profiling unworkable. In contrast, the network behaviour of a specific-purpose device is usually quite restricted, allowing us to whitelist the network connectivity.
Furthermore, we found that enforcing a profile reduces the attack surface of a device. Devices can be contacted only in the ways specifically allowed by the profile. In most cases, that means that the device cannot be contacted from the internet. Obviously, attacks that use a whitelisted channel cannot be prevented using MUD profiles. Nevertheless, device profiling greatly decreases a device’s attack surface.
Figure 1: Device A and Device B launch denial-of-service attacks on example.net and example.org, respectively. Both domains are hosted on the same cloud platform.
In addition, the usability of a device as a DDoS attack medium was found to be slightly reduced. Specifically, the number of services that can be attacked is reduced to those that are whitelisted in the profile. However, these days, the use of cloud platforms such as Amazon Web Services (AWS) or Google Cloud Platform (GCP) is quite common. We observed that a number of IoT devices connect to services hosted on AWS, for instance. Now imagine the following scenario. We generated profiles for both Device A and Device B. They have distinct profiles. Device A is allowed to access example.net while Device B is allowed to access example.org. If both example.net and example.org are hosted on the same cloud platform, Device A and Device B can still mount a DDoS attack against that platform (see Figure 1), even though the profiles generated for the devices are different.
Future work
The scope for using IoT devices to mount DDoS attacks could be reduced even further. We suggest looking into rate limiting, since IoT devices may not need the entire bandwidth available to them. Another useful line of future research would be the validation of manufacturers’ device profiles: once devices that support MUD become available on the market, one could compare the profiles specified by the manufacturers with profiles generated by the prototype.
The thesis is available from the website of the University of Twente.
