Man In The Middle on Docker

Man In The Middle (MITM) attacks in Docker environments exploit the container networking model and configuration weaknesses. Unlike traditional MITM scenarios, Docker-specific attacks target the unique networking architecture where containers share host resources and often communicate over internal networks without proper encryption.

The most common Docker MITM vector occurs through insecure Docker daemon communication. By default, Docker listens on a Unix socket, but when exposed over TCP (often for remote management), it becomes vulnerable. An attacker on the same network can intercept and modify commands sent to the Docker daemon, potentially deploying malicious containers or extracting sensitive data.

# Vulnerable Docker daemon exposure
docker -H tcp://0.0.0.0:2375 ps

Another critical attack surface is Docker registry communication. When pulling images from registries over HTTP or untrusted networks, attackers can intercept and replace legitimate images with malicious ones containing backdoors or cryptocurrency miners. This is particularly dangerous in CI/CD pipelines where automated builds pull images without verification.

# Vulnerable image pull without verification
docker pull registry.example.com/myapp:latest

Container-to-container communication within Docker networks often lacks encryption, enabling attackers to intercept sensitive data like API keys, database credentials, or personal information. Even when using Docker's built-in networking, traffic between containers on the same host travels unencrypted unless explicitly protected.

Docker Compose files frequently expose MITM vulnerabilities through misconfigured environment variables and network settings. Developers sometimes hardcode credentials or use default network configurations that allow unrestricted inter-container communication.

# Vulnerable Docker Compose configuration
version: '3'
services:
  web:
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/dbname
    networks:
      - default
  db:
    environment:
      - POSTGRES_PASSWORD=weakpassword
    networks:
      - default

Build-time MITM attacks target the Docker build process itself. Attackers can intercept RUN commands in Dockerfiles to inject malicious code, replace package downloads with compromised versions, or extract build secrets from intermediate layers.

# Vulnerable Dockerfile with potential MITM
FROM node:18
RUN npm install -g some-package # Could be intercepted

Detecting MITM vulnerabilities in Docker requires examining both configuration and runtime behavior. The first step is scanning Docker daemon settings to ensure it's not exposed over unsecured TCP connections.

# Check Docker daemon configuration
ps aux | grep dockerd
# Look for -H tcp://0.0.0.0:2375 (unsecured) vs -H unix:///var/run/docker.sock

Network inspection tools can reveal unencrypted container traffic. Using tcpdump or similar tools on the Docker host shows whether sensitive data flows in plaintext between containers.

# Monitor container network traffic
tcpdump -i docker0 -w docker_traffic.pcap
# Check for unencrypted credentials, API keys, personal data

Registry communication should be verified for HTTPS usage and proper certificate validation. Tools like docker pull with verbose output reveal whether secure connections are established.

# Test registry connection security
docker pull --disable-content-trust registry.example.com/image
# Should show TLS verification, not plain HTTP

middleBrick's Docker-specific scanning identifies MITM vulnerabilities by testing API endpoints exposed by containers for encryption weaknesses, authentication bypasses, and insecure communication channels. The scanner examines container configurations, network settings, and exposed services to detect potential interception points.

Container runtime analysis tools can detect suspicious network activity patterns that indicate active MITM attempts, such as unexpected DNS queries, unusual port bindings, or traffic redirection to unknown hosts.

# Check container network bindings
docker ps --format "table {{.Names}}\t{{.Ports}}"
# Look for unexpected port exposures or host network usage

Image integrity verification ensures downloaded images haven't been tampered with during transit. Docker Content Trust and signature verification should be enabled for production deployments.

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1
docker pull alpine:latest

Securing Docker against MITM attacks requires multiple layers of protection. The foundation is securing Docker daemon communication by binding it only to Unix sockets or using TLS encryption for remote access.

# Secure Docker daemon configuration
sudo systemctl edit docker.service
[Service]
ExecStart=...
ExecStart=... -H unix:///var/run/docker.sock
# Remove any -H tcp://0.0.0.0:2375 lines

For necessary remote Docker access, implement mutual TLS authentication with client certificates and strong encryption. Generate certificates specifically for Docker communication and rotate them regularly.

# Generate Docker daemon certificates
openssl genrsa -out ca-key.pem 4096
openssl req -x509 -new -key ca-key.pem -sha256 -days 365 -out ca.pem
# Create server and client certificates
openssl genrsa -out server-key.pem 4096
openssl req -new -key server-key.pem -out server.csr
# Sign with CA and configure Docker daemon to use them

Registry communication must use HTTPS with proper certificate validation. For private registries, use self-signed certificates with explicit trust configuration rather than disabling verification.

# Configure Docker for secure registry access
cat /etc/docker/daemon.json
{
  "insecure-registries": [],
  "registry-mirrors": ["https://secure-registry.example.com"]
}

Container network security involves isolating services using Docker networks with explicit permissions. Avoid the default bridge network and create custom networks with controlled access.

# Secure Docker Compose networking
version: '3'
services:
  web:
    networks:
      - web-network
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/dbname
  db:
    networks:
      - db-network
networks:
  web-network:
    driver: bridge
  db-network:
    driver: bridge
    internal: true # No external access

Secrets management is critical for preventing credential exposure. Use Docker secrets for Swarm mode or external secret stores rather than environment variables.

# Use Docker secrets instead of env vars
echo "mysecret" | docker secret create db_password -
docker service create --name myapp --secret db_password myapp:latest

Build-time security involves using trusted base images, verifying package integrity, and avoiding RUN commands that download unverified content. Implement image signing and verification in CI/CD pipelines.

# Secure Dockerfile practices
FROM alpine:3.17@sha256:abcd1234... # Pin exact image hash
RUN apk add --no-cache --virtual .build-deps 
    && apk verify package1 package2 # Verify packages
COPY --from=trusted-builder /app /app # Use trusted build stages

Runtime monitoring with Docker's built-in security features and third-party tools helps detect ongoing MITM attempts. Enable Docker Content Trust for all image operations and use Docker Bench Security to audit configurations.

# Enable Docker Content Trust globally
export DOCKER_CONTENT_TRUST=1
# Audit Docker security
docker run -it --net host --pid host --cap-add audit_control 
    -v /var/lib:/var/lib 
    -v /etc:/etc 
    docker/docker-bench-security