Broken Authentication on Docker

Broken authentication in Docker environments often stems from insecure container configurations and exposed management interfaces. The most common vulnerability occurs when Docker daemon sockets are exposed to the internet without proper authentication controls. By default, Docker listens on Unix sockets, but when misconfigured to bind to TCP ports (0.0.0.0:2375 for HTTP or 2376 for HTTPS), it becomes accessible to anyone on the network.

# Vulnerable configuration - DO NOT USE
DOCKER_OPTS="-H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"

This configuration allows unauthenticated access to the Docker API, enabling attackers to list containers, execute commands inside running containers, create new containers with mounted host volumes, and potentially gain root access to the host system. The Docker Engine API accepts commands without authentication by default when exposed this way.

Another Docker-specific authentication issue arises from improper image permissions. When building Docker images, developers sometimes use the root user without considering the security implications:

FROM node:14
USER root
# Vulnerable - running as root in container
RUN npm install
CMD ["node", "server.js"]

Running containers as root creates a privilege escalation path. If an attacker compromises the application inside the container, they inherit root privileges within the container and can potentially break out to the host system using known container escape techniques.

Docker Hub and registry authentication bypasses represent another attack vector. When pulling images without proper authentication or verification, malicious images can be deployed. The official Docker Hub registry doesn't verify image integrity beyond basic checksums, and if credentials are hardcoded in Dockerfiles or CI/CD pipelines, they can be exposed through image history or build logs.

Container orchestration platforms like Docker Swarm and Kubernetes (when using Docker) introduce additional authentication concerns. Default configurations may expose cluster management APIs without proper authentication, allowing attackers to deploy malicious containers across the entire cluster.

Detecting broken authentication in Docker environments requires examining both configuration files and runtime behavior. Start by checking Docker daemon configuration files for exposed TCP ports:

# Check systemd service file
systemctl cat docker | grep -E "(tcp|2375|2376)"

# Check for exposed ports in dockerd config
ps aux | grep dockerd | grep -E "(tcp|0.0.0.0)"

Network scanning tools can identify exposed Docker APIs. Nmap scripts specifically detect Docker daemon exposure:

nmap -sV --script docker-version -p 2375,2376 target-ip
nmap -sV --script docker-info -p 2375,2376 target-ip

For runtime detection, middleBrick's Docker-specific scanning identifies authentication vulnerabilities by testing the Docker API endpoints. The scanner attempts unauthenticated connections to common Docker ports and analyzes the responses to determine if authentication is properly enforced. It checks for:

• Unauthenticated access to Docker daemon APIs
• Container escape vulnerabilities in privileged containers
• Exposed registry credentials in image layers
• Default passwords or weak authentication mechanisms
• Exposed Docker Compose files with embedded credentials

middleBrick's black-box scanning approach means it tests the actual running Docker environment without requiring access to source code or build configurations. The scanner provides a security score (A-F) and specific findings with severity levels, mapping directly to OWASP API Top 10 authentication failures.

Additional detection methods include examining Docker images for embedded secrets using tools like Trivy or Dockle, which can identify hardcoded credentials, private keys, and other sensitive data in image layers. Container runtime monitoring tools like Falco can detect anomalous authentication patterns and privilege escalation attempts.

Securing Docker authentication starts with proper daemon configuration. Always bind Docker to Unix sockets and use Docker's built-in TLS authentication for remote access:

# Secure configuration - USE THIS
DOCKER_OPTS="-H unix:///var/run/docker.sock --tlsverify --tlscacert=/etc/docker/ca.pem --tlscert=/etc/docker/server-cert.pem --tlskey=/etc/docker/server-key.pem"

Generate TLS certificates and keys for Docker daemon authentication:

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

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

Run containers with non-root users to minimize privilege escalation risks:

FROM node:14
# Create non-root user
RUN addgroup -gid 1001 -S nodejs
RUN adduser -uid 1001 -S nodejs -G nodejs
USER nodejs
WORKDIR /home/nodejs
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]

For multi-stage builds that require root for installation but run as non-root:

FROM node:14 AS builder
USER root
RUN npm install

FROM node:14
RUN addgroup -gid 1001 -S nodejs && adduser -uid 1001 -S nodejs -G nodejs
USER nodejs
WORKDIR /app
COPY --from=builder node_modules node_modules
COPY . .
CMD ["node", "server.js"]

Implement proper authentication for Docker registries and image pulls. Use Docker Content Trust to verify image integrity:

export DOCKER_CONTENT_TRUST=1
# Only pull signed images
docker pull myregistry.example.com/myapp:latest

For Docker Compose files, avoid embedding credentials directly. Use environment variables or external secret management:

version: '3.8'
secrets:
  db_password:
    external: true
    name: myapp_db_password

services:
  web:
    image: myapp:latest
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    secrets:
      - db_password

Enable Docker's built-in authentication mechanisms for Swarm and Kubernetes when using Docker as a runtime. Use RBAC (Role-Based Access Control) to limit container capabilities and network access. Implement network segmentation so containers can only communicate with necessary services.