Mirai, DDoS Attacks, and the State of IoT Security

By Chris Williams


A malware package designed to infect network-connected devices that lacked security, gaining remote access to a large number of hosts (bots) for the purpose of conducting distributed denial of service attacks. Hackers control infected bots from a centralized platform or control server—this control server can issue arbitrary commands to the entire botnet, send additional malicious payloads (malware) to individual bots, and more. The “Mirai” malware infects a wide variety of improperly secured smart devices, leading to renewed criticism of the IoT and its often lackadaisical security standards; for instance, attackers can potentially compromise web cams and digital video recorders based on publicly known factory default credentials. Manufacturers often hard-code these credentials so that they cannot be changed during configuration of the device.

Mirai’s source code was released into the wild in October 2016, following a series of attacks in which Mirai-powered botnets proved devastatingly effective. Among those targeted were noted Cybersecurity blogger Brian Krebs (KrebsOnSecurity.com) whose site was protected by Cloudflare’s DDoS mitigation services at the time. Subsequently, attacks on the Domain Name Service provider Dyn were conducted, at least in part, using Mirai-powered botnets; this series of attacks caused major outages across a number of high-profile retailers and service providers.

Device Vulnerabilities

Vendors that manufacture “smart” devices traditionally have not put security on the forefront of their design goals; many such devices, for example, transmit credentials in clear text—thus being susceptible to potential vectors such as eavesdropping, sniffing, and man-in-the-middle attacks. Many more devices ship with weak default passwords which end-users are never required to update. Looking up these credentials is possible via a simple Google search thanks to a number of Internet resources (plus the manufacturer’s own documentation, in many cases). Additionally, not all vendors publish regular updates to address security issues, and those that do generally do not make such updates mandatory. Instead, manufacturers expect end-users to keep track of and install the latest firmware—not a realistic expectation for a large portion of these products’ target audiences.

Although there is little one can do to prevent sniffing or MITM exploits (HTTPS is not even an optional configuration setting on most of these devices), protecting the networks in which they reside is perhaps more feasible. In many cases, this entails disabling the SSID broadcast, setting up MAC filtering, and implementing a secure WPA-2 key—all measures which will keep honest people honest but won’t necessarily deter a sophisticated attacker. Securing routers and implementing network-based firewalls can mitigate attempts to locate and compromise IoT devices from the Internet. Regarding the weak default credentials, best practice is to change any vendor-supplied passwords where possible (not always an option, as mentioned above). Make sure the new credentials meet with standard complexity and length requirements as well. Users should also visit device manufacturers’ websites and download/install updates.


Several components comprise the malware packages used to create botnets. Included are: a backdoor, with which the attacker can gain remote access to an infected host, and various payloads which can then be executed against that host, such as keyloggers, sniffers, adware, spyware, etc. An attacker can, from a remote location, execute arbitrary commands on the victim, as well as use them for a variety of other criminal activities, from spamming to participating in DDoS attacks. In the latter-most case, an attacker will direct thousands, tens of thousands, or even millions of infected hosts to send requests to a specific target.

The goal is to overwhelm both its processing power and its network bandwidth such that it crashes, stops responding, or at least becomes unreachable for the duration of the attack. Attacks can be relatively brief, just long enough to make a point, or sustained. Sustained DDoS attacks can last indefinitely, at least until the hackers reach some kind of objective (usually ransom, occasionally a political goal).

Botnets consist of so many victim hosts that it is impossible to monitor and direct them all individually—hence the need for control servers that can communicate with the entire botnet simultaneously through a single administrative console; this gives attackers the ability to launch highly coordinated and effective attacks which would otherwise not be possible.

Reflected and amplified DDoS

Current DDoS attack techniques exhibit a high level of sophistication. It is much more than simply pointing bots at a target and ordering them to start sending malicious traffic until that target goes down. Instead of each participant in the attack having to interact directly with the victim, hackers use reflection techniques to conduct these advanced attacks. Reflected attacks exploit a third party to “bounce” the malicious traffic from, thus concealing the identities of attacking hosts as well as that of the command server. Additionally, amplification techniques significantly increase the payload of malicious traffic which hits the target.

An example of an amplified and reflected DDoS attack:

  • Attacker botnet A sends a barrage of specially crafted DNS queries to host B, a DNS server
  • These queries use a spoofed IP address and appear to be coming from host C, which is the actual target of the attack
  • Host C received responses from Host B instead of the attacking botnet
  • Changing the type to “ANY” or using DNS extensions which increase the size of the DNS response (for instance encryption, which adds additional overhead to each packet) significantly inflates the amount of traffic
  • The extreme volume of requests floods Host C so that it cannot consistently respond to legitimate traffic—it begins refusing connections, drops packets, and may even crash

DNS infrastructure: single point of failure

The Friday, October 21st attacks against managed DNS provider Dyn brought down Etsy, Twitter, PayPal, Pinterest, and dozens of other clients for several hours. The scope and sophistication of the attacks caught many off guard, as there had not previously been large-scale attacks of this nature against the DNS infrastructure itself. Additionally, these events illustrated a weakness that had previously received very little (if any) attention: managed DNS without a layer of additional redundancy is still a risk. Most of the companies affected by Dyn’s managed DNS outage did not have any form of back-up domain name resolution strategy in place—no secondary provider was available on “stand by” in case of such an event. Thus, managed DNS became a single point of failure for these companies and the sites/services they offer, and the failure (or lack of) business continuity planning was very evident in retrospect.

The volume of traffic, from a network throughput perspective, was among the largest in Internet history. This event was significantly larger than previous DDoS attacks, which is alarming since they have been steadily becoming more sophisticated over the last few years. Experts estimate the total traffic generated by both the Krebs and Dyn attacks at 600-700 Gbps, which is enough to overwhelm just about any target, even those using DDoS mitigation services such as Cloudflare. (For reference, most DDoS attacks still generate < 10 Gbps.) We can conclude from this data that DDoS mitigation alone does not eliminate the risks satisfactorily.

Pressure device manufacturers

As widely-publicized DDoS attacks using botnets become more common, including those directed at public DNS infrastructure, consumers and security experts alike are asking, “How can we make these products more secure?” There is no clear answer, however, given the lack of industry-wide standardization. We do not presently have way to force these vendors to improve the security of their devices.

One can hope that a coalition of vendors, retailers, experts, and consumer advocates will come together and author an enforceable, open source compliance standard. Or, we may see legal intervention on the part of the U.S. government. (Not likely, however, given past reluctance to formulate nationwide security standards outside of federal agencies and other specific contexts like educational institutions). Short of either happening, consumers can still opt to put financial pressure on these vendors. If non-secure products fail to continue selling, vendors will move to make their products more secure in the future.


Copyright © 2017 ParadoxPrime IA, All rights reserved

Leave a Comment

Your email address will not be published. Required fields are marked *