HIGH auth bypasscockroachdb

Auth Bypass in Cockroachdb

How Auth Bypass Manifests in Cockroachdb

Authentication bypass in Cockroachdb occurs when attackers exploit weaknesses in how the database handles authentication tokens, connection strings, or role-based access control. The most common Cockroachdb-specific auth bypass patterns involve improper handling of SET CLUSTER SETTING statements, misconfigured authentication parameters, and token manipulation in connection strings.

One prevalent attack vector targets Cockroachdb's authentication configuration. When authentication is set to trust or password without proper encryption, attackers can intercept authentication traffic. Cockroachdb's default behavior of allowing connections without TLS when insecure mode is enabled creates a significant attack surface. The database accepts connections on port 26257 without requiring authentication if insecure is set to true in the startup configuration.

Consider this vulnerable Cockroachdb setup:

# Insecure Cockroachdb startup - NEVER use in production
cockroach start-single-node --insecure --listen-addr=localhost:26257

This configuration allows any process on the host to connect without authentication. Attackers can exploit this by connecting directly to the database using standard PostgreSQL clients:

# Bypass authentication completely
psql -h localhost -p 26257 -U root -d system

Another Cockroachdb-specific auth bypass involves SET CLUSTER SETTING statements that modify authentication behavior at runtime. If an application has admin privileges and executes:

SET CLUSTER SETTING server.authentication.password_encryption = 'plain';

This changes the password encryption method to plain text, allowing attackers who capture network traffic to easily extract credentials. The setting persists until the cluster restarts, creating a persistent vulnerability window.

Role-based access control (RBAC) misconfigurations in Cockroachdb also enable auth bypass. When root privileges are granted to application roles that shouldn't have them, attackers can escalate privileges. The following pattern is particularly dangerous:

-- Vulnerable: Overly permissive role grants
GRANT admin TO application_user;

With admin privileges, application_user can modify authentication settings, create new users, and bypass all security controls. Cockroachdb's admin role is equivalent to PostgreSQL's SUPERUSER but with additional cluster management capabilities.

Connection string manipulation represents another Cockroachdb-specific auth bypass vector. Cockroachdb supports multiple connection string formats, and some implementations fail to properly validate authentication parameters:

# Vulnerable connection string - missing password validation
postgresql://host:26257/defaultdb?sslmode=disable

When sslmode=disable is combined with missing password parameters, Cockroachdb may fall back to trust-based authentication, allowing unauthorized access. This is especially problematic in containerized environments where connection strings are constructed dynamically.

Cockroachdb-Specific Detection

Detecting authentication bypass vulnerabilities in Cockroachdb requires examining both configuration files and runtime behavior. The first step is scanning the database configuration for insecure settings.

Configuration file analysis should check for:

# Vulnerable Cockroachdb config - insecure settings
listener:
  address: 0.0.0.0:26257
  http_address: 0.0.0.0:8080
  cert_directory: ""
  authentication:
    client_protocol: "plain"
    server_protocol: "plain"

The presence of empty cert_directory and plain authentication protocols indicates the database is running without TLS encryption, making authentication bypass trivial for network-based attackers.

Runtime scanning with middleBrick specifically targets Cockroachdb authentication weaknesses. The scanner tests for:

  • Unencrypted authentication endpoints on default ports (26257, 26258)
  • Missing or weak authentication requirements
  • Excessive privilege grants to application roles
  • Runtime configuration changes via SET CLUSTER SETTING
  • Connection string parsing vulnerabilities

middleBrick's Cockroachdb-specific checks include testing for the insecure startup flag and attempting unauthenticated connections to detect trust-based authentication. The scanner also examines SQL injection points that could lead to authentication bypass through privilege escalation.

Manual detection techniques for Cockroachdb include:

-- Check for insecure authentication settings
SHOW CLUSTER SETTING server.authentication.password_encryption;

-- Identify overly privileged roles
SELECT rolname, rolcreaterole, rolcreatedb, roladmin 
FROM pg_catalog.pg_roles 
WHERE rolname != 'root' AND (rolcreaterole OR rolcreatedb OR roladmin);

-- Check for disabled TLS
SELECT * FROM crdb_internal.node_build_info 
WHERE build_tag LIKE '%insecure%';

These queries reveal configuration issues that enable authentication bypass. The crdb_internal.node_build_info view specifically shows whether the cluster was started in insecure mode.

Network-level detection involves scanning for open Cockroachdb ports and testing authentication requirements. Tools like nmap can identify exposed Cockroachdb instances:

nmap -p 26257-26258 --script=pgsql-brute 

Successful connections without credentials indicate authentication bypass vulnerabilities. middleBrick automates this testing with specialized Cockroachdb authentication modules that attempt various bypass techniques.

