Man In The Middle in Cockroachdb

Man-In-The-Middle (MITM) attacks against CockroachDB exploit its distributed, network-centric architecture. Unlike monolithic databases, CockroachDB nodes communicate continuously over the network for replication, consensus (Raft), and distributed query execution. An attacker positioned between nodes or between a client and the cluster can intercept, modify, or inject traffic.

Attack Pattern 1: Inter-Node Communication Compromise
CockroachDB nodes use TLS for inter-node traffic by default (since v20.2), but misconfigurations weaken this. If --certs-dir is missing or self-signed certificates are accepted without validation (--accept-invalid-certs flag), an attacker on the same network can perform TLS stripping or present a rogue certificate. The attacker could then:

• Modify replication logs to corrupt data consistency.
• Inject malicious SQL into the Raft log, potentially escalating privileges (CVE-2021-30465-like scenarios in distributed systems).
• Intercept node-liveness heartbeats to cause false node failure detections, triggering unnecessary rebalancing or splits.

Attack Pattern 2: Client-to-Cluster MITM
Applications connect via a SQL gateway (any node). If an application uses an insecure connection string (missing sslmode=verify-full), TLS termination might occur at a load balancer without proper certificate pinning. An attacker could:

• Capture credentials transmitted in cleartext if the initial handshake is downgraded.
• Modify query results (e.g., alter financial totals) before they reach the client.
• Inject responses that cause application logic errors (e.g., changing a SELECT ... FOR UPDATE lock timeout).

CockroachDB-Specific Code Path Vulnerability
The ccl (CockroachDB Community License) binary's TLS configuration is controlled by flags and connection parameters. A common misconfiguration is using sslmode=require (encryption only) instead of sslmode=verify-full (encryption + certificate validation). This allows a MITM with a self-signed cert to be accepted. In Go's database/sql driver for CockroachDB (lib/pq fork), the sslmode parameter directly maps to the TLS config. If set to disable or require without a proper sslrootcert, the client cannot authenticate the server's identity.

Detecting MITM vulnerabilities in CockroachDB involves validating TLS configurations both at the cluster level and in client connections. Manual checks include:

• Inspecting node start commands for --certs-dir presence and correct CA hierarchy.
• Verifying that all nodes present certificates signed by the same CA.
• Checking connection strings in application code/configs for sslmode=verify-full and sslrootcert path.

Scanning with middleBrick
middleBrick automates this detection by testing the exposed API surface (SQL interface via postgresql:// or cockroachdb:// URLs). The scanner performs:

• TLS Configuration Analysis: It attempts connections with varying sslmode parameters to see if the server accepts invalid certificates or cleartext.
• Cipher Suite Enforcement Check: Verifies if weak ciphers (e.g., TLS 1.0/1.1, RC4) are negotiated.
• Certificate Validation: Checks if the server's certificate chain is properly signed by a trusted CA and if hostname verification is enforced.
• Downgrade Attack Simulation: Tests if the server falls back to non-TLS connections when a client initiates a cleartext handshake.

For example, middleBrick's report would flag a finding if it connects with sslmode=disable successfully, or if it receives a certificate that doesn't match the cluster's hostname. The scanner's Encryption category score directly reflects these checks, mapping to OWASP API Top 10:2023 API7:2023 – Server Side Request Forgery (SSRF) (if MITM leads to internal node access) and API2:2023 – Broken Authentication (if credentials are intercepted).

Remediation requires enforcing strict TLS at both cluster and client levels using CockroachDB's native security features.

1. Cluster-Level TLS Hardening
Generate a proper CA and node certificates. Start each node with:

cockroach start --certs-dir=/path/to/certs --join=node1:26257,node2:26257,node3:26257 --cache=25% --max-sql-memory=25%

• ca.crt (CA certificate)
• node.crt and node.key (per-node certificate/key)
• client.root.crt and client.root.key (for admin clients)

Never use --accept-invalid-certs in production. Validate the setup with:

cockroach node status --certs-dir=/path/to/certs --host=node1

2. Client Connection String Enforcement
Applications must use sslmode=verify-full and provide the CA certificate. In a Go application using lib/pq:

import "database/sql"
import _ "github.com/lib/pq"

connStr := "host=cluster.example.com port=26257 user=root dbname=defaultdb sslmode=verify-full sslrootcert=/path/to/ca.crt"
db, err := sql.Open("postgres", connStr)
if err != nil { log.Fatal(err) }

For Java (JDBC), use:

String url = "jdbc:postgresql://cluster.example.com:26257/defaultdb?sslmode=verify-full&sslrootcert=/path/to/ca.crt";
Connection conn = DriverManager.getConnection(url, "root", "");

3. Load Balancer and Network Controls
If using a load balancer (e.g., HAProxy, AWS NLB), ensure it passes through TLS without termination, or if terminating TLS, re-encrypt with valid CockroachDB-issued certs. Use network policies to restrict inter-node traffic to port 26257 only between known nodes.

4. Continuous Validation
Integrate middleBrick scans into CI/CD (via GitHub Action) to catch regressions. A Pro plan scan schedule can alert if a new node is added without proper certs. The remediation guidance in middleBrick's report will explicitly reference the need for sslmode=verify-full and valid CA chains.

Q: Does CockroachDB's default TLS protect against MITM?
A: Yes, if properly configured. By default, CockroachDB generates self-signed certificates and requires clients to use sslmode=verify-full with the provided CA. However, if clients use sslmode=require or disable, or if nodes are started with --accept-invalid-certs, MITM becomes possible.

A: middleBrick scans the publicly accessible API endpoint (the SQL port). If the cluster is not publicly reachable, you can use the CLI tool within your VPC or the MCP Server from an IDE with network access. The scanner tests the live endpoint's TLS configuration, so it will detect weaknesses regardless of firewall position, as long as it can reach the port.