Linux Attack & Defense: Matrix Breakout Edition

As a penetration tester, I enjoy playing the Capture the Flag (CTF) challenges you'll find on VulnHub.com or at an information security conference. As a teacher, I enjoy showing people how to block the attack through proactive systems hardening.

In the most recent webinar episode of my Attacking and Defending Linux series, we go through a three-stage attack, breaking into the new “Matrix: Breakout” Boot2Root CTF virtual machine, which you can download from here, collecting flags as we go. After that, we demonstrate one proactive defense that would break the attack.

In this webinar, as in most real breaches or penetration tests, we have to exploit multiple vulnerabilities in a sequential chain to reach our goal. Some vulnerabilities are the kinds of software flaws that get CVE numbers like CVE-2017-5638 (and often slick names like “Strutshock”). The first vulnerability in the webinar is one of those. But many of the vulnerabilities that we exploit as attackers are weak designs or configurations. The last vulnerability in the webinar’s chain fits this description: the program we exploit runs in a “privileged” container.

Security Considerations for Privileged Containers in Docker

Link copied

The Docker project created “privileged” containers to support running Docker from within Docker. Privileged containers remove two of the major protections that prevent a root user in a container from breaking out of the container: limits on root capabilities and restrictions on devices visible to the container. Let’s discuss the latter.

Consider the difference between an unprivileged and a privileged container’s /dev directories. Here’s a standard container’s /dev directory:

Here’s a privileged container’s /dev directory:

The privileged container has access to the Linux machine’s entire /dev directory. In the webinar, when we find ourselves with root privilege in the container, we mount the host virtual machine’s hard disk device (/dev/vda1) and use it to access a flag file that’s on the host filesystem, normally accessible only from outside of the container. While we don’t demonstrate this, you can generally turn this into full code execution on the host. For example, you could write to a crontab file or change a password.

What about defense? Well, while privileged containers are useful in Docker development, or in special cases, there are very few situations where a container needs to run with this level of privilege. In general, it’s important to make sure that there are strong controls against running privileged containers on your machines. If you’re running Docker Engine hosts without an orchestrator, consider using a Docker authorization plugin like Open Policy Agent’s opa-docker-authz. If you’re running containers with Kubernetes, check out the available admission controllers for your version.

Watch the Webinar and Play Along!

Link copied

To see the full attack path and another defense, watch my webinar: Attacking and Defending Linux: Breaking out of the Matrix Edition. You can even download the virtual machine from here and play along. Note, that to play along in the same environment that I demo in webinar, you'll want a copy of Kali Linux.