Hey kids! Want to launch a distributed denial of service attack using the Internet of Things for fun or profit? It’s simple. Just follow these easy steps.
- Download the Mirai source code, freely available, well, everywhere.
- Wreak havoc.
It shouldn’t be so easy to hack into “smart” devices, so why is it?
Because technologically speaking, many of them are dumb. When I say “dumb” I mean they have such features as universal hardcoded passwords and open telnet. WHAT?? Yep. That’s how Mirai works: It looks for various combinations of “admin, 1234” across devices to gain access.
It’s the simplest of hacks. Or what about device companies that purposely and explicitly build into their products debug apps listening on a TCP or UDP ports that accept a packet like “BackdoorCmdLine” to roll out the red carpet for hackers?
Like all security issues, IoT devices are going to have their share of vulnerabilities, and like most glaring security issues, either lazy programmers cut corners or unlazy programmers cut corners for the sake of consumer usability. That is when you end up with a botnet of several hundred thousand video cameras and DVRs that can take down half of the internet for a day or so.
In the recent October 21 attack on Dyn, IoT devices were to blame. A popular malware tracker shows there are 1.3 million Mirai-infected devices and counting. Even if device makers didn’t rely on a single DNS for all their traffic, (which is maybe a bad idea) it wouldn’t change the fact that the devices themselves are infected. And so what about the provenance of these devices? Surely the device makers can self-police and implement greater security to solve the problem.
Think about how many consumer smart devices are right now rolling off the line in thousands of factories that are driven by the bottom line when the product leaves the shipping dock. After that? Who knows? Who cares?
What is the solution?
Right now, the network is the best line of defense. In the Mirai-infected example, the best idea, public outrage aside, is for the ISPs to block infected devices. This would be possible through their updated policy document: “We do not allow malware-infected devices on our network.”
Consumers would go apeshit, which would force them to bring it up with the manufacturers, there would probably be class-action lawsuits, and probably eventually a congressional hearing about what kind of onerous law to put in place.
If you think that’s an unlikely scenario, think forward to a bunch of wirelessly-connected autonomous drones delivering packages all over, say, New York City, that get hacked and turned into a swarm of airborne weapons of mass destruction. That’s the kind of example that generates intense interest in security.
But practically speaking, nothing is made in the U.S., so what is this hypothetical law going to do? Place security restrictions on imports, that’s what. And how are you going to do a code-level review of every device that gets sold here? You’re not.
Bricks Without Mortar
This is simply a function of where we are today. Building a new industry is like building a brick wall: The “bricks” in the IoT are the big things, like chips and operating systems and devices and platforms and networks. You can only stack your bricks so high before you need the mortar in between them to strengthen them into a defensible wall. The “mortar” of the IoT is a combination of ID management, device management, security, proximity, analytics and even policy, all of which become increasingly more important as scale increases.
The first DoS attack didn’t happen on the consumer Internet until the year 2000, long after the Internet itself was in full swing. An entire internet security industry grew up since then.
The IoT benefits from the ability to learn from analogous examples from the consumer Internet, so even if it looks like we aren’t exactly doing that, we do know, sort of, what needs to be done. We just have to hurry up and do it. Because the attacks we saw last week are what happens when you've got too many bricks and not enough mortar.