Never Leave Your Cloud Database Publicly Accessible

Introduction

In cybersecurity, we often hear about best practices, one of the most important of which is never to open services that should be for internal use to public access. These are best practices for a good reason – when you don’t follow them, you might be hacked!
Research we conducted in the past showed how hackers could use Docker and Redis services that were left exposed to their own advantage.

Investigations into the root cause of data breaches will most often point to the same malpractice where services are left publicly accessible, whether by mistake or intentionally for a specific purpose for a limited time.

When it comes to databases, one of the most important rules is never to expose your database to public access. In cloud environments, however, it’s very easy to make this mistake because your cloud provider can allow it to happen with just a few clicks.
Using Shodan we can quickly get an estimation of publicly open databases. Figure 1 shows statistics related to MySQL and Postgres. Under “Top Organizations” you can see cloud providers like Amazon and Alibaba.

Figure 1: Publicly open MySQL and Postgres databases from Shodan

In this blog, we’ll demonstrate what can happen inside your database when you leave the door open.

HoneyPots

One of the most effective ways of learning how hackers operate is to deploy honeypots.
Taking this approach, we created several Relational Database Services (RDS) on AWS and left them open. To lure hackers we inserted Personal Information Identifier (PII) data and payment information.
In Figure 2, you can see that it didn’t take too long for hackers to discover and make the first connection attempt to the database. In addition, the time to the first attack was also very short.

Figure 2: Honeypot statistics

During the research, we observed multiple attack types. Let’s have a deeper look into them.

Attack Types

Overview

Password cracking using dictionary attack

Once your database is public, the first thing hackers will do is try to connect to it, starting by using various methods of password cracking. We refer to this as phase one.
We observed multiple attacks, some of them conducted from a single IP while others from 115 different IPs, often from the same C Class, with 170 different DB users. Overall, during a period of one month, we observed 23,000 different connection attempts to the database. The most popular DB users used in the attacks were: root, admin, mysql, user, backup, test, phpmyadmin, mysqld, sa, and ADMIN.

In Figure 3 you can see a password cracking attack on MySQL DB carried out by multiple IPs.

Figure 3: Password cracking attack done by multiple IPs

We identified two types of behaviors. After a successful connection to the database, the first of these immediately begins phase two of the attack – the further exploitation of the database, such as malware deployment.
The second type, after successfully connecting to the database, immediately disconnects and saves the credentials for later use. On one occasion, we observed an interval of five days between phases one and two.

Data Probing

Data probing, as shown in Figure 4, is a step hackers perform to inspect the data in order to decide whether it has any value, and whether or not to continue the attack.

Figure 4: Data probing attack

DB User Backdoor

We observed connections to the database (DB) where the only thing that happened was a creation of a new DB user, as shown in Figure 5. Our educated assumption is that this DB user was being used as a backdoor for later access.

Figure 5: DB user backdoor attack

DB Takeover

In this attack, hackers iterate all existing DB users and modify their password, leaving you outside of your own database. In Figure 6 you can see an example of where the hacker got a list of users with specific privileges and then modified the “admin” user password.

Figure 6: DB Takeover attack

Malware Deployment

Hackers can also use SQL to download and execute malicious files on the database machine. For additional information, you can read: A Deep Dive into Database Attacks [Part IV]: Delivery and Execution of Malicious Executables through SQL Commands (MySQL)

Ransomware

Ransomware is usually associated with a malware that encrypts your data and requires you to pay a ransom in order to be able to release it. We’ll take a deep dive into a version of this attack in the next section.

Deep dive into ransomware attack

In the context of ransomware in databases, hackers dump your data, delete it and leave a ransom note.

Figure 7: Ransomware note

In our honeypot project, we were witness to countless ransomware attacks on our databases by different hacker groups. Figure 8 shows a ransomware attack flow on a MySQL honeypot:

Figure 8: Ransomware attack flow

The six phases of the attack:

1. Collect credentials using dictionary attack:
The hacker used a dictionary attack to guess DB users and passwords. In line 5 the hacker succeeded in connecting the DB with an ‘admin’ user. He then disconnected and continued to try guessing additional DB users.

2. Run reconnaissance script:
After five days, the hacker came back and started his attack. At first, he ran a reconnaissance script to discover the following:

• All DB users
• All databases that are not default
• All DB users that have “SELECT” and “INSERT” permissions
• The size of the databases

3. Use “mysqldump”:
By examining the queries (see below) we came to the conclusion that the hacker used mysqldump to exfiltrate the data.

Once he had all the data, the hacker dropped the database:

4. Re-create database:
The hacker created a new database with the same name it had before and inserted a ransomware note.

5. Create a new database:
The hacker created a new database called “PLEASE_READ_ME_XMG” to get the attention of the database administrator, using the same ransomware note as before.

6. Create DB user backdoor
The hacker created a backdoor by creating a new DB user and granted him administrative permissions. This way, the hacker would still be able to connect to the DB, even if the administrator decided to change the password for all users he was aware of.

The end result of the attack – our honeypot database was hijacked.

After analyzing the attack we decided to contact the hacker in order to get more information about his operation. We used a fake email account and asked him for proof that he did, indeed, possess our data. In return, he sent us a screenshot of the dump.

Figure 9: Talk to the hacker

We suspected that hackers use legitimate tools for dumping databases. Now we had proof of “mysqldump” being used to exfiltrate data from databases in this case.

This begs the question: do hackers use legitimate tools to dump databases?
In order to answer this question, we had to get our hands on database dumps from previous data breaches.
We browsed hacker forums and downloaded a couple of dumps.

Figure 10: Dump using MySQL Administrator dump

Figure 11: Dump using MySQL dump

Figure 12: Dump using Adminer MySQL dump

As shown in figures 10 to 12, those dumps are created by legitimate tools.

Conclusion

Our goal was to understand how hackers attack databases. The assumption was that hackers use sophisticated techniques/tools to carry out their attacks, but we learned that this is not always the case. Legitimate tools are usually used for administrative
operations like database backup, but are also used by hackers to exfiltrate your data.
This way, hackers can mask their malicious activity.

This blog shows the tip of the iceberg when it comes to what can happen on your open database.

How can I protect my database?

We highly recommend you follow best practices, for example:
Disable public access
Change default passwords
Deploy password policies (expiration, lock, complexity, etc.)

Searching risky queries or operations, for example:

• BD user backdoor
  • ‘CREATE USER’
  • ‘insert into mysql.user’
• DB Takeover
  • ‘select User from user where Select_priv=”Y” and Insert_priv=”Y”‘
  • ‘update user set Password =’
  • ‘update user set authentication_string =’
• Malware Deployment
  • ‘created table (data LONGBLOB)’
  • ‘CONCAT(‘’,’0x4D5A9…’)’
  • ‘Into‘ and ‘DUMPFILE’
  • ‘CREATE FUNCTION’ and ‘.dll’
• Ransomware
  • ‘PLEASE_READ’
  • ‘INSERT INTO `WARNING`’

You can also search for failed logins to find brute force attacks.

Imperva’s Cloud Data Security (CDS) product can help you to detect some of the attacks like new DB user creation and brute force attacks.
We are currently in the process of adding detection algorithms into the CDS product.