Exposed Docker Daemon

What Is Exposed Docker Daemon?

The Docker API is root-equivalent and has no authentication of its own. A daemon bound to a plain TCP port lets anyone who can reach it start containers, mount the host filesystem, and read the machine. No vulnerability is involved. You'll probe port 2375 unauthenticated from outside, list production containers, and bind-mount the host root to read its environment file. Then you'll remove the tcp://0.0.0.0:2375 bind, require TLS client certificates, and see the same probe refused. The exercise also covers mounting /var/run/docker.sock into a container.

What You'll Learn in Exposed Docker Daemon

• Recognize that the Docker API is root-equivalent and carries no authentication of its own
• Identify a daemon bound to tcp://0.0.0.0:2375 as remote unauthenticated root, needing no vulnerability and no prior foothold
• Trace how an attacker bind-mounts the host root into a container and reads the production environment file through it
• Configure the daemon to drop the plain TCP bind and require mutual TLS client certificates, then confirm the same probe is refused
• Explain why mounting /var/run/docker.sock into a container gives that container the same root-equivalent API

Exposed Docker Daemon — Training Steps

1. Reading the public status page

   Bob is not inside anything. He is on his own laptop, reading Palliston's public operations page. It is meant to reassure customers that the platform is healthy, and in doing so it names the production nodes, their public IPs, and the Docker engine each one runs. Take a look at what it exposes before Bob puts it to use.

2. The line that says too much

   It only takes one line. A production node's public IP and the fact that it runs Docker are all Bob needs to try the cheapest attack there is.

3. Knock on the daemon

   The Docker daemon can be told to listen on a network port instead of only the local socket. When it is, and TLS is off, it answers anyone. Bob points his own Docker CLI at that node's port 2375 and asks it the most harmless question there is: what version are you. If it answers, the game is already over.

4. Read the production fleet

   The Docker API is not a narrow thing. It lists, starts, stops, and builds containers, and it does all of it as root. Bob's first move with it is simply to look: what is this host actually running.

5. Mount the host, take the secrets

   Bob does not need to break into the running containers. The daemon will start a brand new one for him, and it will mount whatever he asks it to. He asks for the host's entire root filesystem at /host, then reads the production environment file straight through the mount. The container is his. The host is under it. There was never a wall between them.

6. What made this possible

   One beat on the mechanism before the response begins.

7. The daemon logs a stranger

   Palliston ships its Docker daemon logs to a central collector. It does not take an intrusion-detection product to notice what turned up: API calls to the daemon on ops-node-01, from an IP that belongs to no one at Palliston.

8. Confirm the door is open

   Before changing anything, Alice reproduces what the logs describe. If an unauthenticated version probe from her own machine answers, the daemon is exposed exactly as Priya feared.

9. Open the daemon config

   The daemon's behaviour is set in one file, /etc/docker/daemon.json. Whatever told it to listen on the network without TLS is a line in here.

10. Find what opened the port

    Two settings, side by side, are the entire exposure. One puts the API on the network; the other tells it not to check who is calling.