Missing Authentication in Cockroachdb

CockroachDB can be run in an insecure mode for local development by starting the node with the --insecure flag. In this mode the database disables all authentication mechanisms and allows any client to connect via the PostgreSQL wire protocol (default port 26257) or access the built‑in HTTP admin UI (default port 8080) without providing credentials. When this configuration is promoted to a staging or production environment, attackers can:

• Connect as the default root user and execute arbitrary SQL statements, leading to data exfiltration, schema modification, or ransomware‑style attacks.
• Access the admin UI to view cluster metrics, node lists, and running jobs, which can reveal internal topology useful for further lateral movement.
• Execute administrative commands such as SHOW RANGES or ALTER DATABASE ... SET ... to disrupt service availability.

A real‑world example is CVE‑2020-14156, which reported that CockroachDB versions prior to 20.2 allowed unauthenticated access to the HTTP admin UI when started with --insecure. Although the CVE focuses on the UI, the same root cause—missing authentication—applies to the SQL endpoint.

In application code, missing authentication often appears as a connection string that omits user credentials or relies on default credentials. For instance, using the Go pgx driver:

// Insecure: no username/password, assumes --insecure mode
conn, err := pgx.Connect(context.Background(), "postgres://localhost:26257/defaultdb?sslmode=disable")
if err != nil {
    log.Fatal(err)
}
// If the cluster is running with --insecure, this succeeds without any auth.

The same pattern appears in Node.js with pg:

// Insecure: connection string lacks user/password
const { Client } = require('pg');
const client = new Client({
    host: 'localhost',
    port: 26257,
    database: 'defaultdb',
    // No user or password provided
});
await client.connect(); // Succeeds if --insecure is enabled

These code paths illustrate how missing authentication can be introduced unintentionally when developers copy a local‑development connection string into a higher‑environment configuration.

Because middleBrick performs a black‑box, unauthenticated scan of the attack surface, it can discover missing authentication in CockroachDB without any prior knowledge of credentials or agents. The scanner:

• Attempts to establish a raw TCP connection to the SQL port (26257) and issues a simple PostgreSQL startup packet. If the server responds with an authentication request that accepts any user (or none), the scanner marks the endpoint as unauthenticated.
• Sends an HTTP GET request to the admin UI port (typically 8080) and looks for the CockroachDB welcome page or metrics endpoint. A successful 200 response without a challenge indicates the UI is exposed without authentication.
• Checks for common misconfigurations such as the presence of the --insecure flag indirectly by verifying that both the SQL and HTTP ports are reachable without credentials.

When such a condition is found, middleBrick returns a finding under the "Authentication" category with a severity rating (typically High or Critical depending on exposure) and includes remediation guidance. The finding also references the relevant OWASP API Security Top 10 item (Broken Authentication) and can be mapped to compliance frameworks like PCI‑DSS Requirement 8 (Identify and authenticate access to system components) and GDPR Article 32 (Security of processing).

Example of a middleBrick CLI invocation that would surface this issue:

middlebrick scan https://api.example.com

The resulting JSON report would contain a section similar to:

{
  "category": "Authentication",
  "severity": "high",
  "title": "Unauthenticated access to CockroachDB SQL endpoint",
  "description": "The scanner was able to connect to port 26257 and issue a SQL startup packet without providing credentials, indicating the cluster is running with --insecure or missing authentication.",
  "remediation": "Run CockroachDB with proper TLS certificates and strong user passwords. Disable --insecure in all non‑development environments."
}

Thus, middleBrick provides actionable detection without requiring any internal instrumentation or credentials from the user.

To eliminate missing authentication, configure CockroachDB to require strong authentication and encrypt traffic with TLS. The steps below use CockroachDB’s native tooling.

1. Generate TLS certificates (if not using a managed service):
   

   cockroach cert create-ca --certs-dir=certs --ca-key=certs/ca.key
   cockroach cert create-node localhost $(hostname) --certs-dir=certs --ca-key=certs/ca.key
   cockroach cert create-user root --certs-dir=certs --ca-key=certs/ca.key
   

2. Start the node with TLS enforcement (omit --insecure):
   

   cockroach start --certs-dir=certs --listen-addr=localhost:26257 --http-addr=localhost:8080 --background
   

3. Set a strong password for the root user (or create a dedicated application user):
   

   ALTER USER root WITH PASSWORD 'StrongRandomPassword123!';
   

4. Use authenticated connection strings in applications. Example in Go with pgx and TLS:

   cfg, err := pgx.ParseConfig("")
   if err != nil { log.Fatal(err) }
   cfg.Host = "localhost"
   cfg.Port = 26257
   cfg.Database = "defaultdb"
   cfg.User = "root"
   cfg.Password = "StrongRandomPassword123!"
   cfg.TLSConfig = &tls.Config{RootCAs: certPool} // load CA cert
   conn, err := pgx.ConnectConfig(context.Background(), cfg)
   

   Example in Node.js with pg:

   const { Client } = require('pg');
   const client = new Client({
       host: 'localhost',
       port: 26257,
       database: 'defaultdb',
       user: 'root',
       password: 'StrongRandomPassword123!',
       ssl: { rejectUnauthorized: true, ca: fs.readFileSync('certs/ca.crt').toString() }
   });
   await client.connect();
   

5. Disable the HTTP admin UI or protect it with a reverse proxy and authentication if external access is not required:
   

   # Start without HTTP endpoint
   cockroach start --certs-dir=certs --listen-addr=localhost:26257 --http-addr= --background
   

6. Verify the configuration by attempting a connection without credentials; the attempt should now fail with an authentication error.

After applying these controls, a rescan with middleBrick will show the "Authentication" finding resolved, and the overall risk score will improve. This approach relies solely on CockroachDB’s built‑in security features—no agents, no external WAF, and no runtime patching.