Man In The Middle in Cassandra

Apache Cassandra's distributed architecture creates unique attack surfaces for Man-In-The-Middle (MITM) compromises, distinct from traditional REST APIs. Cassandra relies on two primary communication channels vulnerable to interception: the native CQL transport (typically port 9042) for client-driver connections, and the gossip protocol (port 7000/7001) for internode cluster coordination. An attacker positioned within the network—compromising a router, exploiting a misconfigured VPC, or deploying a rogue node—can intercept, modify, or inject traffic.

Client-to-Node MITM via CQL: The DataStax Java driver and other client libraries establish TCP connections to Cassandra nodes. If TLS is not enforced or certificate validation is disabled, an attacker can present a fraudulent certificate during the SSL handshake. For example, a compromised network device could intercept the initial STARTTLS-like negotiation (Cassandra's native transport encryption is negotiated at connection startup). Once the MITM establishes the encrypted tunnel with the client, they can decrypt, read, and alter CQL queries and results. This could exfiltrate sensitive data (PII, credentials) or inject malicious CQL like DROP KEYSPACE or INSERT INTO sensitive_table....

Gossip Protocol MITM: Cassandra nodes constantly exchange state information via the gossip protocol on port 7000 (unencrypted) or 7001 (encrypted). An attacker intercepting gossip traffic can poison the cluster's view of its topology. By sending forged GOSSIP_DIGEST_ACK or GOSSIP_DIGEST_SYN messages, they could mark a live node as down, causing client drivers to blacklist it and potentially route traffic through a malicious node they control. This facilitates a targeted MITM on specific client requests. Alternatively, they could inject false load metrics to influence the driver's load-balancing policy, directing traffic to a compromised node.

HTTP Proxy/Stargate Attacks: Many deployments expose Cassandra via HTTP-to-CQL proxies (like DataStax Stargate) for REST/GraphQL access. These HTTP endpoints are classic API targets for MITM. An attacker could intercept HTTP requests to steal Authorization: Bearer <token> headers or modify JSON/GraphQL payloads to change query parameters (e.g., altering a ?keyspace=production to ?keyspace=test for data corruption).

Detecting MITM vulnerabilities in a Cassandra deployment requires examining both infrastructure configurations and application code. For HTTP-based access layers (Stargate, custom proxies), middleBrick's standard API scanning applies directly. Submitting the HTTP endpoint URL to middleBrick triggers its Encryption and Data Exposure checks, which will flag:

• Missing or invalid TLS certificates (HTTPS not enforced, self-signed certs without proper pinning)
• Weak TLS cipher suites or protocol versions (e.g., TLS 1.0/1.1)
• Lack of HSTS headers allowing protocol downgrade attacks
• Sensitive data (API keys, session tokens) in URL parameters or headers

For native CQL (non-HTTP), detection is less about automated scanning and more about configuration auditing. Key indicators of MITM risk include:

• cassandra.yaml settings: client_encryption_options.enabled: false or internode_encryption: none.
• Client driver configurations that disable certificate validation. In Java, look for SSLContext setups using TrustManager that blindly trusts all certificates (e.g., a X509TrustManager that returns true for checkServerTrusted).
• Driver load-balancing policies that do not consider node proximity or SSL status, potentially routing to unencrypted nodes.

middleBrick's GitHub Action can integrate into CI/CD to scan any HTTP management interfaces for Cassandra, ensuring proxy layers are not the weak link. Its Inventory Management check might also flag exposed non-standard ports (like 9042) if inadvertently accessible from the public internet, increasing the MITM attack surface.

Remediation focuses on enforcing encryption and strict certificate validation at all communication layers. Cassandra provides robust native features; the critical step is enabling and correctly configuring them.

1. Enable Internode and Client Encryption (cassandra.yaml):

client_encryption_options:
  enabled: true
  optional: false  # Fail if client does not use SSL
  keystore: /etc/cassandra/keystore.jks
  keystore_password: "changeit"
  require_client_auth: true  # Mutual TLS
  truststore: /etc/cassandra/truststore.jks
  truststore_password: "changeit"

internode_encryption: all  # Encrypt all gossip traffic

Setting optional: false and require_client_auth: true ensures nodes and clients must present valid certificates trusted by the Cassandra truststore, preventing unauthorized MITM nodes from joining the gossip ring or clients from connecting without proving identity.

2. Configure Client Drivers for Strict TLS: Application code must enforce hostname verification and certificate chain validation. For the DataStax Java Driver:

import com.datastax.oss.driver.api.core.CqlSession;
import javax.net.ssl.SSLContext;
import java.net.InetSocketAddress;
import java.security.KeyStore;

KeyStore trustStore = KeyStore.getInstance("JKS");
try (FileInputStream fis = new FileInputStream("/path/to/truststore.jks")) {
    trustStore.load(fis, "password".toCharArray());
}

SSLContext sslContext = SSLContext.getInstance("TLSv1.3");
// Initialize with truststore - DO NOT use a TrustManager that trusts all
// ... (standard TrustManagerFactory setup with trustStore)

CqlSession session = CqlSession.builder()
    .addContactPoint(new InetSocketAddress("cassandra-node.example.com", 9042))
    .withSslContext(sslContext)
    .withSslHostnameValidation(true)  // CRITICAL: Prevent certificate spoofing
    .build();

For Python drivers (cassandra-driver), set ssl_options with a validated ca_certs file and hostname_validation=True.

3. Network Segmentation: Use firewall rules (e.g., iptables, security groups) to restrict access to ports 9042 (CQL) and 7000/7001 (gossip) to only known application servers and cluster nodes. This limits the network positions an attacker could occupy to perform MITM.

4. For HTTP Proxies (Stargate): Configure Stargate with a valid TLS certificate and enforce HTTPS. Use API gateways in front of Stargate to validate JWTs/OAuth tokens and implement mutual TLS where possible. middleBrick scans will verify these HTTP endpoints have Strict-Transport-Security headers and no mixed content.

Q: Does Cassandra encrypt data at rest by default?
A: No. Cassandra's native encryption at rest (transparent data encryption) is an optional feature that must be explicitly configured in cassandra.yaml. MITM attacks target data in transit, not at rest, but both require separate configuration.

Q: Can middleBrick scan a raw Cassandra CQL port (9042)?
A: No. middleBrick scans HTTP/HTTPS API endpoints. For Cassandra's native CQL protocol (binary, not HTTP), you must manually audit driver configurations and cassandra.yaml for encryption settings. However, if Cassandra is exposed via an HTTP proxy (like Stargate), middleBrick can scan that HTTP endpoint for TLS and data exposure issues that could facilitate MITM.