Cockroachdb-Specific Remediation

Remediating authentication bypass vulnerabilities in Cockroachdb requires implementing defense-in-depth controls across configuration, network, and application layers. The foundation is proper TLS encryption for all database connections.

Generate and configure TLS certificates for Cockroachdb:

# Generate CA and node certificates
cockroach cert create-ca --certs-dir=certs --ca-key=my-ca-key.pem
cockroach cert create-node localhost $(hostname) --certs-dir=certs --ca-key=my-ca-key.pem
cockroach cert create-client root --certs-dir=certs --ca-key=my-ca-key.pem

Configure Cockroachdb to require TLS:

listener:
  address: 0.0.0.0:26257
  http_address: 0.0.0.0:8080
  cert_directory: "/path/to/certs"
  authentication:
    client_protocol: "cert-password"
    server_protocol: "cert-password"

The cert-password protocol requires both TLS certificates and password authentication, eliminating trust-based bypass.

Implement proper role-based access control:

-- Create principle of least privilege roles
CREATE ROLE application_user WITH LOGIN PASSWORD 'strong_password';

-- Grant only necessary privileges
GRANT SELECT, INSERT, UPDATE ON TABLE production_data TO application_user;

-- Revoke admin privileges from application roles
REVOKE admin FROM application_user;

-- Create separate admin role for database management
CREATE ROLE db_admin WITH CREATEROLE CREATEDB;

This separation ensures application users cannot modify authentication settings or create new privileged accounts.

Prevent runtime authentication changes by restricting SET CLUSTER SETTING access:

-- Revoke cluster setting modification from non-admin roles
REVOKE SET ON SYSTEM FROM application_user;

-- Audit cluster setting changes
CREATE TABLE auth_audit (
    timestamp TIMESTAMP,
    user TEXT,
    setting TEXT,
    old_value TEXT,
    new_value TEXT
);

CREATE OR REPLACE FUNCTION audit_cluster_setting_change()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO auth_audit VALUES (
        now(),
        current_user,
        TG_NAME,
        OLD.cluster_setting,
        NEW.cluster_setting
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER audit_cluster_setting_trigger
AFTER UPDATE ON crdb_internal.cluster_settings
FOR EACH ROW EXECUTE FUNCTION audit_cluster_setting_change();

This audit trail detects unauthorized authentication configuration changes.

Secure connection string handling in application code:

// Secure Cockroachdb connection in Go
import (
    "github.com/lib/pq"
    "crypto/tls"
    "crypto/x509"
)

func createSecureConnection() (*sql.DB, error) {
    cert, err := tls.LoadX509KeyPair("certs/client.root.crt", "certs/client.root.key")
    if err != nil {
        return nil, err
    }
    
    caCert, err := ioutil.ReadFile("certs/ca.crt")
    if err != nil {
        return nil, err
    }
    
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)
    
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{cert},
        RootCAs:      caCertPool,
        MinVersion:   tls.VersionTLS12,
    }
    
    connStr := "postgresql://host:26257/defaultdb?sslmode=verify-full"
    db, err := sql.Open("postgres", connStr)
    if err != nil {
        return nil, err
    }
    
    db.SetConnMaxLifetime(time.Minute * 5)
    return db, nil
}

This code enforces TLS verification and prevents authentication bypass through unencrypted connections. middleBrick's remediation guidance includes similar code examples for multiple programming languages, helping developers implement secure Cockroachdb authentication patterns.

Related CWEs: authentication

CWE IDNameSeverity
CWE-287Improper Authentication CRITICAL
CWE-306Missing Authentication for Critical Function CRITICAL
CWE-307Brute Force HIGH
CWE-308Single-Factor Authentication MEDIUM
CWE-309Use of Password System for Primary Authentication MEDIUM
CWE-347Improper Verification of Cryptographic Signature HIGH
CWE-384Session Fixation HIGH
CWE-521Weak Password Requirements MEDIUM
CWE-613Insufficient Session Expiration MEDIUM
CWE-640Weak Password Recovery HIGH

Frequently Asked Questions

How does middleBrick detect Cockroachdb authentication bypass vulnerabilities?
middleBrick scans Cockroachdb endpoints for insecure authentication configurations, including testing for unencrypted connections on default ports, attempting unauthenticated access, and checking for overly permissive role grants. The scanner specifically looks for Cockroachdb's insecure startup flag and trust-based authentication modes that allow bypass without credentials.
Can middleBrick scan my Cockroachdb instance if it's behind a firewall?
Yes, middleBrick can scan any publicly accessible API endpoint. If your Cockroachdb instance is behind a firewall, you'll need to expose it temporarily for scanning or use middleBrick's CLI tool to scan from within your network. The scanner requires network access to the database port (typically 26257) to perform authentication bypass testing.