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 ID | Name | Severity |
|---|---|---|
| CWE-287 | Improper Authentication | CRITICAL |
| CWE-306 | Missing Authentication for Critical Function | CRITICAL |
| CWE-307 | Brute Force | HIGH |
| CWE-308 | Single-Factor Authentication | MEDIUM |
| CWE-309 | Use of Password System for Primary Authentication | MEDIUM |
| CWE-347 | Improper Verification of Cryptographic Signature | HIGH |
| CWE-384 | Session Fixation | HIGH |
| CWE-521 | Weak Password Requirements | MEDIUM |
| CWE-613 | Insufficient Session Expiration | MEDIUM |
| CWE-640 | Weak Password Recovery | HIGH |
Frequently Asked Questions
How does middleBrick detect Cockroachdb authentication bypass vulnerabilities?
insecure startup flag and trust-based authentication modes that allow bypass without credentials.