The IoT Botnet Wars: How to Harden Linux Devices from DoS Attacks

An internet service provider in Southern California, Sierra Tel, experienced widespread outages due to this battle. Its Zyxel modems were victim to BrickerBot and another malware, possibly Mirai. It took nearly two weeks to replace all customers’ modems. This was the same modem model that Mirai infected and took out a German ISP’s network, an outage that affected a population size larger than San Francisco.

Hajime is another Mirai-like worm that has been spreading during the past several months with similar goals as BrickerBot: Thwarting malware such as Mirai in exploiting poorly secured IoT devices to do their bidding. Hajime accesses devices by scanning the internet and trying a set of default credentials, and then injecting a malicious program.

However, Hajime tries to harden the security of these devices by blocking four ports that Mirai is known to attack (23, 7547, 5555, 5358) to deflect further subjugation for DDoS attacks or even Bitcoin mining. Unfortunately, once the Hajime-infected device reboots, it returns to its vulnerable state with these ports open. Thus, Hajime is merely a temporary band-aid. The only real cure is to deploy a software update with new credentials.

Leading computer-security expert Gene Spafford said “The only true secure system is one that is powered off, cast in a block of concrete, and sealed in a lead-lined room with armed guards—and even then I have my doubts.” While this may be true, basic security hardening would have helped protect against many of the attacks from malware targeting Linux devices. We will cover some basic system-hardening concepts in the context of these attacks, including closing unused open network ports, intrusion detection systems, enforcing password complexity and policies, removing unnecessary services, and frequent software updates to fix bugs and patch security vulnerabilities.

Basic Security Would Deflect Malicious Mirai Malware

The Mirai malware caused major outages across the internet by attacking DNS provider Dyn’s servers. The malware infected vulnerable devices by using open Telnet ports to target ARM, MIPS, PPC, and x86 devices that run on Linux. It scanned the internet for the IP address of IoT devices and identified vulnerable ones by using a table of more than 60 common factory credentials. As the malware is stored in memory, the device remains infected until it’s rebooted. Even if the device is rebooted, it can be re-infected in minutes unless the login credentials are changed immediately.

Once the device is infected by Mirai, it tries to remove any competing malware and sits idle long enough as a way to avoid detection from security tools. After an extended period, it contacts its Command and Control server for further instruction.

Enforcing complex password policies instead of keeping published factory-default credentials would have helped prevent Mirai from enslaving these devices. The challenge of securing consumer-facing IoT is that manufacturers are relying on consumers to change the password from a factory-default login, which typically requires the process of logging into the admin panel and manually changing the password.

Will Dormann, senior vulnerability analyst at the CERT Coordination Center, says “Instead of hard-coding credentials or setting default usernames and passwords that many users will never change, hardware makers should require users to pick a strong password when setting up the device.”

The ability to deploy software updates is another mandatory capability to fix bugs and patch known security vulnerabilities. In the software-development book Code Complete, author Steve McConnell states that there are 1-25 bugs and vulnerabilities per 1,000 lines of code, where the variable is determined by the practices of the team.

Consumer electronics, such as many of the devices listed on Krebs (see figure), are at the high end of the scale due to the higher focus on features and time-to-market with little security oversight. Many of these devices are already running on thin margins, so having an over-the-air (OTA) update capability with minimal development effort by the manufacturer is an important consideration.

These are the known infected devices by Mirai published on Krebs on Security.

“When it comes to software updates, automatic updates are good,” says Dormann. “Simple updates that notify the user and require intervention are okay. Updates that require the user to dig around to find and install manually are next to worthless. Devices that don’t have updates at all are completely worthless.”

The software update process itself is complex with many security considerations to take into account to protect against things like man-in-the-middle (MitM) attacks. There is also the danger of a device bricking because it loses power mid-update or has intermittent network connectivity. For this reason, updates need to be atomic, meaning the update fully completes or not at all (no partial updates)—even in cases of power loss at any time during the update process.

Manufacturers have open-source options available to deploy software updates to devices. SWUpdate is a well-known and flexible open-source Linux update agent, while Mender.io (disclaimer: the open-source project I am involved with) provides an end-to-end solution (both agent and management server) to deploy OTA updates fleet-wide. Software updates for IoT has become a hot topic, even getting the attention of the U.S. government and Congress. And Bill Woods from the Atlantic Council international think tank noted that two billion IoT devices currently out there have a 12-year-old secure-shell (SSH) flaw that enables them to be turned into a botnet.

