eMUD: Enhanced Manufacturer Usage Description for IoT Botnets Prevention on Home WiFi Routers

Abstract

Distributed Denial of Service (DDoS) attacks have caused significant disruptions in the operations of Internet-based services. These DDoS attacks use large scale botnets, which often exploit millions of compromised Internet of Things (IoT) devices worldwide. IoT devices are traditionally less secure and are easy to be exploited. The extent of these exploitations has increased after the publication of the Mirai botnet source code on GitHub that provided a foundation for the attackers to develop and launch Mirai botnet variants. The Internet Engineering Task Force (IETF) proposed RFC 8520 Manufacturer Usage Description (MUD) so that an IoT device can convey to the network the level of network access it requires to accomplish its standard functionality. Though MUD is a promising effort, there is a need to evaluate its effectiveness, identify its limitations, and enhance its architecture to overcome its weakness and improve its efficiency. The latest Mirai variant malware is exploiting vulnerabilities of Internet of Things devices [1]. As MUD does not consider identifying and patching vulnerabilities present in the device before the issuance of the MUD profile, a device can be compromised even in the presence of the Manufacturer Usage Description profile by exploiting either the configuration vulnerabilities or firmware vulnerabilities present in the device [2]. This paper presents an evaluation study of the Manufacturer Usage Description (MUD), identifies its weaknesses, and proposed enhancements in its architecture. This research proposed a mechanism for identifying and eliminating the configuration vulnerabilities before creating the MUD profile for a device to minimize the attack surface. This research adopts the OWASP firmware testing methodology [3] for discovering vulnerabilities in the firmware of WiFi home routers. The device is allowed to request the MUD profile only if the identified firmware vulnerabilities are low. The identified firmware vulnerabilities are patched in case the score of the identified firmware vulnerabilities is moderate or high. The device is allowed to request the MUD profile after the vulnerabilities are patched. The firmware vulnerabilities are shared with other peers using blockchain smart contracts. There is a possibility that the MUD URL might be pointing to a corrupted or malicious MUD profile hosted at the attacker file server due to the absence of an authentication mechanism in the MUD process. This research also proposed an authentication mechanism for device MUD profile, MUD file generator, and MUD file server. Implementation results show that proposed enhancements improve the security services provided by the Manufacturer Usage Description (MUD).

Role of Device Identification and Manufacturer Usage Description in IoT Security: A Survey

“…MUD is unable to identify the vulnerabilities and bugs in the device firmware before it requests the MUD profile. However, there are some advancements on the MUD [163], that only allowing the device to request a MUD profile when the vulnerability factor of the device is below a certain threshold. Also, it presents an authentication mechanism for MUD profiles for secure and reliable communication of device profiles.…”

Defining the Behavior of IoT Devices Through the MUD Standard: Review, Challenges, and Research Directions

“…Furthermore, [32] uses the same tool to create a botnet detection and mitigation system. The authors of [33] also employ MUD Maker to generate MUD files associated to devices that are submitted to a vulnerability assessment process before getting network access. Furthermore, [21] uses this tool as an example to show how MUD restrictions in a network could be modified to mitigate privacy concerns.…”

“…Content may change prior to final publication. [33] (MUD Maker) [34] (MUDgee) [36] (MUDgee) [37] (MUDgee) [38] (MUDgee) [39] (MUDgee) [21] (MUD Maker) [40] (MUDgee) [41] (MUDgee) [20] (security testing results [55]) [44] (devices' changing behavior in smart buildings) [32] (MUD Maker) [19] (Medium-level Security Policy Language (MSPL) [45]) [47] (QoS parameters) [42] (MUDgee) [48] (human usage aspects) [49] (physical layer parameters and flow statistics) [52] (devices' fingerprinting data) [30] (MUD Maker) [42] (MUDgee) behavioral profiles for connected devices. These aspects are further discussed in Section V.…”

“…A similar approach is also proposed by [60], where MUD Manager's functionality is integrated into fog nodes [61]. In the case of [33], the device's certificate is generated before the MUD profile is created for that device. Furthermore, [62] proposes a certificate-based approach by using a Bootstrapping Remote Secure Key Infrastructure (BRSKI) [63] and AAA for obtaining MUD files through the manufacturer.…”

“…Similarly, [71] presents a deployment scenario for MUD files that are directly deployed on a local router as part of a home network scenario. Also in a similar home setting, [33] proposes an extended MUD architecture based on blockchain technology to obtain vulnerabilities associated with devices on a certain network. In the case of devices getting over a vulnerability assessment process, MUD restrictions are obtained and enforced in routers deployed throughout the network.…”