The Internet of Things (IoT) is the nickname / moniker that’s been given to the now prolific network of ‘smart’ and ‘connected’ devices like thermostats, cameras, DVRs, toasters, refrigerators and the like making their way into homes and businesses across the planet. It’s made the news quite a bit lately (so much that the IoT Village is pretty standard fare at most security / hacker conferences including DEF CON) and most recently because it was used in a massive DDoS attack against two high-profile sites KrebsOnSecurity.com and French Hosting provider OVH. The linked Threatpost article has a lot of good information that’s specific to this most recent attack leveraging the IoT but this seemed like a good opportunity to highlight three specific areas that contribute to the problems with the IoT and some suggestions on how to move forward.
Failures from the manufacturers. While more complex vulnerabilities (buffer overlows, unchecked input, etc.) aren’t uncommon, we’re seeing a LOT of failures from the manufacturers that revolve around poorly implemented authentication.
- Hard coded credentials – Usernames and passwords or public / private keypairs being hard-coded into firmware (making them difficult or impossible to change). If an attacker is able to discover these credentials, closing the hole that’s created can be difficult or impossible.
- Failure to require strong encryption – Use and support of older encryption like SSL or hashing algorithms like MD5. Both technologies can be easily broken with brute force or collision attacks using off-the-shelf hardware.
- Easy authentication bypass. The XiongMai Technologies is an excellent example of this. While the ‘home’ page of the device (http://<IP_address_of_device>/Login.htm) required a username and password, an attacker could easily bypass the login page by simply going to http://<IP_address_of_device>/DRV.htm and gained full control of the device.
- Insecure connections – Many devices still allow access to sensitive areas (configuration pages, reporting pages, etc.) via insecure protocols like HTTP and Telnet. Any traffic to or from a device using these protocols can easily be intercepted and potentially modified in transit.
Failures from the installers and technicians. It’s worth noting that there’s a trickle down effect here and that the technicians and installers should a) know and understand the weaknesses inherent in the equipment that they’re installing and maintaining (and push the manufacturers to do better) and b) clearly communicate these things to the users that they are installing and maintaining the equipment for. That said, there are a number of failures that fall squarely on the shoulders of the installers and technicians.
- Failure to change default passwords – It’s trivial to Google <equipment name> default passwords and get hundreds of lists with hundreds of different username and password combinations neatly sorted by device and model name and that’s only if something like admin / admin or admin / password doesn’t work.
- Failure to disable insecure protocols – Even if the manufacturers leave insecure protocols like HTTP or Telnet enabled on the device, if there’s an option to disable it and the installer or technician didn’t disable it, that’s a failure on their part. All-too-often, we find devices that are connected to the Internet with every port imaginable (80, 8080, 8443, 5060, 50080, etc.) both TCP and UDP fully exposed. Some of the ports are for services listening on the device and some are wide open for an attacker to connect a shell to (reverse shells are nice, but having an open port available for a direct connection is even better).
- Failure to properly segment the network. Talk to ten people and you’ll get twelve answers about the best policy for segmenting a network (keep it all flat so that it’s easily to get a view of all of the traffic or segment it at every conceivable border and compartmentalize everything. There’s merit to both but, at the end of the day, most would likely agree that it’s a bad idea to have a ‘black box’ type device on your LAN that’s also exposed to the Internet and not very closely monitored.
Failures from the users. Like with the technicians, there’s a trickle down effect here as well. It’s the owner or end user’s ultimate responsibility to understand the technology that’s deployed on their network and it’s potential security implications. Ideally, the equipment would be manufactured and installed in such a way that any security implications would be minimal and easily communicated to potentially non-technical people.
- Failure to maintain updates – Once the equipment (camera, thermostat, television, refrigerator, etc.) is installed, it’s important to monitor for software or firmware updates from the manufacturer that may patch holes that had not been discovered before the equipment was installed.
- Failure to change passwords – If the equipment isn’t maintained by a third party, it’s a good idea to change the password to something that the installer or technician does not know. If there is a breach at the installer or technician’s network, your credentials could likely be compromised. If you’ve changed them, that’s not an issue.
So, what now? This clearly isn’t a problem that’s going to be resolved overnight but it’s a problem that needs to be resolved and it’s going to require some effort from everyone (manufacturers, installers, technicians and users). If you are an end user, researching the equipment that you already have and doing the basics (change passwords, update firmware and software, etc.) will go a LONG way. As you buy and install new smart or connected gear, make changing the passwords and installing any available updates part of the process. If you are an installer or technician, hold the manufacturers accountable for the equipment that they’re putting out there. If they don’t respond appropriately to responsible disclosures of vulnerabilities and don’t implement best practices (strong encryption, good authentication, etc.), find another product. Also, if you’re an installer or technician, understand the product that you’re deploying. If you’re going to request (or require) that your customer make changes to their firewall (open every port listed in this book), understand what you’re asking and be prepared to defend it (you need to open TCP port 443 for the web interface, you need to open ports 50080-50083 for the administrative console, etc.) and let them know the security implications of doing so (a vulnerability in the web server or administrative console could be used to gain access to whatever network the device is on). If you’re a manufacturer, thoroughly test equipment before it goes out the door. Hard coding credentials anywhere that they can’t be easily changed by an installer, technician or end user is a bad plan, security through obscurity simply does not work. Assuming that all users are legitimate and assuming that all users will access your device the way that you think that they will (i.e., by going to the login page before going to the device management page) is a bad plan.
Misc / Errata