Beast Attack in Cassandra

The BEAST (Browser Exploit Against SSL/TLS) attack targets TLS 1.0 implementations that use CBC-mode cipher suites, allowing an attacker to decrypt parts of HTTPS traffic. Apache Cassandra can be exposed to this vector when its client‑to‑node or internode encryption is configured with TLS 1.0 and weak CBC ciphers. The attack does not require authentication; an observer who can perform a man‑in‑the‑middle (MITM) on the TCP connection (e.g., on an untrusted network) can leverage the TLS 1.0 CBC chaining vulnerability to gradually recover plaintext.

In Cassandra, the relevant code paths are located in the org.apache.cassandra.net package, specifically the MessagingService and OutboundTcpConnection classes that initialize the SSLEngine. When client_encryption_options or server_encryption_options in cassandra.yaml set protocol: TLSv1 or allow CBC suites such as TLS_RSA_WITH_AES_128_CBC_SHA, the Java SSLEngine will negotiate those parameters. An attacker can then inject chosen‑plaintext blocks and observe the resulting ciphertext, exploiting the predictable IV in TLS 1.0 CBC mode to recover authentication cookies, session tokens, or any sensitive data transmitted over CQL (e.g., query results containing PII).

Because Cassandra’s native protocol (port 9042) is binary, the attack surface is less obvious than a web browser, but the same TLS layer protects the traffic. If encryption is enabled but misconfigured, the BEAST flaw remains exploitable. This maps to OWASP API Security Top 10 2023 category A2:2023 – Broken Authentication, specifically the sub‑risk of using weak or outdated transport protection.

Detecting a BEAST‑vulnerable Cassandra deployment involves checking the TLS version and cipher suites actually negotiated by the server. Since middleBrick performs unauthenticated black‑box scanning of any API endpoint, it can be pointed at the Cassandra native port (9042) or at a CQL‑over‑HTTP gateway (if present) to evaluate the transport security.

During the scan, middleBrick’s Encryption check:

• Performs a TLS handshake and extracts the negotiated protocol version.
• Lists the cipher suite selected by the server.
• Flags any use of TLS 1.0 or TLS 1.1.
• Flags CBC‑mode cipher suites (e.g., those ending in _CBC_) when paired with TLS 1.0/1.1.

Example CLI invocation:

middlebrick scan tcp://cassandra-node.example.com:9042

The output will include an Encryption section similar to:

If the scanner returns a grade of D or F with the above findings, the Cassandra instance is likely exposed to BEAST. The same detection works via the GitHub Action or the middleBrick Dashboard, allowing continuous monitoring of the encryption grade over time.

Mitigating BEAST in Cassandra requires disabling TLS 1.0/1.1 and removing CBC‑mode cipher suites from both client‑ and server‑side encryption options. The changes are made in cassandra.yaml and reflected in the Java driver or cqlsh client configuration.

1. Update server encryption

server_encryption_options:
    internode_encryption: all
    keystore: conf/.keystore
    truststore: conf/.truststore
    protocol: TLSv1.2
    algorithm: SunX509
    store_type: JKS
    cipher_suites: [
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    ]
    require_client_auth: false

client_encryption_options:
    enabled: true
    keystore: conf/.keystore
    truststore: conf/.truststore
    protocol: TLSv1.2
    algorithm: SunX509
    store_type: JKS
    cipher_suites: [
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    ]
    require_auth: false

2. Restart Cassandra to apply the new SSLContext.

3. Verify with a client – using the DataStax Java driver:

Cluster cluster = Cluster.builder()
        .addContactPoint("cassandra-node.example.com")
        .withSSL(SSLOptions.builder()
                .setProtocol("TLSv1.2")
                .setCipherSuites(
                        "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
                        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
                )
                .build())
        .build();
Session session = cluster.connect();

Or with cqlsh:

cqlsh cassandra-node.example.com 9042 --ssl

After restart, run a middleBrick scan again. The Encryption check should now report TLSv1.2 and a GCM‑based cipher suite, clearing the BEAST finding and improving the overall security grade.