Back in early 2014, I noticed that a remotely located router (a v1 Linksys E4200, to be precise) was flaky; sometimes it (along with WAN-accessible devices behind it, such as IP cameras) was "up," other times inaccessible. I initially suspected either a bad Ethernet cable between it and its cable modem partner, a faulty coax span feeding the cable modem, or a dying cable modem or router ... and given that I was 1,000 miles away from it at the time, debugging and fixing the problem was "challenging," to say the least.
However, thanks to timely industry coverage, I soon had another theory in hand. Courtesy of clever "crackers" that were port-searching IP addresses, identifying vulnerable devices and exploiting malformed CGI scripts that didn't properly validate login credentials before executing, a range of Linksys routers were being turned into "zombies" capable of issuing mass DDoS (distributed denial-of-service) attacks and the like.
In my particular case, the "zombie" transformation attempt didn't seemingly succeed. I suspect that this is because the malware worm (referred to "TheMoon") targeted v2 E4200 and successor Linksys routers, which contained twice the system RAM of my v1 unit. In my case, I hypothesized, the malware only caused the router to lock up and eventually auto-reboot, at which point normal function returned ... until re-infection occurred, that is. I "confirmed" the conjecture by changing the router's WAN access port from its "8080" default to "8888"... from that point on, sustained stable operation returned until I retired the router nearly two years later. And Belkin, the new owner of Linksys' router product line, finally fixed the problem with a firmware update ... 3.5 months after the vulnerability became widely known.
As any of you who've followed tech news in recent weeks (or recent years, for that matter) already know, the Linksys situation isn't an isolated case. A veritable army of Internet-connected equipment has been circumvented of late, due to vulnerabilities in its hardware, software or both ... "smart" TVs, set-top boxes and PVRs, along with IP cameras, routers, DSL, fiber and cable modems, printers and standalone print servers, NASs, cellular hot spots, and probably plenty of other gear that currently escapes me. Back in September, to quote one recent example, well-known security researcher Brian Krebs' website was taken down by his provider, Akamai, due to a mass DDoS attack (Google later shouldered Akamai's former responsibilities via its Project Shield initiative). In mid-October, an even more massive DDoS attack on key DNS provider Dyn repeatedly brought large parts of the Internet to its knees. And less than two weeks later, another attack took an entire African country (Liberia) offline.
Here's the thing; it's not like a device's nonvolatile firmware even needs to be completely overridden in order to do its new masters' bidding (although open-sourcing the code makes this easier than would otherwise be the case, not to mention ID'ing vulnerabilities in the first place). Most of this equipment is already DDoS-ready, in the wrong hands ... built-in facilities enable it to repeatedly request updates from NTP (network time protocol) servers, dynamic DNS (domain name servers) and the like, along with more generally repetitively "pinging" any IP address as part of its network diagnostics suite. It's not like a consumer will even necessarily know that his hardware has been taken over ... "pings" (even in bulk) probably won't noticeably swamp a broadband connection, and even assuming the affected equipment goes offline as part of the exploit, the owner will probably just assume it's flaky-by-nature and power-cycle it. And although product recalls are a nice symbolic touch, how many users will bother to take advantage of them ... assuming they're even aware of them?
Back in early 2014, in commenting at another publication both on my personal experience with "zombie" malware along with the broader trend, I made the following recommendations to the developers of such equipment:
1. Make your code as ironclad as possible from day one
2. Promptly and thoroughly respond to industry reports of vulnerabilities, and
3. Don't leave your customers in the dark regarding the availability of subsequent updates, or make the upgrades so difficult to install that they're perpetually postponed or otherwise ignored.
To this list, which I'd not-so-humbly suggest remains spot-on nearly three years later, I'll add one more entry:
4. Block proactive WAN access to the device until the user changes the default username/password combination, along with (ideally) the default WAN access port.
To clarify, I'm not talking about device-initiated Internet transactions (although it'd be nice to be able to block these at first, as well); I realize that initial device setup frequently requires interaction with the supplier's servers to, among other important things, check for available firmware updates that squash vulnerabilities and the like. What I'm referring to is the sort of externally initiated port-scanning activities that led to the previous crippling of my own Linksys router.
Such restriction likely can't be done at the LAN client itself, as it can't differentiate between LAN- and WAN-sourced traffic. It needs to happen at the router, which I'm suggesting shouldn't leave firewall holes to the LAN open by default and also shouldn't allow client-sourced UPnP transactions to open these ports...again, until default device settings are user-overridden. I realize that there's a tradeoff here involving perceived usability; all other factors being equal, consumers want to plug in a device and have it just work, with no further interaction necessary. But given that exploit is the potential result, I'm confident that a bit of education will get consumers past any misgivings that might otherwise arise.
I'll close by chewing on a bit of crow. I've admittedly been critical of Apple's slow going regarding its HomeKit protocol (and both its and third parties' products based on the protocol), the rumored result of increased cost and complexity resulting from its additional security requirements. But conceptually, at least, might this added security prevent (or at least further preclude) exploits? Could be. Shame on me.