Release the RAVEN: Exploiting the Cracks

In Part 1, we went from a single open port to a complete map of the target. Version, topology, indices, secrets, credentials, privilege structure — all of it documented, all of it ready to be weaponized. Reconnaissance is finished. Now we find out what breaks.

This post walks through RAVEN's CVE detection and exploitation capabilities against Elasticsearch. We will scan for known vulnerabilities, exploit legacy scripting engines to achieve root-level remote code execution, read arbitrary files from the host filesystem through the Snapshot API, and detect privilege escalation flaws that have no publicly known exploit technique. Every exploit demonstrated here produces verifiable proof. No theoretical attacks. No "this could work." Captured output or it did not happen.

All demonstrations use RAVEN's integrated lab environments running deliberately vulnerable Elasticsearch versions. No production systems were touched.

The CVE Catalog

Before exploiting anything, it helps to understand what RAVEN knows. The framework maintains a curated catalog of Elasticsearch and Kibana vulnerabilities. Every entry is specific to Elastic's own code. No third-party dependency CVEs, no Log4Shell, no Jackson deserialization chains. If Elastic is not the vendor on the NVD entry, it is not in the catalog.

As shown in Figure 1, running `raven-es --quiet cve --list` displays the full catalog.

Figure 1. The RAVEN CVE catalog showing all 8 tracked vulnerabilities with product, class, CVSS score, Known Exploited Vulnerabilities (KEV) status, and exploit availability.

Eight vulnerabilities: six targeting Elasticsearch, two targeting Kibana. CVSS scores ranging from 7.5 to a perfect 10.0. Three listed in CISA's Known Exploited Vulnerabilities catalog. Six with full exploit implementations, two with version-based detection only.

For this post, we focus on the Elasticsearch side. RAVEN auto-detects the target product during scanning, so only Elasticsearch CVEs are checked against an Elasticsearch target. The `--product` flag provides manual filtering when browsing the catalog with `cve --list --product es`. We will cover the Kibana CVEs in Part 3.

Vulnerability Scanning

The first step in any CVE-based engagement is determining which vulnerabilities apply to the target's specific version. RAVEN's `--check-only` mode performs this assessment without executing any exploit code.

Scanning a Vulnerable Target

We spin up RAVEN's ES 7.5.2 lab, a version released in January 2020 that falls within several vulnerable ranges. As shown in Figure 2, running `raven-es --quiet -t localhost cve --check-only -u elastic -P changeme` against this target identifies which CVEs apply.

Figure 2. CVE check results on ES 7.5.2 showing two applicable privilege escalation vulnerabilities.

Two privilege escalation CVEs were flagged as applicable. The version match is precise. RAVEN evaluates complex range expressions like `(>= 6.7.0 AND < 6.8.8) OR (>= 7.0.0 AND < 7.6.2)` against the detected version and reports exactly why it matched or did not match. No guessing, no "probably vulnerable." The math either checks out, or it does not.

Scanning a Patched Target

The same scan against ES 7.17.22 (fully patched) tells a different story. As shown in Figure 3, running `raven-es --quiet -t localhost cve --check-only` against the patched target returns a clean result.

Figure 3. CVE check results on ES 7.17.22 showing zero applicable vulnerabilities across all six Elasticsearch CVEs.

Zero applicable. Every CVE falls outside the patched version's range. This is the before-and-after that a security assessment delivers: a vulnerable target shows findings, while a patched target shows a clean bill of health.

For automated workflows, the `--auto` flag combines detection with exploitation in a single pass, checking all applicable CVEs and running available exploits against those that match. On a patched target, it reports cleanly: "No applicable CVEs found." On a vulnerable target, it becomes a fire-and-forget engagement tool.

MVEL Script Injection (CVE-2014-3120)

CVSS 8.1. KEV-listed. Elasticsearch before 1.2.0.

The year is 2014. Elasticsearch ships with the MVEL scripting engine enabled by default. MVEL allows arbitrary expressions to be evaluated as part of search queries through the `script_fields` parameter. The intent is computed fields. The reality is unrestricted code execution.

The vulnerability is not a sandbox escape or a parsing trick. There is no sandbox. MVEL executes whatever it receives with the full privileges of the Elasticsearch JVM process. On most deployments of this era, that means root.

We bring up the MVEL lab (`make lab-mvel-up`), which runs `vulhub/elasticsearch:1.1.1`, a version squarely within the vulnerable range. As shown in Figure 4, running `raven-es --quiet -t localhost fingerprint` confirms the target version.

Figure 4. Fingerprint confirming ES 1.1.1, within the CVE-2014-3120 vulnerable range.

Now the exploit. As shown in Figure 5, running `raven-es --quiet -t localhost cve --exploit CVE-2014-3120 --confirm-writes --cmd id` achieves root-level code execution.

Figure 5. CVE-2014-3120 exploit result showing root-level remote code execution (RCE) via MVEL injection.

