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.
a. Even better if said database solution supports access control then you should be setting up access control as well to ensure that specific users only have access to read, write or modify only as required by their function or data needs (you know, the concept of least privilege).
b. If the solution you are utilizing does NOT support Authentication, or the built-in authentication is too complex to set up initially (or costs money), consider placing a reverse proxy in front of the database and/or web front-end, and configuring authentication on the reverse proxy (note that this example is specific to Elasticsearch, but can easily be adapted to other solutions).
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.)
a. Attackers can’t attack what they can’t connect to. The only external IP address that should be able to access your database should be the IP address hosting the front-end to your data (e.g. the web application, etc.), and maybe IP addresses of the admin systems (If they are static IP addresses, or static DHCP allocations)
b. If at all possible, admins for your NOSQL database should be restricted to local access only. Set them up for SSH access, and have them administer the database locally. Although this is more wishful thinking and may not be likely in most cases, it’s still important to be aware of.
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.