Databases are the heart of any modern application, storing crucial information, from simple user preferences to highly sensitive credentials, tokens, and private messages. Consequently, they are a primary target for malicious actors. This article explores several common database misconfigurations where default settings or developer oversight can leave vast amounts of data completely exposed to the public internet.
Understanding the Threat to Backend Databases
A database is an organized collection of data, generally stored and accessed electronically from a computer system. When attacking a web application, one of the main goals is frequently to compromise the backend database because it is where all the sensitive user data is stored.
Compromising these databases normally involves exploiting a vulnerability like SQL injection (a technique where an attacker interferes with the queries that an application makes to its database), but sometimes, unauthorized access can be much easier. These databases are often exposed to the internet without authentication, leaving them wide open for pillaging [extraction of valuable information] by malicious actors, as discussed in the following sections.
Google Firebase Realtime Database Misconfiguration
Introduction to Firebase
According to Google, “The Firebase Realtime Database is a cloud-hosted database stored as JSON and synchronized in realtime to every connected client.” It is a popular choice for mobile and web developers due to its ease of use and real-time syncing capabilities.
An issue can arise in Firebase when developers fail to enable or correctly configure authentication and security rules. This vulnerability is very similar to every other database misconfiguration: there is no authentication. Leaving a database exposed to the world unauthenticated is an open invitation for malicious hackers.
Identifying a Misconfigured Firebase Database
When looking for this type of vulnerability, security researchers and attackers try to keep an eye out for the “*.firebaseio.com” URL. If a security professional sees this domain structure, they know the target is utilizing Google’s Firebase DB. An example domain could be:
vuln-domain.firebaseio.com
If the developer forgot to enable authentication, the database will be exposed to the world. One can easily view the database by appending a /.json to the URL, which essentially requests the entire database content in JSON (JavaScript Object Notation) format, a common data interchange format, as shown below:
vuln-domain.firebaseio.com/.json
If the attempt is successful, the data dump could reveal critical information. For example, the entire database structure, including credentials belonging to an organization, could be exposed. An attacker could then leverage these credentials to perform additional attacks on the application, such as unauthorized login or account takeover.
Summary: Firebase Exposure
Finding and exploiting this misconfiguration is extremely easy and requires zero technical skills to pull off. All one needs to do is find an application using Firebase, append /.json to the URL, and if there isn’t authentication, the entire DB can be exported!
ElasticSearch DB: Search Engine Missteps
Introduction to ElasticSearch
Many security and development professionals have heard of the popular relational database called MySQL. Elasticsearch, like MySQL, is a database used to hold and query information. However, Elasticsearch is typically optimized to perform full-text searches on very large datasets, making it popular for logging, analytics, and search functionality. Another critical factor to note is that Elasticsearch is unauthenticated by default, which can cause a lot of security problems as described in the following sections.
ElasticSearch Basics
According to Google, “ElasticSearch is a document-oriented database designed to store, retrieve, and manage document-oriented or semi-structured data. When you use Elasticsearch, you store data in JSON document form. Then, you query them for retrieval.”
Unlike MySQL, which stores its information in tables, Elasticsearch uses something called types (though types are deprecated in newer versions, the concept of data organization remains). Each type can have several rows, which are called documents. Documents are basically a JSON blob [a large block of data] that holds the data, as shown in the example below:
{"id":1, "name":"ghostlulz", "password":"SuperSecureP@ssword"}
In MySQL, column names are used, but in Elasticsearch, field names are used. The field names in the above JSON blob would be id, name, and password. In the context of database organization, MySQL stores all of its tables in a database.
In Elastic Search, documents are stored in something called an index. An index is basically a collection of documents, analogous to a database in relational systems.
Unauthenticated ElasticSearch DB Access
Elasticsearch has an HTTP server running typically on port 9200 that can be used to query the database. The major issue here is that a lot of developers and system administrators expose this port to the public internet without any kind of authentication. This means anyone can query the database and extract information. A quick search using a public-facing search engine like Shodan (which scans and indexes internet-connected devices) will produce a ton of results revealing exposed instances.
Once it has been identified that a target has port 9200 open, a security professional can easily check if it is an Elasticsearch database by hitting the root directory with a GET request. The response should contain the service’s version and name, confirming the database type.
Once it is known that an endpoint has an exposed ElasticSearch DB, the next step is to find all the indexes (databases) that are available. This can be done by hitting the /_cat/indices?v endpoint with a GET request. This will list out all of the indexes.
This information, along with other details about the service, can also be found by querying the /_stats/?pretty=1 endpoint.
To perform a full-text search on the database, the following command can be used: /_all/_search?q=email. This will query every index for documents containing the word “email”. Security professionals often search for sensitive keywords, which include:
- Username
- Password
- Token
- Secret
- Key
If one wants to query a specific index, the word _all can be replaced with the name of the index to search against.
Another useful technique is to list all of the field names by making a GET request to the /INDEX_NAME_HERE/_mapping?pretty=1 endpoint. Security researchers typically search for interesting field names such as:
- Username
- Password
- Token
- Secret
- Key
The output provides a schema [structure] map, showing all the potential fields (columns) in the index. This information helps in constructing targeted queries for sensitive data.
To query all values that contain a specific field name, one can use the following command: /_all/_search?q=_exists:email&pretty=1. This will return documents that contain a field name (column) named email.
Again, _all can be replaced with the name of an index to perform searches specifically against that endpoint.
Summary: ElasticSearch Exposure
ElasticSearch is just another database where one can store and query information. The major problem is that people expose the unauthenticated web service to the public. With unauthenticated access to the web service, attackers can easily dump the entire database. Systems administrators and security teams must always be on the lookout for an exposed port 9200.
MongoDB: The NoSQL Default Pitfall
Introduction to MongoDB
Like Elasticsearch, MongoDB is a NoSQL database [a non-relational database that provides a mechanism for storage and retrieval of data other than the tabular relations used in relational databases] that uses JSON-like documents to store data. Also similar to the rest of the databases mentioned in this article, Mongo DB often fails to implement authentication by default. This means it is up to the user or developer to enable this security feature, which they often forget.
Checking for Unauthenticated MongoDB
If one is searching for MongoDB instances, the primary port to be on the lookout for is port 27017. As mentioned earlier, MongoDB often doesn’t have authentication enabled by default, so to test for this vulnerability, one simply tries to log in. To do this, one normally just uses the mongo CLI (Command Line Interface) as shown below:
mongo ip-address-here
Once logged into the database, an attempt should be made to issue a command (e.g., show dbs). If an “unauthorized” error message prompting for authentication is received, then the endpoint has authentication enabled and is secure.
However, if one can run arbitrary commands against the system without an error, then authentication has not been set up, and the security professional has full, unrestricted access to the database’s contents.
Summary: MongoDB Exposure
If port 27017 is seen open, or any other MongoDB associated port, security teams must make sure to test the endpoint to see if it’s missing authentication. Exploiting this misconfiguration is as easy as connecting to the database and extracting the data. This is arguably one of the easiest ways for unauthorized data access to occur.
Conclusion: The Authentication Imperative
If an application needs to store data, chances are it is being stored in a database. These databases hold all kinds of sensitive information such as passwords, tokens, private messages, and everything else. That’s why databases are always popular targets for malicious actors. Since these are such popular targets, one would assume they would be fairly secure, but often they are not. A lot of databases are missing authentication by default! This means if connected to the internet, anyone could connect to these devices to extract the information they hold. Configuring strong authentication is the first and most critical step in database security.
The following table summarizes the common services and the key indicators of their exposure:
| Name | Endpoint/Port Indicator |
| Firebase DB | *.firebaseio.com/.json |
| Elasticsearch | Port: 9200 |
| MongoDB | Port: 27017 |
| CouchDB | Port: 5985, 6984 |
| CassandraDB | Port: 9042, 9160 |