The Ransomware Problem: Database security in 2017

Ransomware has become a massive issue in recent years. Not only have several security organizations posted project profits for major malware campaigns in the hundreds of millions, but enterprises are also more likely to pay the ransom than consumers. Recently researchers have also started to notice a pattern in the way ransomware attackers are leveraging new targets. In this blog post I’m going to talk about what’s happening in three specific attacks as well as what you can do to secure your NOSQL database instances.

We’re no strangers to the subject of ransomware attacks. In fact, we here at Hurricane Labs have created a nice series of infographics and ‘quick fix’ blog posts you can use to help combat and prevent ransomware (and malware in general!) that you can find here.

Case #1: MongoDB Databases

In early January of this year, researchers began to notice that ransomware actors had set their sights on a new target: Databases. More specifically, MongoDB databases. Tens of thousands of MongoDB instances have been targeted in a rash of ransomware attacks. The attackers would gain access to the MongoDB instances, delete all the data being stored, and replace the data with a ransom note. The note would request bitcoins to be deposited into a bitcoin wallet in order for victims to get their data back (when in some cases, there was no evidence the attackers exported the data before wiping it). The image featured here was snagged from “The Hacker News“.

Case #2: Elasticsearch systems

Not too soon after, Elasticsearch instances were observed being targeted as well, with the same MO: delete data, leave a ransom note, with the actors most likely not having a copy of the data removed. What I find fascinating about this is that not too long ago, attackers were targeting Elasticsearch nodes with an RCE vulnerability and leveraging that to add Elasticsearch systems to DDoS botnets. Image credit goes to Victor Gevers on Twitter: @0xDUDE.

Case #3: Hadoop HDFS nodes

Most recently, as of January 16th, one of my fellow security researchers, Sudosev, and I began noticing that Hadoop HDFS nodes were being vandalized; attackers were simply deleting the data and leaving a defacement note stating “NODATA4U_SECUREYOURS**T”. The image pictured here is from Shodan.

Are you starting to see a pattern?

In all three cases, there are database technologies that should not be exposed to the public internet in nearly all cases, and in the event that they are, there are methods or documented recommendations to prevent unauthorized access to overwrite the data on a whim. In fact, MongoDB supports authentication and configuring user roles. Hadoop also supports a “Secure Mode” with kerberos-based authentication. While it isn’t exactly easy to set up, considering the amount and likely criticality of the data you are storing in a Hadoop cluster, you still want (and need) to do this.

Elasticsearch on the other hand recommends utilizing their Security/Shield module (What isn’t mentioned is that the security module requires a subscription service). Without this shield module, Elasticsearch treats anyone with the ability to send requests to an Elasticsearch cluster as a super user. This means that if you expose the Elasticsearch backend directly to the internet (e.g. tcp port 9200), then there is practically nothing to stop users from modifying the stored data.

Probably not the last of these “fake ransomware” attacks

I don’t think this is going to be the last we see of these defacement/fake ransomware attacks (called “fake ransomware” due to the fact that the attackers don’t have the original data to restore). Based on research done by Sudosev, other NoSQL technologies also have a tendency toward usability and availability being the focus, with security and integrity of the stored data being an afterthought. This is an interesting and very concerning problem that traditional database solutions faced and have taken great strides toward solving in recent years.

Traditional databases, like MySQL, have been around for ages, and have experienced the same growing pains, but they learned from their mistakes; when you install mysql-server these days, the installation defaults have improved greatly. By default, mysql-server binds the database listener (port 3306) to localhost (127.0.0.1). This means that only the local machine can connect to the database. While this assumes that application you’re using will be hosted on the same box as the database, this setting is more secure, and can easily be changed to support network connections to the database. In addition to limiting network connectivity by default, the mysql_secure_installation setup script has been provided to guide users through removing test users and databases from the default MySQL install, as well as setting up a password for the root MySQL user. In fact, the secure install script is usually installed and ran by default whenever you install the MySQL server package on most popular Linux distros.

So, what can you do?

Here are some generic things you can do to secure your NOSQL database instances.

1.) If your solution supports configuring Authentication, then you should most definitely use it.

2.) Use host-based firewalls (pf, iptables, etc.) to ensure that only specific IP addresses are able to access the database as necessary (e.g. administrator systems, database front-ends, etc.)

Learn from lessons of the past

Ransomware has a tendency for going for low-hanging fruit. So long as NOSQL solutions continue to place availability over Confidentiality and Integrity of the stored data, and fail to learn the lessons of database solutions past, I don’t see an end to this epidemic in sight.