How to find unprotected databases with Netlas.io?

Databases have always been and will be a desirable target for attackers. No matter what the DBMS type or architecture. Data is the only thing that matters for the hacker in this case.

Recently, I set out to understand whether it is possible to effectively control database security using Netlas. Therefore, this is the first of two articles where I will tell you about my findings. After reading, I recommend that you check your databases, because, you know… it is easier to check now than to regret later.

Attention! In this article, as you already understood, we will touch on some published in the world databases. Some instances do not have password protection. You must remember that it still belongs to someone. Accessing such data without the owner’s permission may be considered a crime. Netlas does not access or copy any data from databases during the Internet scanning process. Therefore, there is nothing wrong with doing research using Netlas. However, you should not attempt to access any databases found on Netlas without permission from the owner.

Elasticsearch

Elasticsearch is a data search and indexing system. However, it may also be present in this article. Moreover, for an attacker, elastic indexes are perhaps the most desirable target since they are very easy to work with.

First, I’ll show you the search term. To find all Elastic objects in the latest Netlas.io data, you can use the following dork:

protocol:elasticsearch

And this is what you get:

However, simply displaying all elastic addresses is not enough. Some of them will require basic HTTP authorization; others will be inaccessible. I propose to improve our query a little:

protocol:elasticsearch NOT elasticsearch.elastic_cluster.response_json.nodes:”null”

This will approximately halve the number of results, but we will get accessible servers.

The request can be further refined. For example, you can select a specific country by using the appropriate keyword:

protocol:elasticsearch NOT elasticsearch.elastic_cluster.response_json.nodes:”null” AND geo.country:US

Or you can search for an elastic whose address is one of the addresses in your scope:

protocol:elasticsearch NOT elasticsearch.elastic_cluster.response_json.nodes:”null” AND ip:8.8.8.8

However, how can you use the information you receive?

Let’s say you found something in the search results that interested you. Let this be the IP address of the client company whose audit you are conducting. If you have permission to take such actions, it is worth studying the elastic found. Perhaps this is already outdated data or some kind of test run, so there is nothing to worry about.

To do this, enter the following address in the search bar:

http://8.8.8.8:9200/_cat/indices?v

where instead of 8.8.8.8 there will be the address you discovered.

If such an elastic exists, you will see the following (for the experiment I will use my own server):

Here is a list of all indexes located on a specific elastic, their size, status, and so on.

Imagine that when you open this tab, you see something secret. In my case, let it be the read-me index. If we continue to adhere to the legend that we are only conducting a security audit, this, of course, cannot be ignored. As a specialist, you would like to know what exactly is in this index. Have your clients posted anything important, or is this just a coincidence?

To understand this, you need to enter another query into the search bar:

http://8.8.8.8:9200/read-me/_search?size=1000

where instead of 8.8.8.8 is the address being examined, and instead of read-me is an important index. 1000 here is the number of records returned. You can enter any number.

If the requested index is not additionally protected, you can easily access it:

As you can see, I was able to access the index without much difficulty. I can say with confidence that there are a lot of similar cases. The lack of protection on elastics puts both the business and the people associated with it at risk.

Well, I move on to the next point.

Redis

Redis is an open-source database management system that works with key-value structures. In addition to DBs, it is also used to implement caches.

Because the solution is open source, as well as due to its ease of setup and use, Redis is quite popular. Thanks to the help of Netlas, you can find quite a lot of redises in general, as well as those that do not require a password for authorization.

So, to find all Redis databases, use the following query:

protocol:redis

This will return you over a hundred thousand results:

However, most of these databases are protected by passwords, and this is not surprising; who would want someone curious to poke their nose into their data?

With the help of Netlas, we can find all open Redis databases. To do this, enter the following query:

(redis:* AND NOT redis.info_response:”authentication required”)

Here we will get about twenty thousand results. Yes. Twenty thousand databases are not protected by anything.

For the experiment, I will use the IP address that a friend kindly provided me with. Of course, the same actions could be carried out on the local version of the server, but this will not allow me to show you the features of connecting to remote redises.

The address will be hidden, and I want to remind you that it is better not to do this unless you have the appropriate permission from the owner.

So, to interact with the database, you need to install Redis on your PC. To do this, enter the following command in the terminal:

sudo apt install redis-server

After the installation is complete, you can connect to both the local and remote databases. In the second case, you need to enter the following command:

redis-cli -h IP_ADDRESS –p PORT

I’ll connect to the server:

So, the connection was successfully completed. Next, to make sure the server is working, we can send the “ping” command:

You can see that the response was successfully received. Now the database is entirely under our control. You can request any key. Add any value. Remove any value.

I think it is obvious how dangerous this situation is. Like the previous point, I advise all readers who have a Redis database to ensure that it is password-protected.

This concludes my first article on databases. I hope it was useful to you.

Happy New Year. Good luck with your projects and take care of your databases!