The Internet of Trouble: Securing Vulnerable IoT Devices
There are times when perception will coalesce around something that has been previously known, but not taken seriously. That is what happened recently with the distributed denial-of-service (DDoS) weaponization of the Internet of Things (IoT). Although government agencies have issued warnings about the potential problem of vulnerable IoT devices, nobody has ever really done anything about it.
Then, the KrebsOnSecurity site got hit with the largest-volume DDoS attack that had ever been seen. The botnet that enabled the attack was composed of low-level devices attached to the internet, like closed-circuit television (CCTV) cameras. These connected devices were harnessed on a massive scale to facilitate nefarious actions. The internet turned in a flash from a cuddly puppy into an attack dog with razor-sharp teeth.
The devices making up the botnet were not limited to one geographical area. For example, 18 percent were located in Vietnam. It became instantly obvious that this was a transnational problem that one nation could not control alone. To make things worse, the source code for the bot herder program used in the attack, Mirai, was released publicly in late September. That was like giving a loaded gun, metaphorically speaking, to script kiddies with no impulse control.
On the bright side, that release also encouraged security researchers to finally focus on the real IoT problem underlying Mirai.
Breaking Vulnerable IoT Devices
The Mirai release showed how all those bots came to be in the first place. The source contained a list of default usernames and passwords for these devices. The attackers used these to log in to the devices in a brute-force manner.
Devices usually contained a system on a chip (SoC) that executed the actual protocol connection to the internet. Vulnerable devices also had active login passwords that had not been changed from the default settings. Since the chip was integrated into some other product, the user may not have been offered the option to change the login info — perhaps the manufacturer found these default credentials useful in testing the overall device. However, these default passwords gave the attackers the elevated privileges they needed to carry out their criminal campaigns.
More than just the administrator panel is vulnerable here. Direct services, like Secure Shell (SSH) and Telnet, have shipped with default passwords and no way for users to change the state of the connection. “The password is hardcoded into the firmware, and the tools necessary to disable it are not present,” security researcher Zach Wikholm of Flashpoint told KrebsOnSecurity. “Even worse, the web interface is not aware that these credentials even exist.”
So even if the web-based administrator passwords get changed, other services will remain open and vulnerable. One device manufacturer told KrebsOnSecurity that since September 2015, its devices did not ship with the Telnet port open by default, and users were prompted to change passwords. These claims have not been independently verified. But of course, any device made before that date would not be affected by these changes.
Some manufacturers on the password list may be surprising: It’s not just middle-layer makers involved in this — the potential is far greater than that. Owners of low-level devices may not even realize they’ve been infected, since a botnet is usually not active all the time.
The U.S. Computer Emergency Readiness Team (US-CERT) even issued an alert about the current situation. The notice references a prescient FBI warning about IoT devices from 2015. Much of the FBI’s warning remains applicable today. Of course, the FBI recommended changing the default passwords on IoT devices at that time. The vulnerability of these devices to this sort of misuse was blindingly obvious.
Not so obvious was the FBI’s recommendation to disable Universal Plug and Play (UPnP) on routers. UPnP is the process whereby a device remotely and automatically connects and communicates on a network. It requires no authentication. Because UPnP is self-configuring when it is attached to an IP address, it can be exploited.
The Simple Service Discovery Protocol (SSDP) is part of the UPnP protocol standard. It allows devices to discover each other on a network, establish communication and coordinate activities. Softpedia reported that Akamai issued an advisory warning that attackers had “been leveraging SSDP to launch attacks that amplify and reflect traffic to their targets.”
Akamai also recommended blocking wide area network (WAN)-based UPnP requests to client devices and forbidding UPnP access to the internet unless needed. There seems, at least, to be agreement among two separate sources on some concrete mediation strategies.
Is Your Device Infected?
A defensive measure is always good to have. But what if you want to know if you already have been infected by an IoT bot?
You can use YouGetSignal’s open port finder tool to scan an IP address for open ports and determine whether you have already been infected by an IoT bot. In particular, scan the services SSH (22), Telnet (23) and Hypertext Transfer Protocol (HTTP)/HTTPS (80/443). Mirai and its ilk use these services for communication with the command-and-control (C&C) servers. If the ports are open and you have no idea why, there may be a problem.
How does one rid an IoT device of this problem? This situation calls for a manual hardware reset. First, depower the device. Then wait 60 seconds and repower it. Since the malware is memory resident, the shutdown kills it.
Maybe we can survive Mirai and the like this time. But the IoT will serve as a platform for future attacks in other ways. Some experts are calling for governments to take economic action against these kinds of vulnerable IoT devices. The European Union (EU) is even considering placing warning stickers on noncompliant devices to shame the manufacturers.
After a mass DDoS attack took down many sites on Oct. 21, there were mutterings of an autoimmune response. Some were thinking about weaponizing the Mirai code to seek out these devices and turn them into silicon goo. It’s a brutal response, to be sure, but one that may gain traction if these attacks persist and devices are not updated.
The problem is an economic one at heart. Economists label it an externality, where the effect of something is not limited to the two parties involved in a transaction. The device manufacturer wants to have the lowest price, something consumers desire as well. But a consumer doesn’t necessarily care if the device is used in a botnet, since the attack only affects an external party. There doesn’t seem to be an economic incentive to force manufacturers to adhere to a minimum security standard, even with governmental fingerpointing.
That has to change. All internet users should see the consequences of their decisions, even if they affect someone else. The entire internet community is — quite literally — connected. What goes around, comes around. Stakeholders must deal decisively with potentially toxic IoT devices or the problem will become overwhelming in the near future.
Climbing the Food Chain
Efforts like the MITRE Challenge IoT may end up finding an answer that works for everybody, but that doesn’t mean the problem is going away. For a long-term solution, authorities must implement an economic disincentive to discourage the use of security-blind devices.
Let’s think for a moment about specialized, IoT-resistant software. All network users would bear the cost of this potentially expensive software. Users forced to implement this software might be a vocal force, but they won’t sway those who simply want cheap devices. Those users put their own interests ahead of the community. You just can’t trust people to be altruistic — you have to go higher up the food chain to target the people profiting from these devices.
Somehow, authorities must apply effective economic pressure to device manufacturers to force them to stop selling this stuff. But it must be a coordinated effort among all regulatory bodies to ensure that the security-blind devices will not simply go out the back door instead of the front.