Default Passwords Are Not the Biggest Part of the IoT Botnet Problem
All businesses watch their bottom line. That’s unsurprising. Those that provide technology to consumers (whether IoT device manufacturers or your local ISP that provides your home router) are particularly careful about balancing product support with ease of use. That can lead to what the inventors no doubt believe is an ingenious method of determining passwords on such remote equipment or hardcoding “backup” defaults in case of emergency.1 A quick Google search will find a wealth of tools available to generate “passwords of the day” for devices that use them and pages detailing the methods used to generate passwords from MAC addresses and other device digital fingerprints for many others.
I do not doubt the good intentions of those who plant such risky code in devices intended to be installed in consumers’ homes. When things go wrong, it’s a costly proposition for technical support to spend an hour (or more) simply explaining to consumers how to find the user interface of their router to assist in troubleshooting. It’s much easier (and more cost effective) for them to provide an easy means of remote access that enables a smoother support experience for the customer.
The problem isn’t with intentions, it’s with execution. If you’re going to shoulder the responsibility for managing that device then, by gum, you need to manage it. Because one of the problems with today’s typical provider approach to customer-premises equipment is that it unwittingly fertilizes the soil in which Thingbots like Mirai can propagate like weeds. By configuring devices for remote administration and failing to push firmware updates when vulnerabilities are discovered, providers expose a growing base of vulnerabilities2 in management software that makes these devices easy pickings for those (attackers) who are on the hunt for them.
And growing it is. In conjunction with our data partner, Loryka3, F5 labs has been monitoring the ongoing hunt by attackers to find vulnerable IoT devices they can compromise. In 2016, the annual growth rate was a whopping 1,473%. Perhaps more frightening is the lack of similar growth in the number of networks from which attacks are launched. F5 Labs’ latest IoT report found that “from calendar Q3 to Q4, IoT attacks grew 110% while participating networks stayed relatively flat at 10%. Yet, the number of unique IP addresses participating within those ASNs grew at a rate of 74%.”
It’s easy to point the finger back at consumers, of course. They don’t change their default passwords on routers or Things, and they use insecure passwords. And we can’t even blame the non-tech populace. A Tripwire survey4 found “thirty percent of IT professionals and 46% of workers polled do not even change the default password on their wireless routers. Even more (55% and 85%, respectively) do not change the default IP address on their routers (making cross-site request forgery – CSRF – attacks much easier).” Given research that says, “forty percent of Americans said they were too lazy, found it to be too inconvenient, or they didn’t really care…”5 about following basic security recommendations, it’s no wonder the threat from Things is growing.
But then again, the 60% of us who do care can’t do anything about it, anyway. Our customer premises equipment (CPE) is locked down—except, apparently, to the digital dogs sniffing out our vulnerable routers and access points so they can join the latest botnet army. The problem isn’t always my password, but yours, Mr. Provider. The one you use to backdoor in when something goes wrong. The one I can neither change nor disable, because the equipment isn’t mine, it’s yours. So says your contract with me. That means it’s your responsibility, Mr. Provider, to lock down that equipment to prevent exploitation and subsequent hijacking of the router and potentially machines, and Things inside our home networks.
IoT devices need to be better tested and updated when patches and hotfixes are delivered to address the inevitable vulnerabilities. Really, when neither the firmware nor software has been updated in four years, even though there’s a two-year-old confirmed vulnerability (that’s been in the firmware for far longer), you’d think someone would get on that and fix it. Because I can’t, and neither can anyone else—except the provider or the manufacturer.
The threat of IoT botnets is not going away. Consumers will not be able to effectively provide any kind of defense if providers refuse to offer visibility into their equipment. And providers’ poor security practices with respect to customer premises equipment will, no doubt, only contribute to the growth in Mirai-like botnets.
Worse, this problem is widespread and affects IoT devices everywhere. Freeway signs, digital billboards. Parking meters, red light camera systems. Airport displays, drones, cars… the list of digitally enabled things we rely on is growing at a rapid pace. If manufacturers and providers who support those things apply the same security practices to those devices as they do the ones in our homes, we are in trouble. We move from “I can’t get on the Internet to binge watch my favorite series” to “I can’t get to the hospital because the traffic management system has been hijacked.” It moves from mere annoyance to potential disaster.
As consumers, we need to do a better job of protecting ourselves by following best practices—like changing our default passwords. But that’s only part of the problem, and both manufacturers and providers need to step up and actively seek to shut down this threat. Because the first point of entry into many networks is an ISP-provided and managed router, and right now it’s part of the problem.
Source link
lol
All businesses watch their bottom line. That’s unsurprising. Those that provide technology to consumers (whether IoT device manufacturers or your local ISP that provides your home router) are particularly careful about balancing product support with ease of use. That can lead to what the inventors no doubt believe is an ingenious method of determining passwords…