Most organizations that use Elasticsearch databases use it to store business and customer information. It’s popular for web applications because it allows for easy ingestion and search, making powerful applications easy to develop. Since they often contain a wealth of sensitive data, its critical that those servers be appropriately protected to prevent data leaks. In November 2018, security researcher Bob Diachenko produced a report about a data breach that exposed 57 million personal information records. The data was stored in an Elasticsearch database, which is fine, but the trouble is that the database was left open and exposed to the public on the Internet.
A few misleading articles were published that asserted the issue was with the use of Elasticsearch itself, but the reality is just that the organizations that owned those servers didn’t appropriately protect those databases by placing them on a private network or putting them behind a firewall. Unfortunately, it’s an old story—basic security measures were skipped over and people’s private information (name, employer, job title, email, street address, phone number, and IP address) was leaked to any attacker that was able to find the open server and gain unfettered access without putting in much effort.
But Wait, There’s More
That November 2018 report wasn’t unique. In fact, just 2 months later in January 2019, Diachenko reported yet another massive breach that leaked 24 million credit and mortgage records. He asserted that the criminals behind the attack would “have everything they need to steal identities, file false tax returns, and get loans or credit cards.”
Three other data leaks from Elasticsearch databases happened just in January 2019. To reiterate, the issue isn’t with Elasticsearch database security, but with how those valuable databases are secured. SCMagazine noted: “Earlier four million intern applications from the youth group AIESEC, 108 million gambling records from several online casinos and millions of calls and texts from Voipo were found by researchers.”
Is My Company Properly Securing Elasticsearch Databases?
Short answer, if you can find them in Censys, you’re not properly securing them and they’re open to anyone on the Internet. Realistically, you should assume that any data you have stored in those open databases has been leaked. That said, you still must take action to protect them. And you can still be proactive about any new databases that your company is planning to create and use by ensuring they’re only on a private network and that they’re behind a firewall. More tips follow at the bottom of this post.
To run a Censys search for any exposed databases in use in your organization, we suggest checking specific IPs along with the tag (in our example, we’re using the University of Michigan IP address):
Another search to explore would be to search for your specific hostname, along with the tag:
tags: elasticsearch AND a:[yourhostname.com]
Note: in Censys, you can access the following data from Elasticsearch database servers:
- System name
- System version info, build type, build hash, build date, build flavor
- Cluster health status (green/yellow/red). More information on Elasticsearch’s ratings here
- Cluster name
- Cluster filesystem size in bytes, free in bytes, available in bytes
- All the node info for each node – roles, Operating System, Java Virtual Machine (JVM) version, plugins installed, ingest processors
Crap, We Found Elasticsearch Databases Exposed on the Internet
Deep breath. Okay, move those exposed databases to your private network and tuck them behind a firewall, stat. Elasticsearch has provided a really helpful list of tips to help prevent unauthorized access and security methods for encrypting data and monitoring/auditing appropriately.
Now, work with your red team if you have one, to determine the potential damage of a data leakage. You might ask, “What type of information is this? Is the data stored in this database particularly sensitive? Does it expose our customers, partners, or clients?”
If yes to any of those questions, consider if you need to responsibly disclose the leak to any affected parties. Make sure you’re following your organization’s protocol for such disclosures, which usually includes working with your legal team, security leaders, and other groups.
If you didn’t find any exposed databases, breathe a sigh of relief, make a cup of coffee, and search for other low hanging fruit that you and your team might not know is out there, perhaps servers using old TLS or (gasp) SSL protocol. Subscribe to our blog for more ideas on how to use Censys data to protect your organization.