Can we extinguish the Mirai threat?

SmartNA PortPlus - High Performance Visibility Solutions that scale with your network.

The recent massive DDoS attack against DNS provider Dyn has jolted (some of) the general public and legislators, and has opened their eyes to the danger of insecure IoT devices.

Mirai threat

It is clear by now that it will take joint action by all stakeholders – users, manufacturers, the security industry, ISPs, law enforcement and legislators – to put an end to this particular problem, but it will take quite some time.

Theoretical stopgap solutions

In the meantime, quick solutions that could prevent Mirai-infested devices from participating in DDoS attacks are being sought.

A day after the attack, Invincea Labs’ Research Director Scott Tenaglia published research into the Mirai source code, and revealed the existence of a buffer overflow vulnerability that can be exploited to crash the devices (i.e. stop them from participating in the attack).

He even provided an exploit for it, which could be used by DDoS mitigation services to perform the action, but noted that it would work only for stopping HTTP flood attack (the attack against Dyn was DNS-based). Also, the exploit does not clean the devices of the malware.

Tenaglia says he and his colleagues are “not advocating counterattack, but merely showing the possibility of using an active defense strategy to combat a new form of an old threat.”

Software engineer Leo Linsky has set up a GitHub repository with the Mirai source code and is apparently working on a proof of concept nematode (i.e. a beneficial worm) that would plug the vulnerabilities (default telnet credentials) exploited by the Mirai malware.

“The idea is to show that devices can be patched by a worm that deletes itself after changing the password to something device-specific or random,” he explained. Unfortunately, that could also lock out the legitimate owners.

Linsky made sure to note that the repository is for academic purposes only, and the work he’s doing is meant to be tested only in closed research environments – not on live devices, and especially not on devices one does not own.

He invited other developers to contribute to the effort.