Mirai FAQ: When IoT Attacks

Last updated at Thu, 14 Dec 2023 23:01:14 GMT

Update: Following the attack on Dyn back in October, there is some speculation over whether a similar Mirai-style attack could be leveraged to influence the election. This feels like FUD to me; there doesn't seem to be a mechanism to knock out one critical service to kick over enough state and county election websites, Dyn-style, to make such an attack practical. It could potentially be feasible if it turns out that a lot of city, county, and state websites are sharing one unique upstream resource, but without knowledge of that being the case, worries about a surgical DDoS against the election seems more like hyperbolic speculation than anything else.

Unless you've been blessed with some long DNS TTLs, you probably noticed that some name-brand chunks of the Internet seemed to go missing on Friday, October 21, including Twitter, GitHub, and Pandora. Over the weekend, it became clear that this was another (yes, another) IoT-based denial-of-service attack, where many thousands of devices with direct access to the internet participated in a wide-scale attack on DynDNS, unbeknownst to their legitimate owners, as part of a botnet called "Mirai."

What is Mirai?

Mirai is a botnet — a malicious software application that is designed to gain unauthorized access to Linux-powered devices and conscript them into a distributed infrastructure of clients. Once enlisted, these machines have the capability to perform a variety of denial-of-service attacks against a target dictated by the attacker. In the Friday attacks, the target was Dynamic Network Services' managed DNS service (heretofore referred to as simply "Dyn").

How does Mirai work?

In order to gain access to IoT devices (and really, any Linux computer running telnet), Mirai does not exploit any software vulnerabilities. Instead, it simply tries to guess telnet login credentials for computers accessible via telnet from the internet. Some of these username and password combinations are pretty bad choices for anything hanging out on the internet, like "admin / admin" and "root / root," and some are associated with specific video surveillance systems, like "root / juantec" and "root / klv123." The complete list of credentials is published at GitHub, as part of the Mirai source code.

Once compromised, software is installed on that device that can kick off a variety of attacks as described in the source code, such as UDP or ACK flooding, DNS water torture, HTTP request flooding, and other volume-based attacks.

In the most recent attack, Dyn's services were knocked offline. Since Dyn provided DNS services exclusively for some major services, that meant that we could no longer figure out "where" on the Internet these services lived.

How big is Mirai?

Given the vagaries of internet-wide scanning, it's hard to say how many devices were involved in the Mirai botnet, but the order of magnitude looks to be in the hundreds of thousands range. For a sense of scale, we can look at the recent scans from the National Exposure Index, where we found 15 million apparent telnet servers. We also peeked at a recent Sonar scan of HTTPS certificates, where we found about 315,000 web servers providing a certificate associated with Dahua Technologies, one of the vendors of video surveillance systems that was targeted in the attack. Not all of these telnet servers or video systems are going to be vulnerable, and there are other vendors associated with the attack, but this "hundreds of thousands" figure seems about right.

With all these compromised and compromisable devices, Mirai is capable of sustaining hundreds of gigabytes per second of traffic against a chosen target.

What's Being Done to Fix This?

For this immediate issue, it looks like the heroic engineers at Dyn have been busy reconfiguring their routing in order to be able to weather further attacks. At the same time, their downstream customers are implementing more robust fall-back strategies with other DNS providers. This is not a vote of no confidence against Dyn, of course; disasters and outages happen, and it's only prudent for name-brand services to have fall-backs like this in place.

The fundamental problem of having many, many thousands of insecure devices on the internet remains an issue, though. BCP38 describes techniques for filtering traffic at the edge of an Internet Service Provider's network, which helps defend against DoS attack schemes that generate packets with forged source addresses, but this isn't particularly helpful against the threat demonstrated by Mirai.

What Can I Do?

First and foremost, you should not be exposing your telnet ports to the internet. Period. Full stop. End of story.

It doesn't matter how much you think you need unfettered access to telnet over the internet, you need to stop it. Now. There are much better alternative protocols, such as SSH for shell access, and HTTPS for GUI-based control, both of which offer modern security features like encryption and mutual authentication. Don't merely change your telnet access credentials; stop using them, and make it impossible for others to control your network bandwidth via telnet.

If you rely on a cloud service — and who doesn't, these days — then you should find out what their redundancy plans are in the event of not only an attack on their infrastructure, but an attack on their upstream providers. Reputable providers are quite forthcoming with sharing this information with their customers, and usually publish real-time status pages, like this one.

The Post-Mirai Reality

Unfortunately, the cost associated with exposing insecure devices is not just borne by the operators of these devices. While it may be creepy to know that anonymous, internet-based attackers can access your home or office camera feeds, the attacker in this case was not interested in those video streams at all. Instead, the attacker only cared about the processing power and network bandwidth of the vulnerable device.

Solving for externalities like this is extremely difficult, but given our track record, we know that technology professionals are pretty gifted at coming up with novel solutions to seemingly intractable problems. I'm confident we can come up with a solution that protects IoT devices, protects the rest of the network from those IoT devices, and still manages to preserve the open and distributed nature of the internet.