3:00 min read
The principle of least effort is sensible in many cases, but it’s a poor guide to computer security and an uncomplicated human security risk. If a device or software service comes with a default password, failing to change it will open security risks. In a complicated networking environment, it takes some effort to make sure no default passwords open backdoors because they went unnoticed. Installed systems need review to make sure none have been missed.
Infrastructure? All passwords need changing
There are websites with comprehensive lists of default passwords for every device on the market. On one level, this is helpful; if users need to do a hard reset, they need to know how to access the device, and they may not have the original manual anymore. But these lists are also very handy for criminals.
Default passwords are often weak in themselves, so intruders can guess them in a few hundred tries even if they aren’t publicly available. The password “admin” is a popular one.
Even devices that seem unimportant in themselves need a password change. That smart thermostat or security camera very likely has a full operating system running on it, and someone with access can install software that has nothing to do with its intended function. It becomes a back door to the local network, able to infiltrate other systems and steal data.
Default accounts
Software services may come with default accounts, where the installation procedure either automatically disables the accounts after they’ve served their purpose or keeps them locked until their passwords are changed. For example, Oracle sets up default accounts with these precautions built in. The best practice is to delete such accounts or immediately change their passwords, so that no one will inadvertently enable them in a vulnerable state.
New virtual machines, set us as PaaS, may likewise have accounts with default passwords or no passwords. The setup procedure should prompt the administrator to select a password but hitting Enter too hastily may leave one unchanged. It’s wise to review all accounts after setting up a VM to make sure they have good passwords.
Hidden passwords
The biggest risk is not realizing that there’s a password that needs changing. A service such a database may set up a default account which ought to be removed or changed. Administrators may be careful in securing every new account yet fail to notice that a vulnerable one was automatically installed.
Documentation isn’t always good about mentioning the issue, especially on commodity IoT devices. If a password is needed only for maintenance functions, the person installing the device might not notice that it’s there.
Changing it may not be easy. It may be necessary to set up a Telnet or SSH connection to the device and run the “passwd” command or some equivalent, without any mention in the documentation of how to do it.
Sometimes accounts exist on a device that aren’t revealed to the user at all, and sometimes there’s no way to change the password. These are sometimes leftover test code that the manufacturer forgot to remove. Security updates may remove the test account or give instructions for changing the password.
Don’t assume it’s unreachable
Even if the device is reachable only on the local network, leaving its password unchanged is a poor practice. A network configuration error could expose it, or malware could reach it through another computer on the network. The principle of defense in depth says that networks should have strong internal security as well as protection from outside threats.
At one time, routers were commonly shipped with a published, default administrative password, and remote administration over the Internet was enabled by default. Botnets devoted to scanning them quickly sprang up. They used the brute-force method of probing every possible IPv4 address. The routers would typically get compromised within seconds of being plugged in.
Sometimes there’s no getting around this vulnerability. Administrators need to familiarize themselves with the security setup for devices before installing them, and if possible keep them off the public Internet while setting them up as these devices are inherently insecure.
Best practices
Following CERT’s recommendations will help to avoid exposing devices to default-password risks. Suggested measures include:
- Identifying devices that may come with published passwords.
- Changing the password before letting a device onto the Internet.
- Using non-password authentication methods, such as X.509 certificates and public-key authentication.
- Restricting access to devices where possible.
- Deploying vulnerability scanners to catch unaltered passwords.
When it comes to passwords, the easy way isn’t the best way. Every device that’s open to remote access needs to have a strong password or other access control.