`uid=0(root)`. Full root-level remote code execution through a search query. The exploit sends a single POST to `/_search` with a crafted `script_fields` payload containing MVEL code that invokes `java.lang.Runtime.exec()`. One HTTP request. One root shell.

The prerequisite is minimal: at least one document must exist in at least one index for the search query to have a hit to execute against. RAVEN's lab seeds this automatically, and in the real world, a production Elasticsearch cluster without any documents would be an unusual target indeed.

Groovy Sandbox Escape (CVE-2015-1427)

CVSS 9.8. KEV-listed. Elasticsearch before 1.3.8 and 1.4.x before 1.4.3.

Elastic's response to CVE-2014-3120 was to replace MVEL with a sandboxed Groovy scripting engine. The sandbox was supposed to restrict what Groovy scripts could do, blocking direct access to dangerous classes like `java.lang.Runtime`. The intention was sound. The implementation was not.

RAVEN bypasses the Groovy sandbox using Java reflection. The technique chains `java.lang.Math.class.forName()` to load `java.lang.Runtime` through a class that the sandbox does allow, then calls `getMethod("exec")` and `invoke()` to execute arbitrary commands. The sandbox never sees a direct reference to `Runtime`. It sees `Math`. By the time `Runtime.exec()` fires, the sandbox has already approved the call.

We bring up the Groovy lab (`make lab-groovy-up`), running `vulhub/elasticsearch:1.4.2`. As shown in Figure 6, running `raven-es --quiet -t localhost cve --exploit CVE-2015-1427 --confirm-writes --cmd id` bypasses the sandbox entirely.

Figure 6. CVE-2015-1427 exploit result showing root-level RCE via Groovy sandbox bypass.

Root again. Same outcome, different path. The sandbox that was built to prevent MVEL-style attacks fell to a reflection-based bypass that Elastic's own engineers did not anticipate. This CVE carries a CVSS of 9.8 and is listed in CISA's KEV catalog, meaning it was confirmed exploited in the wild by real threat actors.

The pattern is worth noting: Elastic removed the dangerous feature (MVEL), replaced it with a "safe" alternative (sandboxed Groovy), and the replacement was broken within a year. Security through replacement is not security through design. The scripting attack surface was not eliminated. It was redecorated.

Snapshot Directory Traversal (CVE-2015-5531)

CVSS 7.5. Elasticsearch before 1.6.1.

Not every exploit needs to give you a shell. Sometimes reading the right file is more valuable than executing the wrong command. CVE-2015-5531 demonstrates this principle through a directory traversal vulnerability in the Snapshot API.

The technique is elegant in its simplicity. Elasticsearch's snapshot repository system stores snapshots at predictable filesystem paths. By crafting a snapshot name with URL-encoded directory traversal sequences using `%2f..%2f` (URL-encoded path separators combined with `..` parent references), an attacker can trick Elasticsearch into reading arbitrary files from the host filesystem. The file contents are returned in the error response as a byte array.

We bring up the traversal lab (`make lab-trav-up`), running `elasticsearch:1.5.2`. As shown in Figure 7, running `raven-es --quiet -t localhost snapshot --read-file /etc/passwd --confirm-writes` extracts the contents of `/etc/passwd` through the Snapshot API.

Figure 7. CVE-2015-5531 exploit result showing /etc/passwd contents extracted via snapshot directory traversal.

RAVEN handles the full exploit chain internally: registering a base repository, calculating the 7-level traversal depth from the repository path to the filesystem root, URL-encoding the path separators, and parsing the byte array from the error response back into readable text.

In a real engagement, this vulnerability is often more immediately useful than RCE. Reading `/etc/shadow` (if permissions allow) gives you password hashes. Reading application configuration files reveals database credentials, API keys, and internal service URLs. Reading SSH authorized_keys files maps trust relationships. Reading `/proc/self/environ` exposes environment variables that often contain cloud credentials. A well-aimed file read can compromise more systems than a single root shell.

Directory Traversal via Site Plugins (CVE-2015-3337)

CVSS 7.5. Elasticsearch before 1.4.5 and 1.5.x before 1.5.2.

This traversal vulnerability uses a different attack surface than CVE-2015-5531. Instead of the Snapshot API, it exploits the site plugins directory traversal to read files. RAVEN includes an exploit implementation for this CVE, and while it does not have a dedicated lab, it is testable against the existing ES 1.x labs that fall within its affected version range. The MVEL lab (ES 1.1.1) and the Groovy lab (ES 1.4.2) are both within the vulnerable window.

Check-Only: API Key Privilege Escalation (CVE-2020-7009 / CVE-2020-7014)

CVSS 8.8 each. Elasticsearch 6.7.0 through 7.6.x.

Not every CVE in the catalog has a working exploit, and RAVEN is honest about that.

