By now, everyone should be aware of two things related to IoT devices. The first is that these devices are being deployed everywhere, with no sign of slowing down. They range from wearable devices, smart appliances, and networking devices connecting to common IT networks, to small, lightweight devices (such as sensors) that have been integrated into critical infrastructure using common IT protocols, as well as Medical IoT devices that monitor patients or deliver vital medications or treatments.

The second is that many of these devices are notoriously insecure. Vulnerabilities ranging from passwords hard-coded into firmware to junk code that can be easily exploited are only half the problem. The other is that most of these devices don’t run on normal operating systems, so patching or updating flawed software is difficult if not impossible.

Professional threat researchers, including our FortiGuard Labs team, began warning manufacturers and users several years ago that IoT vulnerabilities would be the source of the next big menace – long before IoT-based botnets began appearing last September and made that plain to the world. The most notorious of these, launched at the end of the summer of 2016, was Mirai. It was responsible for the largest DDoS attack in history. This botnet, built using millions of compromised IoT devices, was used as a weapon to bring down a large chunk of the Internet, including the websites and services of some of the world’s largest online vendors and service providers.

Six months later, we saw the launch of the Hajime IoT-based botnet, which was the evolutionary successor to Mirai. While it was built on the same basic foundation, it was significantly more sophisticated. Unlike Mirai, which was basically a blunt DDoS instrument, Hajime included a variety of built-in sophisticated cybertools. Hajime was also cross-platform compatible, meaning that it was designed to support five different platforms, included a toolkit with automated tasks, as well as a dynamic password list that could be remotely updated. In addition, it could also download other code, like brickerbot.

Hajime also used a lot of automated tools. For example, to evade detection, Hajime was designed to be less noisy. One technique it used in order to stay under the detection radar was to monitor and learn traffic and behavior thresholds so that it could effectively mimic acceptable human behavior. But one of its most alarming features was an embedded tool designed to remove rules. For example, it would attempt to remove firewall rules used to detect this kind of malware.

It would also target ISPs and MSSPs by identifying CPE devices and their CPE LAN Management Protocol and attempt to remove the rules that allowed the CPE device to talk to the service provider. Imagine a service provider with millions of devices that all go dark, and with no heartbeat to see, control, or manage these devices. This was a nightmare scenario that would not only deny services, but also flood help desks with calls from frustrated customers.

And now, just a year since Mirai, a new, even more sophisticated IoT-based attack called Reaper has been discovered. Reaper bears some similarities to Mirai, such as its use of some of Mirai’s code to infect IoT systems. Mirai was extremely effective at compromising a high number of devices to form an IoT-based bot network, so there was little need to reinvent that wheel. However, Reaper shows some significant evolutionary advances over both Mirai and Hajime. For example, samples we have analyzed have revealed that it has been armed with exploits covering nine different known vulnerabilities spanning a variety of IoT vendors, whereas Mirai focused exclusively on password cracking. Vendors targeted by Reaper include NetGear, Linksys, GoAhead, and Avtech, among others

Reaper is also especially concerning because it is built around a Lua engine combined with additional Lua scripts in order to run its attacks. Lua is an embedded programming language designed to enable scripts to run. So, even though it appears that the current Reaper threats we have seen to date have been benign, its flexible Lua-based framework means its code can be easily updated to include more malicious attack options. Which clearly makes it another step forward in the evolution of IoT-based attacks.

Coupled with some basic machine learning or AI, for example, future generations of this malware should be able to recognize virtually any device it encounters, search for a related vulnerability, and then select the appropriate exploit for it from a library of solutions. Or, even be able to develop a custom exploit.

And as emerging technologies like swarm intelligence begin to be integrated into botnet configurations, evolving them into something we call Hivenets, multiple infected devices will be able to work together as a single intelligent system. This intelligence would also enable this intelligent system to quickly identify new devices any member of the Hivenet encounters, probe for vulnerabilities, modify or build exploits, and then, once an exploit solution is discovered, share that intelligence with the rest of the swarm. The results of such an intelligent attack system would be potentially devastating.

Solution

The problem of vulnerable and compromised IoT devices isn’t going to go away on its own. While there are efforts underway to push manufacturers to accept responsibility for the security of the devices they sell, and various legislative bodies are considering imposing a consumer-friendly security rating system, these are still some ways off.

In the interim, here are a few things you can do to protect yourself from IoT-based attacks:

1.  Inventory control: Keep track of the kinds of IoT devices on your network. This should apply both to corporate-owned assets as well as those brought onto the network through BYOD protocols.

2. Control access: Impose strict controls on what devices can access your network. Remember that wireless access only applies to some IoT devices. You will need to also have protocols in place for Bluetooth connections, radio-frequency-based devices spanning nearly a dozen different protocols, and smart devices hardwired into your network. Many of these devices access the network behind the firewall.

3. Segment your IoT traffic: Once you can identify and control access for IoT devices, keep your IoT traffic separate from your other network segments to limit exposure and the spread of malware.

4. Monitor outbound and lateral IoT traffic: Baseline the normal traffic of your IoT devices, then monitor for aberrant behavior so rogue devices can be automatically identified and quarantined.

5. Practice good security hygiene: While it can be difficult or impossible to patch all your IoT devices, there are still many that can be upgraded or repaired.

• Establish a routine for checking for updates and applying patches when they become available. Automate this process as much as possible.
• Replace vulnerable devices when new versions with better security become available.
• Establish IoT security protocols, such as making sure your AV and IPS solutions include IoT signatures.
• Implement Sandboxing to discover unknown malware and compromised devices.

What to do about Reaper

While it was initially reported that Reaper had infected up to 1 million devices, the research community, including FortiGuard Labs, has not seen any activity supporting those numbers. Instead, most professional researchers estimate the number of infected systems to be closer to 10,000 to 20,000.

Reaper scans the internet looking for devices to infect. To detect this behavior, look at the logs on your FortiAnalyer, FortiSIEM, FortGate, or your IoT devices for typical recon scans against your external facing devices.

Fortinet detects Reaper payloads with the following AV signatures:

• Linux/Luabot.A!tr.bdr
• ELF/Iotreaper.C!tr.

Fortinet also detects Reaper’s exploits against some of its targeted IoT devices with the following IPS signatures. (Given the flexible nature of its framework, however, please note that this list could easily change.)

• WIFICAM.P2P.GoAhead.Multiple.Remote.Code.Execution
• JAWS.DVR.CCTV.Shell.Unauthenticated.Command.Execution
• NETGEAR.ReadyNAS.upgrade_handle.uploaddir.Command.Injection
• VACRON.CCTV.Board.CGI.cmd.Parameter.Command.Execution
• DLink.Devices.Unauthenticated.Remote.Command.Execution
• Avtech.Devices.HTTP.Request.Parsing.Multiple.Vulnerabilities
• NETGEAR.DGN1000.CGI.Unauthenticated.Remote.Code.Execution
• Linksys.Routers.Apply.CGI.Parameters.Multiple.Vulnerabilities
• DLink.DIR.800.Series.Remote.Command.Execution

Protections include removing access to any management features from the WAN interface, and ensure tight access controls for access to the internal network. Limiting general and unexpected connections from non-edge IoT devices should curtail any installation attempts. Restricting IoT devices to only making outbound requests from the LAN should also be effective at curtailing or neutralizing installation (but can be problematic setting up).

Note, however, that if a device becomes compromised by Reaper, then all defenses should be considered ineffective and device quarantining, strict segmentation of IoT traffic, and careful monitoring of outbound and lateral traffic need to be implemented.

Sign up for our weekly FortiGuard Labs intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.