Dictionary Attack on Docker
How Dictionary Attack Manifests in Docker
Dictionary attacks in Docker environments typically target exposed management interfaces and misconfigured authentication endpoints. The most common attack vector is against Docker's REST API, which by default listens on Unix sockets but can be accidentally exposed over TCP ports (2375 for unencrypted, 2376 for TLS).
Attackers scan for exposed Docker APIs using tools like Shodan or masscan, then attempt to authenticate using common credential combinations. A typical dictionary attack might try:
GET /containers/json HTTP/1.1
Host: target-ip:2375
Authorization: Basic YWRtaW46YWRtaW4=or simpler brute-force attempts without authentication headers, hoping to hit a misconfigured endpoint that allows unauthenticated access.
Another Docker-specific manifestation occurs with container registries. Attackers target exposed Docker Registry v2 APIs (port 5000) with credential stuffing attacks:
POST /v2/auth
Host: registry.example.com
Content-Type: application/json
{
"username": "admin",
"password": "password123"
}Container orchestration platforms like Kubernetes add another layer. When Docker is used within Kubernetes clusters, exposed kubelet APIs (port 10250) can be dictionary attacked to gain node-level access:
POST /api/v1/namespaces/kube-system/secrets
Host: kubelet-ip:10250
Content-Type: application/json
{
"apiVersion": "v1",
"kind": "Secret",
"metadata": {
"name": "test-secret"
}
}Volume mounts and bind mounts create additional attack surfaces. If a Docker daemon is exposed and has access to sensitive host directories, successful authentication allows attackers to mount these volumes and extract credentials:
POST /containers/create
Host: target-ip:2375
Content-Type: application/json
{
"Image": "alpine",
"HostConfig": {
"Binds": ["/etc/passwd:/mnt/passwd", "/root/.ssh:/mnt/ssh"]
}
}Docker-Specific Detection
Detecting dictionary attacks in Docker environments requires monitoring multiple layers. Network-level detection should watch for repeated authentication attempts on Docker's standard ports (2375, 2376, 5000). Use fail2ban with Docker-specific filters:
[docker-auth]
enabled = true
port = 2375,2376,5000
filter = docker-auth
logpath = /var/log/docker.log
maxretry = 3
bantime = 3600
findtime = 600Configure Docker daemon audit logging to track API access attempts:
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
},
"hosts": ["unix:///var/run/docker.sock", "tcp://127.0.0.1:2375"]Enable Docker Content Trust and verify image signatures to prevent supply chain attacks that might include credential-stealing malware:
export DOCKER_CONTENT_TRUST=1
export DOCKER_CONTENT_TRUST_SERVER=https://notary.docker.ioContainer runtime security tools like Falco can detect anomalous Docker API usage patterns:
- rule: Docker API Access
desc: Detect unauthorized Docker API access
condition: >
syscall.type=execve and
proc.name=docker and
(proc.cmdline contains "-H" or proc.cmdline contains "--host")
output: Docker API accessed (user=%user.name command=%proc.cmdline)
priority: WARNINGmiddleBrick's black-box scanning approach specifically tests Docker's exposed attack surface without requiring credentials. It attempts to detect:
- Unauthenticated Docker API endpoints
- Exposed registry APIs without authentication
- Default credentials in container configurations
- Exposed management ports in Docker Compose files
The scanner tests for common Docker vulnerabilities like CVE-2019-5736 (container escape) and CVE-2021-21284 (Docker Desktop privilege escalation) that could be chained with dictionary attacks for deeper compromise.
Docker-Specific Remediation
Securing Docker against dictionary attacks requires defense in depth. Start with daemon configuration:
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/override.conf > /dev/null <<EOF
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --tlsverify --tlscacert=/etc/docker/ca.pem --tlscert=/etc/docker/server-cert.pem --tlskey=/etc/docker/server-key.pem
EOF
sudo systemctl daemon-reload
sudo systemctl restart dockerThis configuration removes the default Unix socket exposure and requires TLS for all connections. Generate certificates with:
sudo openssl genrsa -out ca-key.pem 4096
sudo openssl req -x509 -newkey rsa:4096 -key ca-key.pem -sha256 -days 365 -out ca.pem
sudo openssl genrsa -out server-key.pem 4096
sudo openssl req -new -key server-key.pem -out server.csr
sudo openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pemImplement network segmentation using Docker's built-in firewall:
docker network create --driver bridge --subnet 172.20.0.0/16 --gateway 172.20.0.1 secure-net
docker run -d --name registry --network secure-net -p 5000:5000 registry:2Configure authentication for Docker registries using basic auth with strong passwords:
sudo apt-get install apache2-utils
mkdir auth
docker run --entrypoint htpasswd registry:2 -Bbn admin securepassword > auth/htpasswd
docker run -d -p 5000:5000 --restart=always --name registry
-v $(pwd)/auth:/auth
-e "REGISTRY_AUTH=htpasswd"
-e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm"
-e "REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd"
-v /mnt/registry:/var/lib/registry
registry:2Use Docker secrets for managing sensitive credentials in Swarm mode:
echo "super_secure_password" | docker secret create registry_password -
docker service create --name registry --secret registry_password
-e REGISTRY_PASSWORD_FILE=/run/secrets/registry_password
registry:2Implement rate limiting at the network level using iptables:
sudo iptables -A INPUT -p tcp --dport 2375 -m state --state NEW -m recent --set
sudo iptables -A INPUT -p tcp --dport 2375 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 -j DROPEnable Docker's built-in security scanning by integrating with Docker Scout:
docker scout analyze --target registry.example.com/app:latest
This analyzes images for vulnerabilities that could be exploited after successful authentication, closing the loop between authentication security and runtime protection.
Frequently Asked Questions
How can I tell if my Docker daemon is exposed to dictionary attacks?
ss -tlnp | grep docker or netstat -tlnp | grep docker. If you see entries like 0.0.0.0:2375 or *:2375, your Docker API is exposed. Also verify that your /etc/docker/daemon.json doesn't contain "hosts": ["tcp://0.0.0.0:2375"]. Use middleBrick to scan your exposed endpoints and identify unauthenticated access points that could be targeted by dictionary attacks.