Zone Transfer in Cockroachdb

In CockroachDB, a "zone transfer" refers to the unintended exposure of replication zone configurations through unauthenticated access to the SQL interface or the admin HTTP endpoint. Zone configurations control how ranges are replicated, where they are placed, and what constraints apply to specific tables or databases. If an attacker can read these settings, they learn the topology of the cluster, replication factors, and any custom constraints that could be leveraged for further attacks such as targeted data exfiltration or denial‑of‑service.

The exposure typically occurs via one of two pathways:

• Unauthenticated SQL access: CockroachDB listens on the PostgreSQL wire protocol (default port 26257). If the cluster is started without requiring client authentication (e.g., using --insecure or with permissive host‑based authentication), anyone who can reach the port can execute SQL statements. The statement SHOW ZONE CONFIGURATION FOR DATABASE db_name; or SHOW ZONE CONFIGURATION FOR TABLE tbl; returns the full zone JSON, including num_replicas, constraints, and gc.ttlseconds.
• Unprotected admin HTTP endpoint: The admin UI runs on port 8080 by default and exposes several JSON endpoints under /_status/v1/. One of these, /_status/v1/zone-configurations (available in recent versions), returns the same zone configuration data as the SQL statement. If the HTTP listener is bound to a public interface and no firewall or authentication is in place, a simple GET request leaks the configuration.

Both paths are analogous to a DNS zone transfer (AXFR) where an internal data structure is disclosed to anyone who can query the service. The risk is not that the data itself is altered, but that the attacker gains intelligence about the cluster’s layout, which can inform subsequent, more impactful attacks.

Detecting an exposed zone transfer with middleBrick involves probing for the two unauthenticated access vectors described above. Because middleBrick performs unauthenticated, black‑box checks, it will automatically attempt:

• A TCP connection to the PostgreSQL port (default 26257) followed by a minimal authentication handshake. If the server accepts the connection without requiring credentials, middleBrick issues the SQL command SHOW ZONE CONFIGURATION; and inspects the response for JSON containing keys like num_replicas or constraints.
• An HTTP GET request to the admin interface (commonly http://<host>:8080/_status/v1/zone-configurations). A successful 200 response with a JSON body that includes an array of zone objects indicates exposure.

When either check succeeds, middleBrick returns a finding under the "Information Exposure" category with severity based on the exposure level (e.g., if both SQL and HTTP are open, the finding is escalated). The finding includes:

• The exact endpoint or port that leaked the configuration.
• A snippet of the returned zone JSON (truncated for brevity).
• Remediation guidance tailored to CockroachDB.

Example of a middleBrick finding (JSON output from the CLI):

{
  "category": "Information Exposure",
  "severity": "medium",
  "title": "Unauthenticated zone configuration exposure",
  "description": "The cluster’s replication zone configuration is accessible via unauthenticated SQL on port 26257.",
  "evidence": "SHOW ZONE CONFIGURATION returned {\"num_replicas\":3,\"constraints\":[{\"type\":\"+\"}]}",
  "remediation": "Enable authentication for the SQL interface and/or restrict the admin HTTP listener to trusted networks."
}

This output can be consumed directly in CI/CD pipelines (e.g., the middleBrick GitHub Action) to fail a build when the score drops below a defined threshold.

Remediation focuses on closing the unauthenticated access paths while preserving legitimate admin and application connectivity. CockroachDB provides native controls for both the SQL interface and the admin HTTP endpoint.

1. Secure the SQL (PostgreSQL) interface

• Start the node with authentication enabled. The simplest production‑ready method is to use TLS with client certificates: cockroach start --certs-dir=certs --listen-addr=localhost:26257 --http-addr=localhost:8080 --background. When TLS is required, unauthenticated TCP connections are rejected at the transport layer.
• If TLS is not feasible, enforce host‑based authentication via a pg_hba.conf-style file. Example entry to allow only specific application hosts: host all all 10.0.0.0/24 md5.
• After authentication is in place, restrict the SHOW ZONE CONFIGURATION privilege to administrative roles only. By default, the statement is readable by any authenticated user; you can revoke it from the public role and grant it to a dedicated admin role:

  REVOKE SHOW ZONE CONFIGURATION ON DATABASE defaultdb FROM PUBLIC;
  GRANT SHOW ZONE CONFIGURATION ON DATABASE defaultdb TO admin_role;
  

• Regularly audit role membership with SHOW GRANTS ON ROLE admin_role; to ensure no unintended grants have been added.

2. Lock down the admin HTTP endpoint

• Bind the HTTP listener to a loopback or internal interface only: cockroach start --http-addr=10.0.0.5:8080 .... This prevents external reachability without affecting internal tooling that can access the node via the private network.
• If the admin UI must be exposed (e.g., for monitoring), place it behind a reverse proxy that enforces authentication (e.g., OAuth2, basic auth) or restrict access via network security groups / firewall rules.
• Disable the specific zone‑configuration endpoint if it is not needed. In CockroachDB v22.2 and later, the endpoint can be turned off with the cluster setting SET CLUSTER SETTING server.status_endpoint.enable_zone_config = false;.

3. Validate the fix with middleBrick

After applying the changes, run middleBrick again against the same target. A clean scan will show no findings under Information Exposure for zone transfer, and the overall security score will improve (e.g., from a D to a B).

Example CLI verification:

middlebrick scan https://api.example.com
# Output: Security Score: B (85/100)
# No findings related to "Unauthenticated zone configuration exposure".

By combining authentication, network segmentation, and privilege controls, you eliminate the zone‑transfer information leak while maintaining full operational capability for administrators and applications.