It seems like every day we read another article about a data breach or leak of cloud storage exposing millions of users’ data.
The unfortunate truth is that the majority of these leaks require no actual “hacking” on the part of the attacker. Most of the time, this highly confidential data is just sitting in open databases, ripe for the picking.
It’s all too easy to discover data leaks online, especially in cloud services, which says a lot about the state of security and preparedness for cyberattacks—we have a long way to go.
Continuing my series on insecure cloud infrastructure, where I previously covered AWS and PACS, I will be going into some detail on elastic servers. Specifically, I will cover a number of cases in which I discovered a common misconfiguration, leading to open backdoors, which expose many records of personal data.
Exposed databases using search
Before I go into detail on the accidental backdoors found in elastic servers, let’s take a look at just how easy it is to find one of these exposed databases online.
While there are dozens of tools and methods for this discovery phase, for the purposes of this demonstration, I used shodan, a search engine that crawls the web for Internet-connected devices.
Let’s do a quick experiment and see if it yields results. With a quick Google search on elastic databases, we learn that elastic databases by default listen on port 9200.
From there, we open up shodan and search:
elastic port:9200
This will basically bring up IPs who have a service responding on port 9200 and whose content contains the word “elastic.” Ninety-nine percent of the time, this will bring up an elastic search server.
For the sake of full comprehension, I will give a 10-second primer on how to use the elastic search API.
Elastic can be compared to MYSQL in the following way:
| MYSQL | ELASTIC |
| Databases | Indices |
| Tables | Types |
| Records – column and row | Document with properties |
Here are a few key commands to help you navigate any elastic instance. The first is the /_cat command and the second is the /_search?pretty=true.
The cat command simply lists information, and it is a good starting point to understand what indices or fields you have to work with.
Elastic servers
Jumping into shodan, we start our search for elastic databases.
Let’s choose the a random IP that comes up from the shodan query. In this case, it is a server residing in China: https://www.shodan.io/host/47.104.101.159#9200
We can check if it is open to the world by typing in: http://47.104.101.159:9200/_cat/
This brings up the following results:
Seems like no authentication so far. Let’s look at what indices exist here by typing in /_cat/indices, which gives us the following results:
So far so good. It is clear that at the moment we will not likely be facing any authentication stopping us from accessing the data. Now we can list the contents of one of these indices, similar to a Select * from TABLE_NAME in sql. Lets choose one at random, kms_news, which looks to have 37 records inside.
We type http://47.104.101.159:9200/dzkj_news/_search?pretty=true
and voila! All the data spits out for us with hardly any effort at all.
As you can see, it was quite easy to find exposed data in a random elastic server online. In less than a minute, we found an exposed server and could continue to dump all the data. I am certain that if we spent a bit more time, we would find a database with a more critical leak.
There is a reason, after all, that these databases have received so much press for their infamous leaks.
The backdoor
Now lets get to the topic at hand… the misconfigurations leading to the backdoor.
Along with elastic, you often hear the word Kibana. This is basically the GUI front end to an elastic database, allowing you to browse/search data and configure the structure and details of the elastic instance.
As such, it is common for companies to have an internal elastic DB on premise and expose the Kibana front end so that employees may access the data from their web browser, fully authenticated. In this case, the Kibana server could listen on port 5601, open to the Internet, and will access the data from an internal elastic DB behind the company’s local intranet.
So where does the backdoor lie? Well, after having done an exhaustive search of various Kibana servers online, I noticed something funny happening on a large number of results.
I would browse to the Kibana instance and receive the login screen as expected, but after doing a port scan using nmap on the same IP, I noticed a familiar port being opened:
The infamous 9200!
To be specific, I found more than 20 servers within a span of five minutes with this same misconfiguration. What’s going on here is that an admin set up elastic search and decided to allow access through the Kibana front end, restricted by proper authentication. The problem, however, is that the actual data store on port 9200 isn’t just communicating internally. It, too, is exposed to the Internet, allowing backdoor access to the data directly from elastic queries carried out by anyone who wants to look, just as we did in the example above.
Here is an illustration showing the misconfiguration, which should make it all the more clear.
Finding a port 9200 exposed to the public does not mean there will be something of value inside. However, the combination of these two ports being exposed and restricting access only on Kibana almost guarantees that there is data here the company wanted to keep private.
Elastic ready to snap
Elastic is likely the number one source of leaked data online, and after conducting this research, I would attribute that to how easy it is to misconfigure. The focus, of course, being on the relationship between the internal server on 9200 and the public-facing component on 5601.
The purpose of this article was not to talk about a specific company or to put anyone on blast for exposing public data. Rather, I am hoping to explain just how many servers are sitting on the Internet with this backdoor. There are thousands of elastic servers open to the public and exposing data—this is nothing new. What makes these specific cases unique is that there were clearly attempts to incorporate some type of security, however, the platform is clearly being misunderstood.
Because elastic search is such a commonly used cloud database, it’s important to highlight this specific misconfiguration because it can easily be fixed.
Finding the exposed data was neither the result of a 1337 hack, nor a difficult side channel to discover. Hopefully this may help admins using elastic to better understand the danger of defaults, and for security analysts, this hopefully provided some useful information on researching new cloud infrastructures.
Stay tuned for the next article in this series where I will be covering the details of various leaks found on elastic.
The post Business in the front, party in the back: backdoors in elastic servers expose private data appeared first on Malwarebytes Labs.