Default Credentials: Low-hanging Fruit in the Enterprise

Passwords are Like Underwear, and It's Laundry Day

Perhaps one of the most easily overlooked security problems in the industry is password security. I'm not referring to the stored end-user password problems (discussed here), but the default (or weak) usernames and password combinations used to protect common administrative interfaces to applications and systems.

The problem stares us in the face every day, each time we log into a router, database management system, or remote access console and enter a password. Often we put a lot of time and effort into securing the end user-facing passwords, such as implementing account lockout password policies and forcing them to change their passwords at a regular interval. I find it ironic that the applications and devices used to run the organization often do not implement the same controls. Hundreds of applications and/or devices are known to be deployed with default passwords, and if not changed before or immediately after they are plugged into the network, can present serious risk to the organization.

Default credentials are considered "low-hanging fruit" for two reasons. First, they are easily exploitable by an attacker and can often lead to a serious security breach. Second, once you've identified the problem, it is easy to fix by setting a more secure password.

The password problem as described above exists in the smallest networks, all the way to large enterprises with tens-of-thousands of hosts (or more). The default or weak password is a different animal than some of the other issues we face today, such as patching, web application security, or "BYOD." A default password on a management interface of a device tends to slip under the radar of many organization's security programs. For example, if you have a solid patch management program, it will not detect a weak password because there is no "patch" per se. Firewalls are not effective defenses as users and administrators must be able to log into the systems. Defenses that identify malware are looking for different problems. Even if you have a solid configuration management program, often times it will miss this type of exposure. For example, many embedded systems do not participate in your configuration management as they run operating systems that are not directly updated or managed by the administrator. Weak passwords will also fall out of scope from configuration management because they are stored as hashed values, not easily identifiable by checking a configuration file or registry entry. In order to uncover the vulnerability you have to try to log in as the user or test the user's password hash. Testing the password hash itself presents a few challenges. You must implement a separate system to crack passwords on a continual basis, then securely report the results, securely deliver the results to the account owners, and then force them to change their password.

The devices and applications configured with default or weak credentials are often critical to your organization. For example, many console access controllers, virtual environment management, several embedded systems used to run your networks, multi-function printers, or VoIP systems may be vulnerable. This provides the opportunity for an attacker to control critical and/or sensitive systems in your environment.

Testing for default accounts and passwords over the network is easier, and safer, than testing for weak passwords. A default account for an application or system is typically one single username and one password combination. It's safe because logging into a system is expected behavior. It will generally not trigger your account lockout policy because testing will only initiate one or two login attempts.

Testing for weak passwords is trickier. In order to test for weak passwords, multiple login attempts are required. A strict account lockout policy, of say three failed attempts and the account is locked until reset by an administrator, will cause issues when testing for weak passwords. Why test for weak passwords over the network at all? While testing the actual password hash is less intrusive, it will not catch systems that do not provide access to hashed passwords or systems that are not under your direct control and have fallen out of your systems management process.

Another problem with default or weak credentials is the problem gets worse the larger your environment becomes. The more applications and systems you roll out, the more likely it will be the problem occurs, and the more important your policies, processes, and procedures become. It’s difficult to control the problem on a large scale as teams of administrators and developers are rolling out applications and systems, often taking shortcuts around policies in order to meet deadlines. The busier folks become, the more likely the problem will appear in rollouts.

Economics compound the problem as well. The obvious fix for the default password problem is to never release an application or device that contains a default password. However, the common complaint from software and hardware companies is this will cause increased support. Letting the user choose, even a weak password, will reduce risk, but increase support calls from users who forgot their password.

I recently spend some time looking at the various ways in which Tenable's products help identify weak and/or default passwords. Below are some examples.

Vulnerability Checks for Default/Weak Passwords

Nessus contains over 250 built-in plugins that will search for default and/or weak passwords on a number of services and applications. For example, Nessus will detect a Windows system that has a blank administrator password:

Some services are not as obvious as a missing Windows administrator password. For example, Baseboard is a management program for IBM servers. The service listens on UDP port 623, which could easily be overlooked as it is not a common port. Below, Nessus found an IBM Baseboard server containing easily guessable credentials:

One of the more common embedded systems to find in an enterprise are Cisco routers and switches. Managing thousands of Cisco devices is no easy task, keeping the management interfaces secure is part of that challenge. Nessus will find Cisco devices on your network that have fallen out of your device management program. For example, the device below was running Telnet with weak credentials:

Detecting Login Anomalies

Using the Log Correlation Engine (LCE) to analyze the logs from your systems, you can gain insight into login patterns and detect anomalies. Logs can be collected from a system running the LCE client or from syslog messages. The LCE associates user IDs with any type of event, including login failures. Displaying login failures by user ID can be very enlightening, as it often highlights access control problems not readily seen when working with individual IP addresses:

In the sanitized screen shot shown above, the list of user IDs associated with login failures is displayed in the left column. In the middle column, users who generated a login failure event that has never been seen before are listed. Finally, there were only a few user IDs that had enough login failures to be considered an anomaly. Displaying the data in this fashion allows you to identify user IDs that someone may be trying to brute-force guess the password.

You may also choose to look at login events per system and track the presence of login-related events. The chart below monitors logins, login failures, and access-denied events as well as anomalies in these logs for nine different servers:

Successful authentication attempts are shown in green above, and login failures are shown in the "LoginFailures" column in yellow. An access-denied event type in the next column indicates denied access to resources that do not require a form of authentication. Columns that include statistical deviation events are labeled as "Anomalies," and first-time events are labeled with the "NBS" tag for Never Before Seen.

Conclusion

If you talk to penetration testers (or even attackers), they will most often comment how a weak or default password encountered in a network led to "success." Organizations must have a solid process for deploying systems and applications to prevent these vulnerabilities from existing. Even with a solid deployment strategy, things still slip through the cracks. This is why it’s important to implement a system of checks and balances that will uncover this type of password weakness on the network. To further combat the problem, good log correlation and anomaly detection will help detect some of these vulnerabilities "in motion." The good news is that default credentials are an easy fix -- simply change the password (and optionally the username) to mitigate the vulnerability.