Auth Bypass on Docker

Auth bypass in Docker environments often occurs through misconfigured container networking, exposed administrative interfaces, and improper authentication layer implementations. The Docker daemon itself listens on a Unix socket by default, but when misconfigured to listen on TCP ports without proper authentication, it creates a critical attack surface.

# INSECURE: Docker daemon listening on all interfaces without auth
DOCKER_OPTS="-H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"

This configuration allows anyone on the network to connect to the Docker API and execute commands without authentication. An attacker can list containers, pull images, or even execute commands inside running containers:

# Extract container data without authentication
curl http://docker-host:2375/containers/json

# Execute commands in containers
curl -X POST http://docker-host:2375/containers/container_id/exec -d '{"Cmd": ["cat", "/etc/passwd"]}'

Another common Docker-specific auth bypass occurs with exposed Docker registries. When a registry is deployed without authentication and accessible from the network, attackers can push malicious images or pull sensitive data:

# INSECURE: Registry without authentication
version: '3'
services:
  registry:
    image: registry:2
    ports:
      - "5000:5000"
    volumes:
      - ./data:/var/lib/registry

Container escape vulnerabilities can also lead to auth bypass by allowing attackers to break out of containerized environments and access the host system where Docker credentials might be stored:

// Example of a container escape via cgroups v1
// CVE-2022-0185 - allows writing to read-only files
// This can lead to privilege escalation and Docker daemon access

Multi-stage builds without proper access controls can inadvertently expose intermediate stages containing secrets or credentials:

# BUILD STAGE - credentials exposed if not properly cleaned
FROM alpine AS builder
RUN apk add --no-cache git
RUN git clone https://github.com/private/repo.git /app
RUN npm install --unsafe-perm

# FINAL STAGE - but attacker can access build cache
FROM node:18-alpine
COPY --from=builder /app /app
# If build cache is exposed, credentials from builder stage are accessible

Detecting auth bypass vulnerabilities in Docker requires both configuration scanning and runtime monitoring. Start by examining Docker daemon configurations and network exposure:

# Check Docker daemon listening addresses
sudo netstat -tulpn | grep docker
# Look for: tcp://0.0.0.0:2375 (insecure) vs tcp://127.0.0.1:2375 (secure)

# Check for exposed registry ports
sudo netstat -tulpn | grep 5000

# Verify authentication configuration
sudo cat /etc/docker/daemon.json

For registry authentication verification, test with curl:

# Test if registry requires authentication
curl -I http://registry-host:5000/v2/_catalog
# Should return 401 Unauthorized if properly secured

Docker inspect commands reveal container networking configurations that might expose administrative interfaces:

# Check container port mappings and network exposure
docker inspect $(docker ps -q) | jq '.[].NetworkSettings.Ports'

# Look for containers with port 2375, 5000, or admin interfaces exposed

middleBrick provides automated detection of Docker-specific auth bypass vulnerabilities through its black-box scanning approach. The scanner tests for exposed Docker APIs, registry endpoints, and authentication bypass patterns without requiring credentials or installation:

# Scan a Docker host or registry URL with middleBrick
middlebrick scan http://docker-host:2375

# Scan a registry endpoint
middlebrick scan http://registry.company.com:5000

The scanner identifies vulnerabilities like exposed Docker daemon APIs, unauthenticated registry access, and weak authentication mechanisms. Results include severity ratings and specific remediation steps for Docker environments.

For containerized applications, examine service configurations that might expose admin interfaces:

# INSECURE: Admin interface exposed without auth
admin:
  image: admin-panel:latest
  ports:
    - "9000:9000"  # No authentication required
  environment:
    - ADMIN_ENABLED=true

Runtime monitoring with Docker events can detect suspicious authentication patterns:

# Monitor Docker events for auth-related activities
docker events --filter 'type=container' --filter 'event=start'

# Look for unexpected container starts or exec commands

Securing Docker against auth bypass requires multiple layers of protection. Start with Docker daemon configuration:

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://127.0.0.1:2375"],
  "tlsverify": true,
  "tlscacert": "/etc/docker/ca.pem",
  "tlscert": "/etc/docker/server-cert.pem",
  "tlskey": "/etc/docker/server-key.pem"
}

This configuration ensures the Docker daemon only accepts local connections and requires TLS client authentication for remote access. Generate certificates using:

# Generate CA
sudo openssl genrsa -out ca-key.pem 4096
sudo openssl req -x509 -new -key ca-key.pem -sha256 -days 365 -out ca.pem

# Generate server certificate
sudo openssl genrsa -out server-key.pem 4096
sudo openssl req -subj "/CN=server" -new -key server-key.pem -out server.csr
sudo echo subjectAltName = IP:127.0.0.1 > extfile.cnf
sudo openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem -extfile extfile.cnf

For registry authentication, implement basic auth or token-based authentication:

# SECURE: Registry with authentication
version: '3'
services:
  registry:
    image: registry:2
    ports:
      - "5000:5000"
    environment:
      - REGISTRY_AUTH=htpasswd
      - REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm
      - REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd
    volumes:
      - ./data:/var/lib/registry
      - ./auth:/auth

Create the htpasswd file:

# Create authentication file
docker run \
  --entrypoint htpasswd \
  registry:2 -Bbn username password > auth/htpasswd

Container network isolation prevents unauthorized access to Docker APIs:

# SECURE: Isolated network for Docker services
services:
  app:
    image: myapp:latest
    networks:
      - app-network
    ports:
      - "3000:3000"

  db:
    image: postgres:latest
    networks:
      - app-network
    environment:
      - POSTGRES_PASSWORD=secret
    ports:
      - "5432:5432"  # Only accessible within app-network

networks:
  app-network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16

Implement Docker Content Trust to verify image integrity:

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1

# Only pull signed images
docker pull myapp:latest

For CI/CD environments, use Docker BuildKit with secret mounting instead of build arguments:

# SECURE: Using BuildKit secrets
# syntax=docker/dockerfile:1.3

FROM alpine AS builder

# Use secrets instead of --build-arg
RUN --mount=type=secret,id=github_token \
    git clone https://[email protected]/private/repo.git /app

FROM node:18-alpine
COPY --from=builder /app /app

Finally, implement runtime security monitoring with Docker Bench Security or similar tools to continuously validate configurations:

# Run Docker Bench Security
git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
./docker-bench-security.sh