Welcome to a new installment of Unauthenticated! One of my goals with this series is to drive home the point that authentication (with properly implemented access controls) is essential to the security of your entire environment.
In this post, we will look at a recent internal penetration test where a Docker service was identified in the environment that did not require authentication to interact with, resulting in remote execution as root on one of the Docker containers running Linux.
Docker is a technology that allows for fast and easy creation of virtualized operating systems (called containers) with customized configurations and software installations. Docker containers are lightweight and take up few system resources, allowing for a system to run many containers at once.
Two important Docker concepts to note are images and containers. An image can be thought of as the template used to build the operating system, install software, and apply configurations. A container is a running instance of an image, representing the virtualized operating system environment that a user interacts with.
Check out the excellent series Dockerizing A Web Testing Environment by Wes, my coworker, for a practical overview of Docker.
On this internal penetration test, Nessus helpfully identified a system running Docker that did not require authentication to interact with over the network.
Findings like this are generally easy wins for an attacker, as they likely provide interactive access to operating systems with high privileges.
With the information from Nessus, I connected to the Docker on the system and requested a list of images, identifying an image labeled “tomcat”:
The “tomcat” image was not running as a container, so I used the docker run command to start container:
Then…
With the container now running, the docker exec command was used to directly interface with the operating system of the container. A root shell was provided due to the use of the –privileged flag when running the container:
Exploitation of this system did not lead to exposure of credentials or sensitive data during the assessment. However, I did have full control over the docker container which is essentially the same thing as having full control over a system in the client’s environment. This system could be leveraged by an attacker as a jump point to conduct malicious activities from.
Authentication issues may affect more than the single system or application they apply to, as authentication issues can be leveraged by a threat actor as a staging platform to conduct further attacks within the environment.
Organizations that use Docker in their environment should always require authentication. As shown in this post, anyone with access to the network can easily gain full control over a Docker container if authentication is not required.
Check out this link for information on how to implement authentication in Docker.
Additionally, consider performing regular audits of your environment to identify Docker instances that may pop up over time. This can be performed either through your internal Quality Assurance processes or third-party penetration testing services such as those offered by White Oak Security.