Vigilante Hacking

In the early 2000s, the Blaster worm was spreading on computers running operating systems such as Windows XP and Windows 2000. DDoS attacks were launched in 2003, causing damages totaling hundreds of millions of dollars. The Welchia worm was a response to Blaster, which exploited a vulnerability in Microsoft’s remote procedure call (RPC) service much like Blaster. However, after infecting a system, it would instead delete Blaster if it existed there, and then tried to download and install security patches from Microsoft that would prevent further infection.

Similar to Welchia, Hajime is going head-to-head with Mirai and its malicious variants to minimize the damage they can do. Hajime appears to be a much more advanced botnet, taking steps to camouflage its processes and files, making detection of it much more difficult. And it’s much more refined in cycling through credentials as it parses through information to identify the device manufacturer and uses their combinations by default. For example, when it attacked the MikroTik router, Hajime attempted to log in initially with the factory-default according to MikroTik documentation, and reduced the number of invalid passwords as it tried to reduce the chances of being blacklisted.

Hajime closes known network ports that Mirai exploits to secure those devices—a strategy that device manufacturers should use: Closing unnecessary ports reduce their attack surface. Intrusion detection systems (IDS) are also helpful in monitoring unusual network activity. There are two types of network IDS: Signature detection and Anomaly detection. Many open-source solutions are available; Snort and Suricata are popular options.

BrickerBot is the first malware of its kind whose goal is to cause a PDoS by bricking devices not fully secure, with the seeming goal of removing them as potential victims of malware that will enslave them for DDoS attacks. There have been multiple versions of BrickerBot, and the suspected author of it claims to have bricked over 2 million devices. BrickerBot 1 targets devices running Linux with BusyBox and an exposed Telnet service. They usually have an older version of Dropbear SSH, and most were identified as Ubiquiti network devices running outdated firmware. BrickerBot 2 targets Linux-based devices more widely using a similar tactic of leveraging an exposed Telnet service with a default or hard-coded password.

The most secure software is one that is not installed. All services and applications running on your device should have a fundamental reason to be there. Adding unnecessary features increases the attack surface of your device and will, by definition, make it less secure.

Applying Basic Security Principles Will Help

Some fundamental system hardening can be the deciding factor on whether a device will be an actor in a DDoS attack or bricked. The results of vigilante hacking, like that of Hajime and BrickerBot, to combat the Mirai-driven DDoS attacks has generated much debate. There are arguments on both sides, with many insisting the amount of warnings on the lack of IoT security has fallen on deaf ears to manufacturers and consumers. And they argue that malware such as BrickerBot is a drastic but necessary measure to hit them where it hurts, and in the process, disable insecure devices from being a part of another DDoS attack.

There have been discussions online about a scenario where a consumer would be under warranty from the manufacturer if their devices do get bricked. The cost to the manufacturer to replace it would be too high to ignore security, forcing them to take security much more seriously.

A common counter-argument of vigilante hacking is “Why should the consumers be punished? Where is the line someone can cross to anonymously take the law into their own hands?” There is neither accountability nor certainty that the authors of BrickerBot or Hajime are completely well-meaning, or if there’s something nefarious the public has yet to discover. They also use the same techniques that black hats use, potentially leading to a proliferation of more malicious hackers.

Another potential scenario is a vigilante malware can brick a device that may potentially kill someone despite it being far from the original intent. Something as simple as an IoT refrigerator can be hacked and bricked without the owner’s knowledge. Subsequently, a person could proceed to unknowingly eat spoiled food that may cause illness and even death. And we know there are much more health-sensitive devices than a refrigerator being connected, such as connected cars, insulin pumps, heart implant devices, and much more.

In fact, the FDA recently became involved with Abbott Labs and its new acquisition, St. Jude Medical. St. Jude Medical devices had vulnerable software that allowed unauthorized external control, which could run down the battery or deliver a series of shocks at the wrong time (these devices included defibrillators and pacemakers). The latest correspondence indicates the FDA isn’t satisfied with parent company Abbott Labs’ response to the issue, despite St. Jude’s claims they had developed a software patch that could be applied to remove the vulnerability.

While we briefly covered some basic security-hardening concepts, it’s not comprehensive. But these should be a start to conform to industry best practice for securing IoT systems. These steps would have helped to protect or at least mitigate the effects of the malware discussed. Although there’s no silver bullet and security can never be “perfect,” it’s clear that implementing existing solutions to cover basic security around credentials, open ports, and enabling automated software updates will have a massive impact.