Since 2013, Docker has been a game changer in different IT industries in several ways, it gave both developers and users a lot of flexibility for developping and using many apps and operating systems.

Firstly, Docker containers provide isolation and portability for software applications. By encapsulating an application and its dependencies within a container, developers can ensure consistent behavior across different environments. This eliminates the notorious “works on my machine” problem and streamlines the deployment process.

Secondly, Docker enables the deployment of containers in clusters, managed by frameworks like Google’s Kubernetes. This approach allows for the separation of application code and infrastructure, facilitating highly resilient and elastic architectures. Container clustering is particularly beneficial for microservices-based applications, as it promotes scalability and fault tolerance.

Lastly, Docker containers offer a higher layer of abstraction for application deployment. They simplify the process of configuring, saving, and sharing server environments. With Docker, installing an application or large software can be as easy as running a few commands. This ease of use enhances productivity and accelerates development cycles.

While Docker has gained significant popularity in recent years, it does introduce some complexity to the development process, but also some weakness if you enable the remote access and use it with default settings. An attacker can then be root in a second, as we’ll see below.

Remote access for Docker daemon

If you want to work remotely on a container, it’s possible to configure Docker to accept requests from a remote host as explained on this page from the Docker documention. Even if the documentation explains how to protect Docker by creating a non-root user or protecting the daemon socket for example, a lot of remotely accessible containers are used with the default configuration, accessible on port 2375, but also on port 2376 for TLS using a root account.

Find these containers on Shodan

By searching for product:docker port:2375 on Shodan, we can see that many servers hosting containers with the port 2375 open.

Because Shodan’s free accounts provide limited results (2 pages), you can increase the number of available results by filtering and specifying alternatively different countries by adding country=XX where XX represents the country code: “country=US” for USA, “country=UK” for United Kingdom, “country=CN” for China, etc… Complete list on iso.org.

Analyse the server before attacking (Optional)

When you use Docker remotely, you can use the usual options listed on this page. The difference is you need to spocify the host with the “-H” parameter. We will check first the Docker version installed by using the “--version” option on the first server listed on Shodan in the previous section. Then, we can list all images installed and available with the images parameter.

Launch the attack

For listing every process actually running, you will use the “ps” parameter. You can see the operating system running on the container, its uptime, size, and espacially its image ID which we will use.

Let’s try the first one, running Ubuntu. After docker -H IP_ADDRESS, we can select a container with the “exec” parameter, then add the “-it” options for an interactive shell (“i” for interactive and “t” for tty), and the image ID. Finally, we can write what do we want to use on this container, here “/bin/bash”.

After a few seconds, we are root. No credentials, no confirmation, nothing. Just :

“Hello that’s me!
-OK, please come and do whatever you want”.

Now, maybe you’ll need more tools. To install them, you’ll probably need wget, curl or git. On this container, curl is not available, you can install it with: apt install curl -y

Same for wget: apt install wget -y

The git command is already available, on this container. If not available you can install it with: apt install git -y

You can now imagine what a malicious attacker can do with all of these, like launching a DDoS attack executed from this container, scanning anonymously any sensitive server and coming back later to download results, creating a phishing attack or clickjacking webpage, etc…

If your Docker containers are remotely accessible, please check the security section in the official documentation and make it secure: https://docs.docker.com/engine/security/

This post was initially posted on my previous blog hosted on Github: Docker hacking | cryptrz