MongoDB And Open Source: Super-Sized Vulnerability?

Recent attacks on MongoDB remind us that the convenience of open source utilities may come at a heavy security price. Luckily, new techniques and technology offer a solution.

By Rami Mizrahi, Vice President of R&D, TopSpin Security

The recent flood of ransomware attacks on unprotected instances of MongoDB has brought open source utilities to the forefront of the security debate. Easy-to-use, easy-to-implement, and low-cost -- MongoDB and other open source utilities have changed the way many organizations work and collaborate.

Today, employees can self-deploy software products at the click of a mouse. Technologies such as Git and Docker make the installation of open source software and publicly-available projects which once demanded whole teams of integrators a matter of minutes. Almost any user with some technical know-how can now set up a WordPress site for his group, deploy file-sharing for her project team via OwnCloud, or create a data analytics warehouse to analyze marketing campaign data. And the cool thing is there is nothing inherently insecure about many of these tools.

However, it’s important to recognize open source tools such as MongoDB are frequently used to address strategic business needs. The ease of setting these tools up — both in-house and in the cloud — has contributed to a rapidly-growing Shadow IT perception regarding open source solutions. This perception judges a solution by its convenience and expediency first and security somewhere thereafter, ignoring the strategic implications altogether. This is the big problem facing security-conscious organizations because setting up a utility and securing it demand very different levels of expertise.

Open Source: Security First? Not Exactly …
Securing open source utilities and preventing attackers from exploiting them is a task for professionals. It’s a task with overhead that requires know-how and demands some compromise from users. The problem is, as always, finding the golden path between ease of use, time to market, and security. At the moment, the installation defaults favored by open source utility vendors focus largely on the first and second of these considerations leaving security unattended and unaddressed.

In the interest of ease of deployment, many open source projects have no security by default — even if they are, as mentioned above, built for potential secure implementation. There are also some that come to market before they’re actually ripe for production with developers still struggling with basic product functionality and not yet even thinking about security.

For example, almost all open source projects (including MongoDB, until recently) have an easy default password for the admin interface, and some have no password at all by default. Many don’t use encrypted protocols, and some even contain undocumented backdoors such as a TELNET interface or JMX monitors, to facilitate debugging.

Yet even non-technical users read the news. They know deploying a cloud-based database of leads from a recent marketing campaign, or known bugs in a new product version, might not be the best idea. And that’s why more and more instances of MongoDB and other open source utilities are deployed in-house – safe, so the thinking goes, behind the perimeter defenses.

Internal Open Source Deployment — A False Sense Of Security
Deploying a database or other open source utility within the confines of the organization can provide a false feeling of security. Security professionals know that just because an application is deployed within the organization and not directly exposed to the Internet does not mean it doesn’t require security.

Breaches of highly-secured internal databases and data leaks from sensitive air-gapped organizational sources are common occurrences. While some are the result of highly-sophisticated targeted attacks, attackers are not all that choosy. They’ll take whatever data is easiest to access. Malware such as Pony scours each infected machine for passwords, open FTP sessions, SQL/NoSQL databases, SSH tokens, and more. There’s no reason to assume locally-implemented open source utilities with default or no security are safe from even the most rudimentary hacking attempts.

More sophisticated attackers who have already gained access to the organizational network watch the local LAN closely, searching for an easy-to-access project. They use low-hanging open source fruit to steal data, or — even more dangerously — to use as a pivot towards a more valuable target. This happens because home-implemented open source tools often reside in the organizational data center or cloud and tend to be linked to other systems using automated credentials.

Once inside an exposed database such as MongoDB, the attacker can access the database with full admin rights. This is what happened to some 10,000 MongoDB instances earlier this month: the relatively unsophisticated hacker was able to create, read, update, and delete records, or simply lock other users out pending a ransom.

Open Source Is Not Going Away
Despite the inherent security flaws of the self-service open source Shadow IT phenomenon, there’s little chance MongoDB and tools like it are going to disappear. And demand from the field for faster, leaner open source implementations will probably not abate. So, what can be done to make the self-implemented open source utility landscape — specifically in-house MongoDB instances — more secure?

Breaches in the perimeter are a given. No security professional today believes his or her network is impenetrable. That’s why more organizations are turning to challenging attackers both at the gate and inside the castle, so to speak. Adaptive, intelligent, and automatic deception-based solutions are gaining both mindshare and wallet share.

Deception refers to systems that spread fake endpoints, devices, servers, and data across the network and secure valuable assets by effectively luring attackers away from the real assets. The more advanced such solutions applying intelligent deception continuously monitor all organizational traffic in order to map and profile every asset, service, and application. Some detection technologies are about to plant a wide diversity of traps for attackers, able to mimic nearly every system, file, database application, etc., that prove attractive to attackers.

In an intelligent deception protection scheme, all database instances in the organization — specifically MongoDB databases with no authentication — would be detected and mapped, and all users identified. Then, a fully-working MongoDB decoy including basic query capabilities would be automatically created. As a final step, MongoDB-specific mini-traps (breadcrumbs) would be generated and seeded across a variety of endpoints. These breadcrumbs fool advanced malware and attackers, leading them to the decoys instead of the actual database. Once engaged with the decoy, the attackers are exposed and the threat can be quickly eliminated.

Attackers and the malware they use are getting more sophisticated. However, intelligent deception helps security teams keep one step ahead. Because they constantly analyze network traffic, these systems can both detect new unprotected instances as they are created and quickly set up identical decoys to fool the attacker.

The Bottom Line
As 10,000 MongoDB database owners can now attest, getting hacked is not only no fun it’s a serious blow to productivity. Adopting the right security paradigm can help IT organizations deal with the inevitability of Shadow IT open source implementations that may lack ideal security configurations. This makes open source tools a more viable, less vulnerable tool for business.