Open and Exposed Databases: Risks and Mitigation Techniques Explained
Reading time: 10 minutes
Databases are among the most important parts of a web application. Almost every action performed on your web application involves using a database in some form to determine what to perform next, to store a user's input, or to give a user information. These three user interactions form the most essential functions that a web application performs.
Databases often contain tons of valuable information, including usernames, passwords, email-IDs, addresses, phone numbers, and much more. This treasure trove, however, also makes the database one of the most targeted parts of a web application. Looking at some of the largest database breaches in history further emphasizes just how valuable the information stored within your organization's database can be.
And database hacks are not always sophisticated hacks that occur due to software code faults. Frequently, the simple yet fatal misconfiguration of a database's operation is the root cause of data breaches.
- Hello Elasticsearch
- Consequences of a database breach
- Misconfigurations: the most common cause of database exposure
- Mitigating database breaches
- Summary
Hello Elasticsearch
Some of the most common database hacks include the use of Elasticsearch, a popular database that is highly efficient at storing large amounts of data as well as analyzing and visualizing the data it stores. This makes it super popular within organizations that have a lot of logging or other large data to be analyzed.
Elasticsearch by default binds to localhost only, which is secure enough, but to make Elasticsearch usable in an organization, database administrators often make the mistake of binding Elasticsearch to the public network interface without firewalling it. While this may seem normal at first, keep in mind that Elasticsearch has no default user authentication setup on it. Manual configuration is required to enable the xpack module which then allows one to set up a password based authentication on Elasticsearch.
The above misconfiguration allows attackers to simply enter, delete data, steal data, and exit. Again, there is simply no way to determine whether a user is a hacker or not. This simple flaw has caused a countless number of hacks within Elasticsearch over the years and continues to do so even today.
Security breaches caused due to database compromises can lead to loss of data as well. At times, data is not only stolen but also destroyed by attackers. Read more about data loss prevention here.
Now, let's take a closer look at how to identify open and exposed databases.
Consequences of a database breach
The consequences of a database breach are extensive and often seen as a critical cause of trust issues in any web application.
Because databases often contain sensitive information like first and last names, home addresses, personal phone numbers, and other information that is shared in confidence, leaks of such data are perceived as negative and highly harmful, leading to trust issues and customer departures from compromised web applications.
Another facet of database breaches is the threat of silent attacks. These involve attackers making minor changes to a database in order to gather or steal data over a long period of time and also to compromise targeted accounts. This was often seen in cryptocurrency exchanges in the past, wherein user accounts would get compromised and funds stolen, as well is as in advanced persistent threats (APT).
With newer laws coming into place such as the GDPR (in Europe), ICO (in the UK) and various other regional laws, dealing with breaches can also involve legal consequences and financial fines. These laws require companies operating within those regions to report breaches within 24 hours or less. Failure to do so can incur larger fines and other legal consequences.
However, beyond laws, legal consequences, and financial losses, your reputation is the most important aspect of your web application. It is essentially what drives users to your platform, makes them stay, and prompts them to recommend it to their friends, family, and others. Data breaches often lead to damage of your platform's reputation, which leads to a negative overview of your platform itself.
Misconfigurations: the most common cause of database exposure
As database breaches are frequently caused by misconfigurations, let's take a deeper look into some of the misconfigurations most commonly seen.
Misconfigured user ACLs
A user ACL (access control list) is a set of defined rules which allows or denies a user the ability to perform certain actions such as creating, deleting, or modifying a database. If these rules are misconfigured, a user may be allowed to perform unsafe actions, and if that user gets compromised, an attacker can gain access over the entire database. Therefore, it is critical to configure optimal user ACLs to limit the area of possible attack surface via a user account compromise.
Allowing remote connections without firewalling
Most modern DBMS (database management systems) have built-in remote connection allow/deny rules available, but misconfiguration of these rules can allow unauthorized users to access your database. Using a firewall gives you a second layer of safety, as well as a second chance to catch the misconfiguration.
Another risk with allowing remote connections without a firewall is that if the DBMS has a vulnerability in its allow/deny remote access code, an attacker can gain access to your database, even with a correctly configured ruleset.
Reused passwords
Reused passwords represent another highly frequent misconfiguration. Use of the same password for server login and DBMS admin login runs rampant, and is one of the leading causes of database breaches. Using strong, unique passwords for each user-password combination improves the overall security of your database setup.
Other forms of misconfiguration can arise from the platform in use. Companies are known to leverage the flexibility of platforms like AWS which if misconfigured can increase your database's attack surface as well.
Make yourself aware of other common cybersecurity risks. Everything from out-of-date software to human error can create possible risks for your database. That is why reducing the access layer and keeping the DBMS and operating system updated go far in improving security.
Mitigating database breaches
Using open-source tools
Using free and open-source tools is one of the first steps to begin securing your database and mitigating any chances of database breaches.
Tools like Nmap allow one to scan their server for open ports, and seeing the database open port in the scan report can also help identify open database access.
For example, if you are running an Nmap scan against their server and see port 3306 open, this indicates that their MySQL server is accepting connections without filtering/limiting.
Users often set up restrictions within MySQL but do not firewall their ports. This can lead to severe consequences if the MySQL version running has vulnerabilities that allow bypassing the filters set up within MySQL itself. Using a combination of in-software filters combined with a dedicated software or hardware firewall offers maximum security.
Apart from scanning your server, tools like mysqltuner and postgresqltuner can be run on the database server to provide various optimization- and security- related configuration suggestions.
For example, if one runs mysqltuner against their database, on a basic or stock setup you will see the following suggestion.
General recommendations:
Restrict Host for 'user'@% to 'user'@LimitedIPRangeOrLocalhost
RENAME USER 'user'@'%' TO 'user'@LimitedIPRangeOrLocalhost;
The above output suggests we restrict the host and user access from a specific IP address or range or simply localhost. This prevents the general internet from accessing the database via the user.
Following the best-recommended practices
Database software vendors often have recommended security configurations defined as well. If followed, these can help reduce your database's attack surface significantly.
Usually, vendors include the most commonly overlooked security configuration aspects of their database software, such as limiting access to remote hosts and restricting user privileges. Checking out these recommended practices right from the start can save you a lot of time, and spare you from reconfiguring a database once it's in production.
For example, Elasticsearch has its own security improvement recommendations, MySQL users can access the MySQL Security Best Practices, MariaDB users can follow the guide Securing MariaDB, and MongoDB administrators can use the MongoDB Security Practices. These are just a few examples of how official documentation can help reduce the chances of, and even prevent, an attack.
Using ASI
Scanning for open and exposed databases is even easier using our own Attack Surface Intelligence tool. With only a few clicks you can find a list of open and exposed databases detected under your organization's domain name,
To begin, head over to the URL: https://securitytrails.com/app/sb/
Click on the "Projects" button in the navbar:
Once here, click on "Create New":
Then, input the name of your project and your organization's domain name, and once you're ready, click on "Create Project":
Give it a few seconds—then click on your newly created project:
Now, click on the "Risks" tab:
Inside of which you'll click on "Database Open Ports":
This will yield a list of open and exposed databases, with information including the URL, IP address, ports detected, database type (MongoDB, PostgreSQL, MySQL, CouchDB, etc.), and the database's hosting company:
Using SQL Explorer
Another way to scan for open and exposed databases within your organization is to use the SecurityTrails™ SQL Explorer.
To begin, log in to your account at https://securitytrails.com/app/sb/ and then click on the "SQL" button in the navbar:
Once there, input the query for the appropriate database type that you are looking for:
Checking for open and exposed MySQL databases
Since MySQL uses port 3306, we'll use that port in our query, and you can replace "ge.com" with the domain name of your organization.
SELECT
domain.hostname,
http.title,
ip.address
FROM
hosts
WHERE
ip.ports_real = '3306'
AND domain.apex = 'ge.com'
Expected output:
Checking for open and exposed PostgreSQL databases
Since PostgreSQL uses port 5432, we'll use that port in our query. Again, you can replace "ge.com" with the domain name of your organization.
SELECT
domain.hostname,
http.title,
ip.address
FROM
hosts
WHERE
ip.ports_real = '5432'
AND domain.apex = 'ge.com'
Expected output:
Checking for other open and exposed databases
Just as in the examples above, where we used ports 3306 (for MySQL) and 5432 (for PostgreSQL), we can use other ports in our query, like 5984 (for CouchDB) or 27017 (for MongoDB), etc., in the ip.ports_real section.
Summary
Open and exposed databases are often the leading cause of data breaches in web applications, and misconfigured restrictions and user ACLs can cause damage on multiple fronts when dealing with databases containing invaluable data.
Using open-source tools like Nmap can allow you to scan their own servers for open ports and identify possible open and exposed databases that are accessible from all over the internet. Securing these ports with in-software restrictions combined with a software or hardware firewall can help mitigate most attacks.
Beyond scanning, one can use database-specific tools like mysqltuner (for MySQL) and postgresqltuner (for PostgreSQL) which can enhance a user's insight into the database's configurational changes, for database user access restriction and other remote access-related settings that may be misconfigured.
But even the use of tools listed above is inherently limited, in that you can only scan what you're aware of.
Often in organizations with multiple development teams and projects, various virtual machines are spun up for testing and/or development—and at times these virtual machines are left running with only minimal configuration. Using SecurityTrails™ Attack Surface Intelligence (ASI), however, can help identify such open and exposed databases that may go unnoticed or even remain unknown until they get compromised, which can often be too late.
SecurityTrails™ Attack Surface Intelligence automatically finds and enumerates open and exposed databases within your organization. Empowered with information such as the database URL, IP address, ports detected, database type (MongoDB, PostgreSQL, MySQL, CouchDB, etc.), and the database's hosting company, your organization's security team can maintain an edge over keeping your organization safe and secure..
