Mirai has received significant attention in the wake of record setting distributed denial-of-service attacks that took place in September of 2016. Mirai is a platform that supports ongoing DDoS-for-hire operations, allowing threat actors to launch DDoS attacks against their victims in exchange for monetary payment.
Unfortunately, with 6.4 billion IoT devices in use, and a vast majority of them not properly secured, Mirai and other IoT-based botnets pose a threat, not only for their DDoS capabilities, but also due to the way they propagate. Indeed, Mirai can, and has, inadvertently caused outages simply by attempting to overtake these insecure IoT devices. One example of this is when more than 900,000 customers of German internet service provider Deutsche Telekom (News - Alert) lost its internet connection this past November after its routers were infected with Mirai.
In late November 2016, a new Mirai variant emerged that leveraged a propagation mechanism different from the Telnet-based brute forcing mechanism originally provided in the leaked Mirai source code. This new variant exploits vulnerable implementations of the TR-064/TR-069 protocol used by internet service providers to remotely manage their customers’ broadband routers. Given the focus of this Mirai variant, service providers are looking for specific mitigation advice to prevent this new variant from overtaking their customer premises equipment and/or causing network outages in the process.
Understanding the Economic Model of Mirai
In late 2016, the new Mirai variant was reported by several media outlets as being used to provide DDoS as a service. These DDoS-for-hire booter/stresser services allow anyone the ability to launch a DDoS attack against a victim for a small fee. Interestingly, if we consider the economic model of this botnet, we see that it roughly mimics that of a mobile virtual network operator.
If we follow this analogy, the threat actors who are building and maintaining the Mirai botnet are the mobile network operators. They own the botnet infrastructure and provide other threat actors (the MVNOs in this case) with managed access to it. The second-tier threat actors (aka MVNOs), in turn, provide the DDoS-for-hire service to end customers, setting their own rate structures and marketing it however they choose. For example, sometimes the MVNOs will actually refer to the botnet as Mirai, whereas in other cases they may simply peddle what they advertise as their own botnet. The Mirai source code has built-in support for this type of economic model with a MySQL account database, API, and CLI-level access to the botnet.
How Mirai’s Propagation Mechanism is Evolving
Like all things that evolve to survive, the propagation mechanism used by this new Mirai variant changed from the propagation mechanism used in the originally-leaked Mirai source code. The original Mirai code performs Telnet-based brute forcing to compromise vulnerable IoT devices that were poorly designed and configured. Unfortunately, most consumers don’t change the default passwords that their new IoT devices arrive with. This means that when the device manufacturers’ pre-defined lists of default usernames and passwords were compromised, it resulted in countless webcams and DVRs being subsumed by Mirai botnets.
Now, if we look at this new Mirai variant, we see its propagation mechanism working very differently. The new variant exploits vulnerable implementations of the TR-064/TR-069 protocol used by ISPs to remotely manage their customers’ on-premises equipment (primarily home routers). The vulnerable implementation of the protocol (also known as the CPE WAN Management Protocol, or CWMP) allows arbitrary code to be executed on affected routers by passing that code as a configuration parameter delivered in a SOAP message over HTTP to port 7547. A detailed explanation of this exploit is provided by the Internet Storm Center. The arbitrary code execution allows the Mirai payload to be downloaded and installed onto the router, incorporating it into the Mirai botnet. Once the IoT device has been absorbed into the botnet, it is available to launch DDoS attacks upon command, and simultaneously begins scanning for other IoT devices to compromise – creating an increasingly larger and stronger botnet.
Mitigation Advice for Broadband Operators
Given the aggressive nature of this Mirai variant’s attempts to compromise CPE devices and rapidly grow botnets, it is critical for broadband access ISPs to proactively scan their customer access networks to locate compromised and/or vulnerable nodes, and then notify those customers that their devices are vulnerable. In cases where the ISPs themselves have provided the vulnerable CPE, the ISPs should immediately replace those devices. This is because heavy scanning by threat actors will merely result in those devices becoming immediately re-compromised after they’ve been rebooted. Additionally, broadband access ISPs should apply the network infrastructure self-protection mechanisms built into their network devices to rate-limit ARP and other relevant control-plane traffic, which may be created by compromised devices scanning the network with the goal of pulling other vulnerable CPE devices into the botnet. This will enable ISPs to ensure that heavy scanning activity by compromised CPE devices will not disrupt large swathes of their customer base by limiting the collateral impact of such scanning.
It is also important to note that ISPs operating DSL broadband networks should implement Best Current Practices to ensure that only the ISPs’ dedicated network management systems can access the remote network management facilities on these CPE devices. ISPs of cable modem networks should also follow the same procedure with the DOCSIS network management systems used to remotely manage CPE devices on their networks.
Edited by Erik Linask