The Dangers of Exposed Elasticsearch Instances

Elasticsearch is a widely used text-search and analytics engine. The tooling provides a simple solution to quickly, easily, and efficiently store and search large volumes of data. Elasticsearch is utilized for a wide range of different use cases in applications, from logging request data all the way through to storing sensitive data used within applications. 

Despite its usefulness, Elasticsearch instances often pose a security risk due to poorly configured security settings. The most common issue is not enabling authentication over port 9200. This typically happens during the initial testing phase, whereby an engineer will set up the Elasticsearch instance across one or many EC2 instances. To simplify testing of the functionality of these instances locally, the engineer will often fail to enable authentication for the application running on port 9200, which poses many different risks.‍

Common Issues & Risk‍

The primary and most significant risk from a data security perspective is of course the data. The risk posed by an exposed instance is directly proportional to the sensitive nature of the data stored within. Non-sensitive data stored for testing in a staging environment poses less risk than personally identifiable information stored in production. However, a common mistake seen within Elasticsearch based research is that companies begin by populating instances with staging data, forget they are exposed, and then populate them with production data. Another common mistake is when companies commit the same misconfigurations when setting up a production environment for Elasticsearch.

There are also more risks than just from the data security perspective. By leaving the instance exposed, attackers can use the functionality not only for data exfiltration but also to leverage published exploits. The Log4j vulnerability is the perfect example. Attackers could potentially achieve remote code execution on exposed, unauthenticated Elasticsearch instances by exploiting Log4j.‍

Examples‍

Peekaboo Moments suffered a data exposure when thousands of unsecured baby videos and images were made available online. Peekaboo’s app developer, Bithouse, left the Elasticsearch database open and without password protection. The database contained more than 70 million log files comprising nearly 100 GB of data stored from March 2019. The exposed data included detailed device data, links to photos and videos, and around 800,000 email addresses.

Online marketing company Mailfire exposed the data of over 320 million people due to an unsecured Elasticsearch server. A hacker gained access to the notifications being pushed to Mailfire clients. The disclosed information included private conversations between users of an adult dating site in addition to PII.‍

Identification & Remediation‍

Identification of open Elasticsearch instances within an organization can be tricky. At the surface, you can scan all EC2 instances and check for port 9200.

An EC2 instance listening on port 9200 may indicate the presence of Elasticsearch, however further manual inspection on the service running on the port is needed to confirm. 

‍Open Raven can help to identify Elasticsearch instances listening on port 9200 without having to authenticate. Magpie, our open-source, commercially maintained CSPM, has a policy that will notify you of all EC2 instances that fit the profile of potential exposed Elasticsearch instances.

In addition, we also have a service named DMAP. DMAP bridges the gap between semi and fully automatic detection, as it can fingerprint any detected EC2 instances for open data stores and provide the details of what is running. We are planning on releasing an open-source version of DMAP at some point. Stay tuned for updates. 

The remediation for open Elasticsearch instances is simple. Once detected, make sure port 9200 is only accessible to the applications and employees who need access. For example, restrict AWS security groups to only allow access for company applications in the VPC and employees via an authenticated VPN. Locking machines hosting sensitive data within your VPC where only other applications and users via VPN can access it is always a great idea.‍

Conclusion‍

Elasticsearch is a widely used datastore across different companies and is prone to common misconfigurations which leave the instance publicly accessible. These public instances leave potentially sensitive information available for attackers to query/steal and provide an additional attack surface for attackers to exploit. Open Raven can help mitigate these misconfigurations with Magpie. Using Magpie, you can scan AWS accounts for EC2 instances with port 9200 open and receive alerts on any that match the profile. Overall, the best remediation for these misconfigurations is to restrict access to port 9200 to within your VPC where only applications with VPC access and users with VPN connections can access the instance.