By: Zane Markel
January 30, 2017
In the wake of the headline-grabbing Mirai DDoS attacks in 2016, several esteemed voices in Internet security called for IoT manufacturers to use more secure root passwords on IoT devices. The general thinking was that, since Mirai exploited devices by guessing their factory default usernames and passwords, the solution is to make those passwords harder to guess. In their “Strategic Principles for Securing the Internet of Things (IoT)”, the DHS argues that manufacturers need to make those default usernames and passwords more “unique” and “hard to crack.” The Broadband Internet Technical Advisory Group’s recommendations on IoT Security and Privacy echoes this argument, saying that default usernames and passwords should not be “common” or “easily guessable.” Computer security journalist Brian Krebs, whose site was the target of one of the biggest Mirai attacks, went a step further and recommended IoT makers to require users to set their own complex passwords when first setting up the device. The Open Web Application Security Project (OWASP) argued that users should be allowed to change device usernames and passwords and that the passwords they pick should be “strong” and “complex” in their IoT Top 10.
These tips all have laudable intentions and may initially appear to be satisfactory solutions. However, weak default passwords are usually just the symptoms of more nefarious underlying problems, and treating these pieces of advice as universal truisms could be counterproductive in the long run.
Weak default passwords shouldn’t be a problem in the first place
In order for Mirai and similar malware to compromise a device using a weak default password, the device needs to allow remote root login to begin with. However, most devices have no need for this capability. While many devices do need some form of remote administrative configuration, this capability is often accessible via an administrative web app that only grants administrators the ability to configure relevant settings. A root login is much less restricted, as it gives users unfettered access to the embedded computer on an IoT device. While both can theoretically cause harm, typically only root access is useful for building botnets.
Usually, there is never a legitimate need for root access to an IoT device. The only users that would want such access are tinkerers trying to get under the hood, which is a tiny niche of people that could easily adapt to secure, local methods of getting root access. A few companies might want to retain remote access to the IoT products they sell, but such desires are rarely justified. (There are certainly better ways to push updates.)
Mirai spreads by guessing credentials on devices running Telnet and SSH, remote login services that should not have been running in the first place. I speculate that vendors run their IoT products on operating systems that have these services turned on by default and don’t think to disable them during development. Instead of urging these vendors to implement more complex default passwords or schemes, one should urge them to simply disable Telnet, SSH, and any other service that allows remote root access. (Krebs’ post does recognize that Mirai spreads through these services and concedes that there are times when following his advice will not actually protect against Mirai, but the article does not actually urge manufacturers to disable Telnet and SSH.)
Stronger passwords are not the solution to the problem that shouldn’t be
In the few cases where remote root access is necessary (or, alternatively, if one is seeking to secure a web app for administrative configuration), the aforementioned password advice is still too simplistic.
Relying on default vendor-chosen passwords is not sufficient. If legitimate users have a way of learning the password, so do attackers. Attackers could simply buy a product in order to acquire any documentation that contains the password, and they can then use that password to get into other people’s devices no matter how complex the password is.
One might argue that there are cases where a single organization, not users, will want to retain a default password for root access. This would alleviate the need to actually publish the password. However, if a device stores a plaintext password locally at all, motivated attackers can physically dissect a copy of the product in question to lift the filesystem to determine the password. For example, this video of a recent BlackHat presentation shows how several white hat hackers lifted the filesystem on a TrackingPoint Linux-powered rifle in order to uncover its vulnerabilites. If a unique, complex vendor password is stored as a secure salted hash (an additional feature that is often automatic on operating systems yet not mentioned in either the DHS or BITAG reports), this makes it much harder to guess. However, in the event that an attacker does find the password, the default password would still be a central point of failure that renders every single product in use vulnerable.
Brian Krebs’ and OWASP’s recommendation that users set their own passwords prevents passwords from becoming single points of failure, which could greatly impede malware like Mirai. However, this approach introduces several new vulnerabilities. First, if users are not forced to set their own password during the initial setup, this recommendation’s benefits will greatly diminish, because malware like Mirai will likely compromise devices before most users get around to changing the password. But even when forced to choose their own password, users are strongly incentivized to choose weak ones. On the one hand, people already have a difficult enough time choosing strong passwords for all their computers and online services; having to come up with unique and clever passwords for all their IoT devices is just not feasible. Companies can set policies that attempt to require users to set complex passwords anyway, but this can backfire, as low usability often leads users to find workarounds like falling back on easily-entered but obvious passwords that meet complexity requirements (e.g. “qwerQWER1234!@#$”.) On the other hand, users have minimal incentive to secure their devices, anyway. At present, the biggest threat to most IoT devices is that they will be incorporated into a botnet, in which case almost none of the harm actually falls directly on the owners of compromised devices. Thus, it is actually irrational for users to choose hard-to-guess, low usability passwords for all their IoT devices, because the cost (in time and effort) to a device owner to use such a password is higher than the expected benefit. Requiring users to set passwords might improve security over well known default passwords, but usability will suffer, and attackers will likely still be able to amass large botnets from devices with easily guessed passwords.
Requiring “strong” passwords constrains innovation
When in office, Barack Obama released a report calling for the development of “the equivalent of a cybersecurity ‘nutrition label’ for technology products and services—ideally linked to a rating system… that consumers will intuitively trust and understand”. If such a nutrition label and rating included elements that requires or rewards protecting remote root access with passwords, it would impede innovations that could improve both security and usability in many devices.
For example, the Open Connectivity Foundation (comprising over 300 member organizations, including Cisco, Intel, and Microsoft) is currently developing a specification for IoT inter-device communication. Its specification does allow devices to authenticate via password, but this capability is only intended for specification-compliant devices that must resort to passwords to interact with non-compliant devices. When devices compliant with the specification communicate, they authenticate using other types of credentials besides passwords (Security Candidate Specification v1.1.0 section 9.3). All authentication schemes have their own shortcomings, but the credentials supported by the OCF specification would generally be much more secure and usable than passwords. Despite these advantages, regulation that encourages manufacturers to protect remote root access with passwords would discourage or prevent IoT manufacturers from adopting these security standards.
We have seen that, most often, devices should never allow remote root access via password in the first place. In those uncommon cases where such access is warranted, default passwords are unsafe regardless of their complexity. User-chosen passwords are better but subject to serious human factor vulnerabilities. Furthermore, mandating password-protected IoT devices would preclude the adoption of innovations that are both more secure and more usable. Thus, even if there are a couple particular cases where it would be helpful, the common sweeping and simplistic password-centric responses to Mirai are misleading and unjustified.
Instead of handing IoT developers simple but inadequate guidance, security experts should help developers design for security throughout all stages in product development by helping them recognize and weigh the options at their disposal. More specifically, almost all IoT devices are better off if they are designed not to rely solely on passwords for root access to begin with. For instance, they can use credentials other than passwords or require a second factor for authentication. Architectures like the Open Connectivity Foundation’s communication specification can help by making it easy or even necessary to use smarter authentication schemes. Additionally, reasonable security frameworks that guide developers through the process of recognizing and critically weighing competing security options might be more useful in the long run than any simple advice that could quickly become inadequate or obsolete.Tags: Zane Markel