Once upon a time in early 2016, we were talking with pen tester Ken Munro about the security of IoT gadgetry — everything from wireless doorbells to coffee makers and other household appliances. I remember his answer when I asked about basic security in these devices. His reply: “You’re making a big step there, which is assuming that the manufacturer gave any thought to an attack from a hacker at all.”
Privacy by Design is not part of the vocabulary of the makers of these IoT gadgets
If you take a look at Ken Munro’s blog at Pen Test Partners, the security testing company he founded, it’s filled with examples of vendor’s PbD negligence. In fact he has a few hacking scenarios worked out for IP cameras, just the kind of IoT devices which were implicated in last week’s Mirai attack.
Once you understand some of his techniques, you come away with what I’m calling Munro’s golden rule when dealing with consumer-grade IoT: change the bleepin’ defaults if you want to prevent hackers from owning your IoT thing.
When hackers get control of, say, an Internet connected coffee maker — because an easy-to-guess admin default password that wasn’t changed — they then often also find the WiFi’s PSK in plain-text stored on the device as well. It gets pretty serious very quickly from there.
And Then Along Came Mirai
These types of attacks, though, require the hacker to be within range of the WiFi signal, then deauthenticate the IoT gadget with, say, aireplay-ng, and force it to reconnect to the hacker’s own access point. So you have more to worry about from neighborhood kids or the occasional wardriving attacker.
I came away from our interview with Munro thinking the baseline security of consumer IoT is, well, not very high, but also relatively benign, and involving security weakness known by a few security pros.
Get the Free Pentesting Active
Directory Environments E-Book
The Mirai attack last week changed all that. The Internet of Insecure Things became a topic for coverage in even the non-technical media. I was reading a good description in, of all places, Forbes of how cameras like the ones Munro tested were taken over by bots in the Mirai-based DDoS assault against DNS provider Dyn.
There’s still much we don’t know about the Dyn incident, but it’s clear that WiFi cameras were involved — perhaps up to 30,000.
So how were the hackers able to scale up the camera attack that I referenced above to take over thousands of WiFi cameras worldwide?
Certainly they weren’t sending scores of self-driving cars equipped with Yagi antennas to roam the roads.
At least, not yet.
Doomed by Default
Instead they realized that consumers, like their counterparts in IT organizations, are bad at changing default settings. I mean if security admins and other super users can’t update default passwords to other than ‘123456’, then how can ordinary humans do any better?
What I thought would be the hardest part for hackers to pull off — discovering the address of the cameras — became relatively easy for them because of a default setting in WiFi routers that non-tech consumers never bother to reset.
Does anyone know what UPnP or Universal Plug and Play is?
I thought so.
UPnP is a protocol that let’s networked devices automatically open a port on the router to let you communicate with your gadget remotely.
The UPnP idea makes some sense in the context of WiFi cameras: you might want to remotely view what’s going on in your kitchen or the kid’s room over a browser, or perhaps do some remote admin work using telnet. In that case, you would need a public port that’s mapped by your router to the device. UPnP does the mapping for you.
UPnP is convenient, but can lead to a less secure environment if you’re not careful about strengthening admin passwords to the device.
The hackers behind the recent Mirai attack exploited the consumer’s default-itis. Specifically, they took a brute force approach, scanning tens or even hundreds of thousands of routers worldwide searching for exposed telnet ports, which were likely added by UPnP.
They then gained shell access by trying a short series of typical default passwords —“12345”, “admin”, etc. — until they succeeded in logging in. If not, they moved on to the next router.
Once on the gadget, which was in many cases a specific brand of wireless camera, they loaded the Mirai software, transforming the device into a bot spewing out UDP packets targeted at Dyn.
Do The Right Thing Right Now
Like many consumers, I was unaware of the UPnP capabilities of my router. After checking my own home router, I discovered that my UPnP was (long excruciating sigh) enabled. I’m fairly sure I never touched this setting, so this must have been the default from the vendor— Linksys in my case.
As a public service, I worked out the following list to help you avoid becoming an unwilling participant in the next IoT-based DDoS attack:
1. If you’re a consumer or small business person, I would disable the UPnP feature now! To inspire and help you, below is a snapshot of my Linksys router’s admin screen with the UPnP switch.
2. Take the time now to also update the admin password of your router and the WiFi PSK. And make these high-entropy – 8 or more characters of the battery-horse-staple variety. This would involve resetting the PSK on any other computers or devices already connected to the WiFi network.
3. With UPnP disabled, going forward when you add new devices, you would have to expose the relevant ports manually. That is, if you decide that you absolutely need remote access.
To do this, open up the port forwarding panel on the router and explicitly add a mapping entry. Refer to the manual for your device – camera, coffee maker, refrigerator, etc. – for details It’s more work with this approach, but now you’ll be forced to really think about what you’re doing when adding IoT gadgetry.
4. For any IoT devices already on the network, change their admin passwords, making them longer and more complex! Sure, you’ve disabled outside access to these gadgets by disabling UPnP. But you still have to worry about the local attacks I first wrote about in the beginning of this post.
5. Finally, download and run nmap on your WiFi network. It’s the port scanning tool I wrote about a few months back. You’ll get a report showing what ports are publicly exposed on your WiFi network. I’d then study the results to see if it matches your understanding of the apps or devices that have access to the great wide world.
If you’re like me, it’s just one or (more likely) zero ports. If not, then you’ll have to do more investigation.
One more point to note: nmap requires the public IP address of your router, not its fake internal IP address — i.e., 198.x.x.1 To find out what the address is for your network, enter “what is my IP address” into the Google search bar on your browser.
Enter the IP address that Google returns into nmap for its deep-dive scan.
Designed to Fail
There’s enough blame in the Mirai incident to spread around to everyone involved: vendors, the public, and the government as well.
First, vendors need to up their game before releasing IoT devices. In Munro’s blog, he presents so many basic authentication and password problems withthe IoT devices he’s tested as to almost make it seem as if they were ‘designed to be hacked.’
It’s that bad.
One step vendors can take is to encrypt and sign the downloadable firmware that’s available on their sites, thereby making it harder for hackers to work out their exploits by scanning the binaries for certain strings. Or at least store WiFi passwords in encrypted form on the device.
Sheeple! We as consumers also need to cultivate a security mindset as well. Don’t assume that the IoT gadgets you install take care of everything. Ask questions! If you’re not being directed to update an admin password during installation, something is wrong. If that happens, put the gadget back in its box.
Finally, when we buy electronic devices, we know it has passed some basic tests and received approvals — Underwriters Laboratories, FCC, etc.
What about a privacy and security certification?
Some of the cameras that were hacked in the Mirai should never have been released on the market. Currently, there’s no data security equivalent of the FCC’s electronic compliance standard.
Perhaps there should be. Or at least the IoT industry should set up their own security standards and enforce them.
In the near future, we can expect more incidents in which the default settings of IoT devices will continue to be exploited. Want to get a better handle on the IoT environment? Listen to the first part of our interview with Ken Munro.
