Threat Modeling the Internet of Things: Modeling Reaper

What a timely way to end this series on Threat Modeling the Internet of Things (IoT). An advanced thingbot, nicknamed Reaper (or IoTroop), was recently discovered infecting hordes of IoT devices. Reaper ups the ante for IoT security. It has a sophisticated C2 channel system and a Lua code execution environment (to deliver much more complicated attacks), and it comes prepackaged with 100 DNS open resolvers.

Researchers are tracking Reaper, even though it hasn’t launched any attacks yet. Let’s hope it’s like Conficker—an original virus/botnet that at its peak enslaved 10 million Windows boxes, but was never activated.

The discovery of Reaper in September 2017, in between the fourth and fifth installments of this series on Threat Modeling IoT, allows us to conduct an interesting thought experiment.

Could threat model have prevented Reaper?

Part 1 of this series put forth the premise that if we want to make a safer Internet of Things, we need to be doing more rigorous threat models. Part 2 introduced simple threat modeling, and Part 3 applied a threat model to a real-world IoT project. Part 4 discussed the mitigation for the most crucial component of IoT consumables, the authentication system.

Would the threat model presented in the series have mitigated Reaper? Let’s take a look.

Recall that a simple threat model consists of three steps:

1. Cataloging the assets at play.

2. Brainstorming the threats to those assets.

3. Scoring (prioritizing) those threats to create a mitigation strategy.

In Part 2, we mentioned that the OWASP IoT Project page contains a typical list of IoT project assets:

Recall from Part 3 of this series that you can use the STRIDE acronym to help you brainstorm threats to the asset list. STRIDE stands for: 

• (S)poofing of user identity

• (T)ampering

• (R)epudiation

• (I)nformation disclosure

• (D)enial of service

• (E)scalation of privilege 

Reaper is fascinating because it doesn’t just contain one infection threat vector; it contains at least nine! If we take those nine vulnerabilities that Reaper is using to infect IoT devices and put them in a table, we can see that the threat modeling we outlined in the previous articles could likely have uncovered them before distribution.

A quick glance at the table shows that all nine of the vulnerabilities include escalation of privilege. The vulnerabilities are described as remote code execution (RCE) or command injection, but either way it’s mostly the same thing: unsanitized input. If you were a developer of an IoT device, this table should be a wake-up call. Obviously, sanitize your input; but also, maybe it’s time to whitelist process execution. There’s probably no reason that the administrative web server should be able to launch telnetd, for example.

In the OWASP device assets above, the final device threat surface item is Update Mechanism. One interesting aspect of Reaper is that it has a non-aggressive infection schedule. If all manufacturers had a way to push updates to their devices, they might be able to get ahead of Reaper by closing the listed vulnerabilities before the devices could get infected. It’s nearly 2018; IoT devices need to have push updates, because if they don’t, they will eventually get co-opted into Reaper, or perhaps a more malignant thingbot.

Conclusion

There are a lot of lessons to be learned from the IoT thingbot named Reaper. Reaper is holding itself up as a blinky light in front of our faces, reminding the InfoSec community that we really need to get ahead of IoT madness. The manufacturers of many of these devices are making some rookie mistakes. Threat modeling is a decent first step toward improving the situation.

But given the number of IoT devices coming online every day, I suspect the situation will get worse before it gets better.