The malware code behind the IoT botnet responsible for the recent, massive DDoS attacks has been released. And although there are lessons to be learned from it, experts suspect the release will cause more harm than good.
The Mirai botnet malware was released in the hacking-community website Hack Forums by a user named Anna-senpai, who claims to be the author of the code. Mirai was the botnet malware used in the distributed denial-of-service (DDoS) attack that took down the site of infosec journalist Brian Krebs and was clocked at 620 Gbps. Both names Anna and Mirai reference Japanese anime. Anna-senpai adopted the honorific senpai because the hacker sees himself or herself as a teacher for those wanting to use the Mirai malware. But the Japanese word for teacher is sensei, not senpai.
Anna-senpai did not take responsibility for that attack and said it was time to leave the game. In the forum post, Anna-senpai wrote, when he or she first got into the DDoS industry, “I wasn’t planning on staying in it long. I made my money,” and now it’s time to get out. “So, today, I have an amazing release for you. With Mirai, I usually pull max 380k [380,000] bots from Telnet alone. However, after the Kreb [sic] DDoS, ISPs [have] been slowly shutting down and cleaning up their act. Today, max pull is about 300k [300,000] bots and dropping.”
Anna-senpai went on to describe the system requirements for running the malware and tips for configuring the Mirai botnet malware. Anna-senpai claimed someone should be able to set up a working botnet in under one hour with the scripts and code provided.
Experts said the malware does take skill to implement properly, but Rick Holland, vice president of strategy for San Francisco-based Digital Shadows Ltd., said the “code release is particularly dangerous, since it once again lowers the barrier to entry for threat actors.”
“This release will cause more harm than good. The good that will come out of it is that it will raise awareness around denial-of-services attacks,” Holland told SearchSecurity. “Of course, awareness isn’t a security control and won’t be able to prevent DDoS attacks. Organizations will need to move from awareness to actual mitigation.” MalwareTech said on Twitter it might not be so easy for threat actors to get started with the code.
Jean-Philippe Taggart, senior security researcher at Malwarebytes, based in Santa Clara, Calif., said this opens the possibility of more large botnets, as well as the possibility that “a less experienced attacker might accidentally damage these IoT [internet of things] devices through poor coding and lack of experience.”
“Mitigating against an IoT DDoS is difficult, as these machines can have legitimate IP addresses, making filtering bona fide traffic difficult,” Taggart told SearchSecurity. “A more advanced threat actor could also patch these IoT devices in such a way as to only allow them to be accessible by them.”
Gunter Ollmann, CSO of Vectra Inc., based in San Jose, Calif., said the Mirai IoT botnet malware could be modified in unknown ways in the future.
“The botnet agent is particularly versatile and has a number of precoded install packages for a wide variety of common system-on-chip platforms,” Ollmann told SearchSecurity. “This means that copycat botnet operators will not need to learn or understand the differences of the platforms, but can target them anyway; in essence, dumbing down the skill level needed to launch such attacks going forward.”
Anna-senpai said the Mirai malware propagated by brute-forcing IoT device passwords via Telnet in a way that is 80 times faster and 20 times less resource-intensive than traditional botnet malware Qbot.
Ollmann said one impressive feature of the malware was the ability to use multiple IP address to bypass port exhaustion in Linux.
“The purpose here is to increase the total number of outbound connections that can be created and to overload the receiving device by exhausting their number of inbound connections, which will likely be maxed out at 65k [65,000] for a single port or protocol,” Ollmann said. “DDoS caused by connection saturation is often preferred as an attack vector because it doesn’t require high volumes of traffic. Therefore, a DDoS state can be achieved using a smaller number of attacking devices and requires less bandwidth to achieve the desired goals.”
Jerry Gamblin, lead security analyst at CARFAX, based in Centreville, Va., said the Mirai code highlighted troubles with users leaving the default passwords on IoT devices.
“The fact that devices are still running Telnet should be shocking, but, unfortunately, it isn’t,” Holland said. “The same is true for admin:admin credentials. All too often, we see nonexistent or poor security on these types of devices.”
Ollmann said this is a design flaw that IoT makers will have to consider in the future.
“All such devices need to ship with some kind of default credentials, so that the purchaser can configure the device for their own network environment. The real problem is that the owners are negligent in not changing these accounts after installation,” Ollmann said. “Future vendors of products like this should perhaps adopt practices which force the owner of the device to change the default password before they’re allowed to proceed further with configuration — and also to do some basic password integrity checking to prevent common or reused passwords. This would be pretty easy to do.”
Ollmann suggested a few basic security procedures to mitigate risk.
“The obvious advice for reducing the probability of compromise today is change the default admin credentials on the IoT device, or change or remove any other nonadmin credentials on the device,” Ollmann said. “And ensure that the IoT device sits behind a firewall and that the firewall is configured to drop by default all protocols not absolutely required for the operation of the IoT device.”
Holland said the first step toward mitigating the risk of having your IoT devices used in a DDoS botnet is to be aware of your IoT footprint.
“Far too often, organizations aren’t aware of the actual IoT inventory within their environments. The next step is to understand the available configuration settings of the devices that are deployed. These could be quite limited, given the lack of security practices within IoT,” Holland said. “Ultimately, we will need to apply pressure to IoT vendors that security must be built into the devices, because unlike many traditional IT assets — like endpoints or servers — bolting on security isn’t an option.”