Remote shell attacks against password-less systems date back to before the modern Internet era, and allowing root (administrative) users to connect directly using SSH (PermitRootLogon) still catches my attention. We went through similar security challenges with MySQL, which in some default configurations also didn’t require a password for local connections. Many Oracle database setup examples include common passwords, but it’s obvious where to set the password. A shared, common password is more secure than none at all, followed by a shared password only used in your organization. These are easy practices to fix, the basic hygiene of security, not unlike brushing your teeth or locking your front door. But we do have to do them, unless we want to spend more time at the dentist.
So, what can we learn from the fact that, in 2017, there are still production systems with no passwords set on them? The most obvious, of course, is that anyone making software should ship with some basic access controls turned on. More importantly, it should tell us that all systems, be they hosted in on-premise data centers, or on private or public clouds like AWS & Azure, need at least basic security & configuration. It’s easy to get distracted or overwhelmed by the 150+ security vulnerabilities commonly seen on any given Linux or Windows system, or by the 100-200+ security controls typically recommended by the Center for Internet Security or the Defense Information Systems Agency’s policies, and to miss the most common rules: use passwords, shut off unnecessary services, disable configurations that make what services are running less secure (like using PermitRootLogon), and apply patches regularly. With as fast as security is evolving at present, a service without a password set is the lowest hanging fruit and should be the least of our worries. However, the administrators of somewhere north of 30,000 MongoDB instances are having a bad day as a result.
Right now, across the internet, internet-facing unsecured MongoDB databases are being copied, deleted, and held for ransom. [http://www.eweek.com/security/mongodb-ransomware-impacts-over-10000-databases.html] What was first 10,000 compromised instances, is now 28,000, and has the potential to hit almost 100,000 by the time the attacks have run their course. As most of the articles on the incident point out, the first item in the security checklist for MongoDB, and indeed for any service, is to configure access controls.
MongoDB is a pretty decent database popular in production, especially in web-based applications that may live entirely in the cloud or on internet-facing systems. The worst part of this is databases that don’t have basic best practices like setting a password are also at a higher risk of not being backed up. This means that in many of these cases, data lost to ransomware or malicious action may be irretrievably gone. Of course, if your organization has good basic best practices, most of your data will have at least some form of backups, and ransomware then hopefully ties up only the most recent changes, not substantially all of it.
However, if your production application is running or dependent entirely on one of these databases, and all of the data is lost or held ransom, you’re out of business until you can recover your data. At that point, the suggested recovery fee of $150-900 (.15-1 BTC) is almost salt in the wound: most businesses would lose much more than that from the few hours to a day of downtime if recovered, and potentially much longer if they’d have to start from scratch.
The upside of all of this, is that by following and executing on the basics, we can avoid having to have this particular ransomware discussion with our superiors. Worse yet, to find out that the hacker in question didn’t even store a backup copy of your data. We can avoid having our company’s name in the news, and that awkward moment in the next interview when a hiring manager looks up from your resume and asks about “The Breach.”
Update: as of 23 January, the MongoDB ransomware is now available for sale, meaning anyone with a couple hundred bucks can compromise an open MongoDB instance. With recent news articles reminding us that there are still internet-facing sites that are subject to Heartbleed, a vulnerability that made news years ago and started the celebrity vulnerability phenomenon, it’s more important than ever to stay on top of, and rapidly close vulnerabilities, especially those in public-facing systems.
For more information on best practices for how to keep your IT environment secure, see the BMC SecOps IT Security and Compliance Guide.