CVE-2020-7009 describes a privilege escalation vulnerability in the API key service where an authenticated user could create API keys with privileges exceeding their own role. CVE-2020-7014 is the same vulnerability, reissued after Elastic's initial patch was found to be incomplete. According to Elastic's advisory, exploitation involves "a series of steps" that result in elevated privileges. What those steps are has never been publicly disclosed.

I investigated this vulnerability extensively. The naive approach of specifying elevated `role_descriptors` in the API key creation request does not work because Elasticsearch computes the effective privileges as the intersection of the requested descriptors and the caller's own permissions. The key is created, but its actual privileges are clamped to the caller's role. The advisory's "series of steps" likely involves a more complex chain that bypasses the intersection logic, but without access to Elastic's internal fix commit or a public proof-of-concept, I cannot reproduce it.

RAVEN handles this honestly. Both CVEs are in the catalog with accurate version ranges, and the `--check-only` scan correctly identifies vulnerable installations. Revisiting the CVE check from Figure 2, the same scan on ES 7.5.2 highlights CVE-2020-7009 and CVE-2020-7014 as applicable, as shown in Figure 8.

Figure 8. CVE-2020-7009 and CVE-2020-7014 flagged as applicable on ES 7.5.2. Detection without exploitation.

If a user attempts `--exploit CVE-2020-7009`, RAVEN returns a clear message: "CVE-2020-7009 does not have an exploit implementation. Only check function is available." No false promises, no broken exploits, no fabricated results. Detection without exploitation still has value on real engagements. A finding of "your ES 7.5.x deployment is vulnerable to a CVSS 8.8 privilege escalation" belongs in a penetration test report regardless of whether the tester can demonstrate the full exploit chain.

Beyond CVEs: The Scripting Module

CVE exploitation targets specific vulnerable versions. But what about clusters where you already have authenticated access and scripting is enabled? RAVEN's `scripting` module provides direct script execution across all three of Elasticsearch's scripting engines, gated by version: MVEL (`--engine mvel`) for Elasticsearch 1.x before 1.2.0, Groovy (`--engine groovy`) for Elasticsearch 1.3.x through 1.4.x, and Painless (`--engine painless`) for Elasticsearch 5.0 and above.

The distinction from the CVE module matters. CVE exploits abuse vulnerabilities in specific versions. The scripting module uses legitimate scripting functionality that happens to be dangerously powerful when exposed to an attacker with valid credentials.

Against a modern Elasticsearch cluster (ES 7.17.22) with Painless, the scripting module reports honestly. As shown in Figure 9, running `raven-es --quiet -t localhost scripting --engine painless --rce --cmd id --confirm-writes -u elastic -P changeme` confirms that the Painless sandbox blocks the attempt.

Figure 9. Painless RCE blocked at compile time. RAVEN reports the sandbox enforcement rather than failing silently.

Elastic's third attempt at a scripting sandbox succeeded. MVEL had no sandbox. Groovy's sandbox was bypassed within a year. Painless, introduced in Elasticsearch 5.0, blocks arbitrary class access at compile time. The `Runtime.getRuntime().exec()` technique that works on MVEL and Groovy is rejected before execution even begins. RAVEN detects this and reports it rather than failing silently or fabricating results.

The `--engine` flag can be omitted, in which case RAVEN auto-selects the appropriate engine based on the detected version. On legacy clusters where MVEL or Groovy are still active, the scripting module provides the same RCE capability demonstrated through the CVE exploits above, framed as a misconfiguration finding rather than a vulnerability finding. That distinction matters in a penetration test report: "your version has a known CVE" and "your scripting configuration is dangerous" belong in different sections.

The Exploit Scorecard

Across this post, we demonstrated six CVEs. CVE-2014-3120 gave us root-level RCE on ES 1.1.1 through MVEL script injection. CVE-2015-1427 achieved the same result on ES 1.4.2 by bypassing the Groovy sandbox through Java reflection. CVE-2015-5531 read `/etc/passwd` from ES 1.5.2 via snapshot directory traversal. CVE-2015-3337 exploited site plugin directory traversal for file reads on ES versions before 1.5.2. CVE-2020-7009 and CVE-2020-7014 were accurately detected as applicable on ES 7.5.2, though no public exploit technique exists for either.

Two root shells. One arbitrary file read. Two accurate detections. One additional traversal exploit without a dedicated lab. And a scripting module that turns legitimate functionality into an attack vector when credentials are available.

Every result above was captured from a live lab environment. Every `uid=0(root)` is a real process running on a real container. Every file read returned real file contents. RAVEN does not simulate exploitation. It performs it.

Port 9200 has been thoroughly tested. In Part 3, we turn to port 5601, where Kibana waits with its own set of vulnerabilities, its own API surface, and its own critical CVE that required building a browser automation trigger that no other tool provides.

This is Part 2 of the "Release the RAVEN" series. Read Part 1: First Contact for reconnaissance or continue to Part 3: Kibana Under Siege for Kibana exploitation.

RAVEN is available on GitHub and PyPI.