ignorance is bliss, but not for mongodb

3
Ignorance is bliss, but not for MongoDB The database management system MongoDB is currently being downloaded at an impressive rate: approximately 30 000 times per day. Widely spread, this open source software is today the talk of the town because of a hacking wave that, according to some, was to be expected sooner or later. In 2015, the Hackernews website was the first to raise concern about and its security flaws. Over 600 TB of data hosted by the NoSQL database were identified as being accessible without a password. Yes, you read that correctly. « These MongoDB instances weren’t exposed due to any flaw in its software, but due to a misconfiguration (bad security practice) that let any remote attacker access MongoDB databases without using any special hacking tool. », added the website. Not long after, MongoDB published a new software version of its database. The latest version 3.4 enables administrators to actually activate the authentication feature on the unprotected systems. But, as it was to be expected, the majority of admins most likely didn’t catch the news concerning the additional security features of the available updates. It’s also possible that some of them find a migration process bothersome (to upgrade from a 2.7 version to a 3.X can be delicate). Regardless of their reasons though, this particular segment of MongoDB users is now being targeted by an unforgiving hacking pandemic. Last December, security researcher Victor Gevers sounded the second alarm for MongoDB, announcing that the danger had officially evolved from the state of « potential threat » to « full-blown ongoing attack ». According to Gevers, it seems as though cybercriminals were the only ones to take his warning into account. The outbreak all started with a group dubbed « harak1r1 » which is actively targeting all administrators having not updated MongoDB. What remains hugely impressive in this case is just how the numbers progressed in less than two weeks. On January 3 rd , 2 000 databases had been seized by « harak1r1 ». Now, according to Gevers and another fellow security researcher, Niall Merrigan, the stats show today almost 34 000 infected databases. This sudden increase is also due to rising number of criminal groups seizing this opportunity. Like bees to honey, more than 20 groups are involved today in the MongoDB heist. And who can blame them? It seems pretty easy to exploit the software’s misconfiguration. One the most “successful” group is Kraken. Kraken alone has managed to gather an impressive number of 21 000 MongoDB databases.

Upload: itrust-cybersecurity-as-a-service

Post on 12-Apr-2017

215 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Ignorance is bliss, but not for MongoDB

Ignorance is bliss, but not for MongoDBThe database management system MongoDB is currently being downloaded at an impressive rate: approximately 30 000 times per day. Widely spread, this open source software is today the talk of the town because of a hacking wave that, according to some, was to be expected sooner or later.In 2015, the Hackernews website was the first to raise concern about and its security flaws. Over 600 TB of data hosted by the NoSQL database were identified as being accessible without a password. Yes, you read that correctly. « These MongoDB instances weren’t exposed due to any flaw in its software, but due to a misconfiguration (bad security practice) that let any remote attacker access MongoDB databases without using any special hacking tool. », added the website.Not long after, MongoDB published a new software version of its database. The latest version 3.4 enables administrators to actually activate the authentication feature on the unprotected systems. But, as it was to be expected, the majority of admins most likely didn’t catch the news concerning the additional security features of the available updates. It’s also possible that some of them find a migration process bothersome (to upgrade from a 2.7 version to a 3.X can be delicate). Regardless of their reasons though, this particular segment of MongoDB users is now being targeted by an unforgiving hacking pandemic.Last December, security researcher Victor Gevers sounded the second alarm for MongoDB, announcing that the danger had officially evolved from the state of « potential threat » to « full-blown ongoing attack ». According to Gevers, it seems as though cybercriminals were the only ones to take his warning into account.The outbreak all started with a group dubbed « harak1r1 » which is actively targeting all administrators having not updated MongoDB. What remains hugely impressive in this case is just how the numbers progressed in less than two weeks. On January 3 rd, 2 000 databases had been seized by « harak1r1 ». Now, according to Gevers and another fellow security researcher, Niall Merrigan, the stats show today almost 34 000 infected databases. This sudden increase is also due to rising number of criminal groups seizing this opportunity. Like bees to honey, more than 20 groups are involved today in the MongoDB heist. And who can blame them? It seems pretty easy to exploit the software’s misconfiguration.One the most “successful” group is Kraken. Kraken alone has managed to gather an impressive number of 21 000 MongoDB databases.

Page 2: Ignorance is bliss, but not for MongoDB

Another ransomware? Uhm, not really...

