Phishing Api Keys in Cockroachdb

Phishing for API keys in CockroachDB environments targets the credentials used to authenticate to its SQL interface (via cockroach sql or drivers) and its HTTP API (Admin UI, Changefeed, etc.). Attackers exploit common misconfigurations where these secrets are inadvertently exposed in client-side code, configuration files, or version control.

CockroachDB-Specific Attack Patterns:

• Connection String Leakage: Applications often embed CockroachDB connection strings (e.g., postgresql://user:password@host:26257/defaultdb?sslmode=verify-full) in frontend code, environment files (.env), or public repositories. If sslmode=disable or verify-ca is used, credentials may even be transmitted in plaintext over the network.
• HTTP API Basic Auth Exposure: The CockroachDB HTTP API (e.g., for Changefeeds or Admin UI) uses Basic Auth. API keys (passwords) can be phished if they appear in URLs (e.g., https://user:password@cluster.cockroachlabs.cloud:8081), which get logged in browser history, proxy logs, or referer headers.
• Default/Weak Credentials: Insecure initial setups might use default passwords (e.g., from quickstart guides) or weak passwords that are easily guessed or brute-forced, especially if the SQL port (26257) or HTTP port (8080/8081) is exposed to the internet without firewall rules.
• Client Library Misuse: Driver connection code (Go, Python, Java) that hardcodes passwords or reads them from insecure locations can be reverse-engineered if the binary is distributed or if source code is leaked.

For example, a Node.js application might leak a CockroachDB password in a client-side bundle:

// VULNERABLE: Password in frontend code
const dbUrl = "postgresql://app_user:Secur3P@ss!@db.example.com:26257/appdb";
// This string gets bundled and visible to anyone inspecting the client-side JavaScript.

Detection involves scanning for exposed credentials in HTTP requests/responses and analyzing CockroachDB-specific authentication patterns. middleBrick's unauthenticated black-box scan tests the API's external surface without credentials, looking for:

• API keys in URLs/Headers: Checking if HTTP requests to CockroachDB's HTTP endpoints (e.g., /api/v2/...) contain Basic Auth credentials in the Authorization header or URL userinfo.
• Connection string patterns: Searching response bodies for PostgreSQL-style connection strings that include passwords.
• Error message leakage: Triggering authentication errors (e.g., wrong password) and checking if the error reveals whether the username exists (user enumeration), which aids phishing.
• OpenAdmin UI exposure: Detecting if the CockroachDB Admin UI (port 8080/8081) is publicly accessible without authentication, as it may display connection details.

A middleBrick scan of a CockroachDB HTTP endpoint might return a finding like:

{
  "check": "authentication",
  "severity": "critical",
  "title": "API Key Exposure in URL",
  "description": "Password found in URL userinfo component. Credentials may be logged in server logs, browser history, or referer headers.",
  "evidence": {
    "url": "https://admin:cockroachdb_password@cluster.cockroachlabs.cloud:8081",
    "param": "userinfo"
  },
  "remediation": "Never include credentials in URLs. Use HTTP Basic Auth via the Authorization header or client certificates."
}

Additionally, middleBrick's OpenAPI/Swagger analysis can detect if an API spec (if provided) documents authentication schemes that use static API keys in headers or query parameters, which is a design flaw for CockroachDB integrations.

Remediation focuses on eliminating static secrets and enforcing strong, certificate-based authentication. CockroachDB provides native features to replace password-based auth with more secure methods.

1. Use Certificate-Based Authentication (Recommended)

Replace password-based SQL authentication with client certificates. Generate a CA and node/client certificates, then configure CockroachDB to require certs. Connection strings then omit passwords:

// Go example with pgx (cert-based, no password)
connStr := "postgresql://app_user@db.example.com:26257/appdb?sslmode=verify-full&sslrootcert=/path/to/ca.crt&sslcert=/path/to/client.crt&sslkey=/path/to/client.key"

For the HTTP API, use mutual TLS (mTLS) instead of Basic Auth.

2. Rotate and Revoke Compromised Credentials

If a password is exposed, immediately rotate it using SQL:

-- Change password for a user
ALTER USER app_user WITH PASSWORD 'NewStrong!Pass123';
-- Or revoke all privileges and drop the user if compromised
REVOKE ALL ON DATABASE appdb FROM app_user;
DROP USER app_user;

For HTTP API Basic Auth, change the password in the CockroachDB Cloud console or via ALTER USER for HTTP users.

3. Secure Client Configuration

Never hardcode credentials. Use environment variables or secret managers:

// Python example using psycopg2 and env vars
import os
from psycopg2 import connect

conn = connect(
    host=os.getenv('DB_HOST'),
    port=os.getenv('DB_PORT', '26257'),
    user=os.getenv('DB_USER'),
    password=os.getenv('DB_PASSWORD'),  # Loaded from secure env, not in code
    dbname=os.getenv('DB_NAME'),
    sslmode='verify-full'
)

4. Network-Level Controls

Restrict CockroachDB SQL (26257) and HTTP (8080/8081) ports to trusted IPs using firewall rules or CockroachDB Cloud's IP allowlist. This prevents external scanners from even reaching the authentication surface.

5. Audit and Monitor

Enable CockroachDB's audit logging to track authentication events. Use middleBrick's continuous monitoring (Pro plan) to regularly scan for accidental re-exposure of credentials after deployments.

To prevent phishing-related credential leaks, embed security checks early. middleBrick's tools allow seamless integration:

• CLI: Scan your CockroachDB-connected API endpoints before commit: middlebrick scan https://api.example.com
• GitHub Action: Add a step to your workflow to fail the build if middleBrick detects critical authentication issues like exposed API keys.
• MCP Server: While developing in an IDE like Cursor, use the middleBrick MCP to scan your local or staging API endpoints directly from the editor.

For CockroachDB specifically, also incorporate SQL linting tools (like sqlc or custom scripts) to detect hardcoded passwords in migration files or application code.