Default Passwords & Credentials

Default passwords

Default passwords are another kind of misconfiguration that saves attackers a lot of time and effort. They’re easy to exploit and easy to detect—just the kind of thing that attackers love. So we need to find them first. We can leverage the network inventory work we did in chapter 1 to give us a starting point for where to look. We’ll also want to include network infrastructure like switches. We’ll want to pay particular attention to anything that’s exposed to the internet.

As was the case with defenses against SQL injection, our defense against this kind of misconfiguration can be layered. The first layer of the defense is to add to our provisioning checklist to make sure to not use default passwords when provisioning new services.

Beyond that, we can look into scanning our network for default passwords. This second layer is highly specific to your network. You won’t have time to exhaustively scan everything on your network. You’ll need to use your judgment on where to focus your efforts. You may get a good return on looking into crusty old infrastructure that doesn’t have clear ownership. And don’t overlook networked printers. Networked printers can have capabilities like emailing or connecting to an Active Directory server. If you can get administrative access to a printer by using default credentials, you may be able to see the email or Active Directory credentials that enable those capabilities.

Care in avoiding default passwords can open the door for helpful monitoring as well. If possible, alert on failed login attempts that tried using default credentials. Once you’ve configured your system with new, nondefault credentials, there will never be a legitimate login attempt that uses the default credentials. If you see that someone has attempted to log in with default credentials, you have a high-quality signal that an attack is underway.

Keep credentials out of source control

Checking credentials into a public GitHub repo is a common mistake. In the eyes of an attacker, leaked credentials are just as good as default credentials.

Even if we only use private source control servers, we still don’t want to check credentials into source control. We don’t want to have to do a build in order to change credentials. Also, putting credentials into source control makes it hard to introduce tiers of access. For instance, you may not want junior team members or third-party contractors to be able to see or change production credentials. Some organizational models call for a separation between those who write code and those who have access to run or deploy that code in production.

If we’re agreed that keeping passwords out of source control is a good idea, it’s worthwhile to have an automated way to enforce this in case we forget. If you have sensitive data confined to a single configuration file, you may be able to use features of your source control system to keep that file from ever getting checked in, even accidentally. Many source control systems can be configured to not track specific files. If you’re using Git, you can add your sensitive configuration files to your .gitignore file. This will keep you and your team from being able to check in the sensitive files at all. Other source control systems may offer similar functionality as well.

It’s worthwhile to periodically look through our source code for credentials that have been checked in. This is especially important on a larger team. It’s easy for decisions like not checking credentials into source control to not be communicated to the entire team, especially as the team grows over time.

The first tool you can use is just plain grep. It’s worth doing a one-time manual search for words like the following:

• password
• cred
• token

grep -Ri password *

These three words are worth scanning for, but you might get a lot of false positives. If you need to whittle down a lot of matches, you may want to filter these down. One way would be to look for occurrences that look like assignment statements in the programming language you use.

grep -Ri password * | grep '='

or

grep -Ri password * | grep ':' # if you use a lot of yaml or json

These next search patterns are very unlikely to have false positives. These are the beginnings of standard ssh private key files.

—–BEGIN RSA PRIVATE KEY—–
—–BEGIN OPENSSH PRIVATE KEY—–
—–BEGIN DSA PRIVATE KEY—–
—–BEGIN EC PRIVATE KEY—–

There are a number of tools that take this concept a little further. One example is TruffleHog. One of the nice things about TruffleHog is that it understands Git. So point it at your Git repo and it will look for checked-in secrets on any check-in on any branch. The benefit is that it can find secrets even if they aren’t in the latest branch. This catches the scenario where a developer accidentally checks in a password, realizes what they’ve done, then deletes the password on the next check-in. It’s not enough to remove it from the latest branch, because as TruffleHog shows, an attacker with access to Git can go back through the check-in history and look for passwords that used to be checked in.

TruffleHog has two modes of operation. One uses a configurable list of regex patterns, including the ssh private key patterns we looked at earlier. The second mode involves looking for high-entropy strings that “look” like checked-in certificates. The regex searches are faster and can be appropriate for adding into your build process.

---

In the next lesson, we’ll see how misconfiguring Jenkins and public-facing servers can leave your system vulnerable.