Security Misconfiguration

Admin logins

How many times have you typed “admin/admin” as a login? It may seem ridiculous, but default passwords are a serious problem. Attackers have entered applications, network devices, and databases by using the default, out-of-the-box admin login. This is just one kind of security misconfiguration.

Security misconfiguration usually takes the form of omission. Servers enable unneeded features by default. We forget (or don’t know) to disable them and thereby leave an unconfigured, unmonitored entry point open. Admin consoles are a common source of problems. Seek them out and force good password hygiene. Never allow a default password on a production server. Cast a wary eye on containers, especially if building on an image that includes applications. Base OS images shouldn’t have servers running, but common bundles include servers like Redis, Mongo, Postgres, ZooKeeper, and so on. These have their own authentication mechanisms and default admin passwords.

MangoDB

The whole world got a vivid wake-up call in the early days of 2017, when somewhere north of 20,000 MongoDB installations were taken hostage. The databases had default credentials and were exposed to the Internet. Attackers took the data, wiped the database out, and replaced it with a demand for bitcoin.

Note: MongoDB, the company, has a thorough guide for securing the database $^{12}$. It’s unfortunate that the default installation at the time was not secured.

Remember the install script is the first step in installation, not the last.

Server listening too broadly

Another common security misconfiguration relates to servers listening too broadly. We first encountered this in Programming for Multiple Networks. We can improve information security right away by splitting internal traffic onto its own NIC separate from public-facing traffic. Security professionals talk about the “attack surface,” meaning the sum of all IP addresses, ports, and protocols reachable to attackers. Split those admin interfaces to reduce the attack surface. This is especially easy in cloud environments, where another interface is just an API call away. Some servers come with sample applications that have shockingly poor security protection and may be ages out of date. There’s never a reason to put a sample application into production. Nevertheless, it happens. Once there, the sample apps are never patched. They’re part of the exposed attack surface. Sample apps are well known and easy to find in the wild. It’s easy to build an attack for flaws in those sample apps.

Finally, make sure every administrator uses a personal account, not a group account. While we’re at it, let’s go ahead and add some logging to those administrative and internal calls. If nothing else, we’ll be one of the few people to witness a smiling auditor.