The media are advertising these incidents as ransomware attacks, but that’s not the case for all of the groups. Indeed, Kraken doesn’t encrypt your data, neither does it launch a malicious payload like the rest of this season’s malware (read our previous article on Popcorn Time here). No, these hackers actually use a script that replaces database content with the ransom request. In other words, they export the content of unsecured MongoDB instances in order to then erase the found data and drop instead a file containing the ransom content.

A basic script should look something like this:

> mongodump --host <targetHost> --out data

> mongo --host <targetHost> dbName

> db.dropDatabase()

> db.bitcoins.insert({"bitcoin Address": "XXXX", "message": "You have been pwned. Give us 1 BTC.", email: "[email protected]" })

Of course, we are simplifying things to a great extent here. But it remains true that, if the database can be accessed without first logging in, one can easily launch the above mentioned script.

But all good things come to those that... pay, right? False. According to Gevers and Merrigan, some of the cybercriminal groups involved are quite happy with just deleting the files found, rendering all data hostage rescuing operations futile. Unfortunately, more than 88 enterprises to data have already paid the requested price and 12 of them have yet to receive a response (or their data, for that matter).

Cybersecurity experts also note that these groups are also competing with each other at the same time. And what a ruthless fight it is. Some hackers even delete existing scripts containing ransom demands. Between you and us, this doesn’t exactly inspire trust. Victims could then easily find themselves in the situation that the bitcoins they just transferred were sent to a hacking group that doesn’t even have their data.

However, looking over the stats, it becomes clear that cybercriminals cannot endlessly benefit from MongoDB’s weakness. According to John Matherly, the founder of Shodan, almost 50 000 MongoDB servers are exposed to the Internet, while more than a half have already been infected. That being said, hackers have again found the loophole that renders the situation in their favor. Take, for instance, Kraken – that has made a profit of over 9 000 bitcoins (or 7 million euro) in the last couple of weeks. The latter didn’t just stop there, it also put its script up for sale in order to make the most out of a temporary situation.

Source: Bleeping Computer

Page 3: Ignorance is bliss, but not for MongoDB

Don’t be surprised! If you leave the door cracked...

...hackers will definitely invite themselves in.

Andreas Nilsson, Product Security Responsible at MongoDB, explains how administrators can manage to avoid this type of attack: “These hacks can be avoided thanks to the numerous security measures integrated within MongoDB. Our security manual is there to help you use these safety features correctly.”

This might come as a surprise to some of you, but MongoDB is no more less secure than a MySQL database: « It’s in the nature of a database software to render optional certain features. This is not true only in the case of MongoDB », stated a spokesperson in New York.

Even so, certain actors present in the cyber-landscape did not hesitate to harshly criticize the leaf-company. Appalled at the recent events, Chris Wysopal, Director of Technology for Veracode, doesn’t agree at all with this product development approach. The latter attempted to underline the need to secure a software from the moment it is being first conceived on Twitter:

It seems we’ve hit a bump in the road, as public opinion is divided: should we enable the popularization of a quick & simple tool, despite its security shortcomings? Or should we instead focus on developing tools that are more complex, more secure, with a restrictive configuration, disregarding the need for a fast and painless deployment?

That aside, the important thing right now is to determine whether or not you’ve already been hacked. It’s easier than it sounds, trust us. You can do this by simply following these 3 steps:

1. Check your MongoDB for an unknown admin account that may have been recently added;

2. Check GridFS, the tool that enables you to use MongoDB as a file manager, to see if any unknown files were recently added, not as a result of your own doing;

3. Check the logs in order to make sure that your MongoDB instances were not accessed by a foreign machine.

If, by some strike of luck, yours is not among the 34 000 compromised servers, you should know that the situation (if left unchanged) is subject to change in the very near future. If this chain of so-called ransomware was possible, it’s only because there are still individuals out there in denial of the true value of cybersecurity best practices.

Here are a couple of steps you might find useful:

1. Update your MongoDB to the latest version;

2. Disconnect the remote control feature for your database (if possible);

3. Block the default port of MongoDB;

4. Configure Bind_ip in order to limit the access to the server by linking local IP addresses.

Link: https://www.reveelium.com/en/ignorance-bliss-not-for-mongodb/

https://www.reveelium.com/en/cisco-webex-vulnerability-its-a-kind-of-magic/