Optimising Mirai: A better IoT DDoS botnet?

The Mirai botnet was a game changer for IoT. Finally the irresponsibility and corner cutting of too many IoT vendors has resulted in some really serious consequences. It’s one thing stealing one person’s Wi-Fi key from their kettle, or pulling some sensitive data from the web service that the ‘thing’ consumes, but Mirai is different.

We’ve said many times previously that IoT would make for the perfect botnet: Easy to compromise, hard to patch and the owner likely won’t ever have a clue that they’re part of the botnet.

Mirai was beautifully simple but frankly, if we were creating a botnet with our existing knowledge of IoT insecurity, we wouldn’t have done it like that.

Disclaimer

This piece could be misconstrued as educating the DDoSser. It isn’t – they will already have worked this improved attack out for themselves. This article is about ensuring that everyone knows what to expect in future and to help mitigate the effects.

Onwards

It was very interesting that one of the most read blogs on our web site in recent months was about MVPower DVRs – we had found remote code execution, ~50,000 found on Shodan:
https://www.pentestpartners.com/blog/pwning-cctv-cameras/

Mirai looks for telnet available from the internet and checks for several sets of default credentials. The most common targets were Dahua IP CCTV cameras – these have known default credentials. Ideal.

Take control of the device and send some traffic to your victim’s web site. Doesn’t take much traffic per device when you have tens of thousands of devices under your control. Here are a few of the connection types it attempts:

#define ATK_VEC_UDP        0  /* Straight up UDP flood */
#define ATK_VEC_DNS        2  /* DNS water torture */
#define ATK_VEC_SYN        3  /* SYN flood with options */
#define ATK_VEC_ACK        4  /* ACK flood */
#define ATK_VEC_HTTP       10 /* HTTP layer 7 flood */

Except…

telnet isn’t that common to be found port-forwarded.

Why target telnet? That was an interesting choice as it’s easy to exploit, but port forwarding of telnet is way less common than web ports. It would also be easy for ISPs to block telnet.

If we were constructing an IoT botnet we would of course have chosen port 80. Port forwarded all the time, holes punched in the unwitting consumers firewall by UPnP.

So, to build your botnet using port 80:

We have one big advantage compared to the telnet attack – we can fingerprint the device from a small number of HTTP requests, and use a targeted attack against the device. Mirai just blasts each open telnet device with all 60 sets of default credentials. We’ve been running a Mirai honeypot for a few days and have seen multiple, noisy attempts against it.

This cuts down on the amount of noise the attack generates, decreasing the chance that our attacks are detected. There has been talk of blocking port 23 inbound to domestic broadband connections – bona-fide uses of it are rare these days – but there would likely be uproar if port 80 was blocked.

The difference between telnet and HTTP is that we don’t get shell access automatically. However, in our experience many DVRs and IP cameras have trivially exploitable command injection vulnerabilties, allowing us to gain root shell access.

The MVPower DVR /shell issue still has 29.5k exposed DVRs. Another issue leaves about 24k DVRS exposed. That’s over 50 thousand devices from just two vulnerabilities.

From this point we can take control of devices in exactly the same way as Mirai, running our bot to communicate with our C&C servers.

It may be slightly more effort to find these vulnerabilities, but a modest amount of work would allow you to keep on adding more and more vulnerabilities to your stock pile, allowing you to extend your botnet.

Mirai was being used to create DDoS attacks from something between 600 Gbps and >1Tbps. Pretty nasty stuff.

A killer IoT botnet?

One smart thermostat we have looked at has an insecure firmware update mechanism. Whilst the exploit is not as simple as connecting to port 80 and entering a default password, it allows us to take full control of the device. The kicker is how many of them there are – we estimate up to 300,000.

With just that one thermostat brand we’re confident one could produce a larger DDoS than Mirai has of late.

Scale that up a bit. More thermostats, more CCTV cams, more DVRs, more kettles, more IoT-everything, more brands, more countries.

IoT DDoS? You ain’t seen nothing yet.

What on earth can you do about this?

Firewalling isn’t enough, though obviously being completely sure that UPnP is off is important.

CSRF can attack a device behind the firewall.

CSRF can attack your router and thus the domestic firewall.

Don’t forget the local web service – most of the web applications running on these devices have a standard of security we were seeing in the mid 1990s – command injection, XSS, CSRF, missing authentication everywhere.

Network segmentation is clearly absolutely critical, but how do we expect the average user to implement IoT network segregation when most can’t even be bothered to change their Wi-Fi PSK or router admin password from the default that the ISP set?

Updates

Why do IoT vendors persist with presenting web interfaces on the local network? What’s the sodding point? The user is never going to use these, they’ll use the web service from their mobile app because it’s easy.

Get rid of local web interfaces completely. Force all config via the web service and the cloud.

Once the vendor has done that, they’ll have the ability to push firmware updates automatically rather than waiting for the user to (never) get round to it.

Of course, the update process needs to be secure too, but at least having the ability to push updates is a step forward from the current, dreadful status quo.

Conclusion

Here’s what you should do to mitigate against this:

• Always check and upgrade firmware where possible. Change the default passwords for all devices.
• When logging in, do not ask the browser to remember credentials, especially if it uses basic authentication.
• Disable UPnP on the router and be careful what ports you manually expose to the Internet.