Docker is one of the most widely used container-based technologies. It is a tool which helps to create, deploy, and run applications by using containers.
Containers make it easy for the developers to build the application with all its dependencies and libraries and ship it out as one package. But with new technologies come new vulnerabilities.
We’ll be looking into a few attacks that can be performed to exploit docker vulnerabilities.
In the docker setup, a user with low privilege (non-root user) is added to the docker group to perform docker related tasks without giving the user root or sudo privileges. A low privilege user (non-root user) in a Linux machine with Docker group assigned, can escalate the privilege to a root user and perform an administrative task in the host machine.
It is recommended to run the docker daemon in rootless mode. Rootless mode executes the Docker daemon and containers inside a user namespace. A feature of Linux that can be used to separate the user IDs and group IDs between the host and containers is called User Namespaces.
User Namespaces can provide better isolation and security: the privileged user root in the container can be mapped to a non-privileged user on the host. A rootless mode is a mode where both the daemon and the container are running without root privileges.
When the images are deleted from the host machine, this action will not lead to the deletion of the mounted volume automatically.
If an attacker has gained access to the host machine during the exploitation phase, he/she can look for dangling volumes on the docker host as part of post-exploitation phase and examine for sensitive information in the volume, which can further be used to attack the infrastructure or the application in the environment.
For example, consider a scenario where a developer has mounted a volume on the host and has written a sensitive file which contains database password/username. The volume created is then shared with a container.
Now when the developer tries to stop and remove the container, although the container is deleted, the volume is still dangling around and we can access the data in it. An attacker having access to a docker host can access this sensitive data.
It is always advised to remove the container with -v flag. If the -v flag is not being used when removing the container, the volume will always end up dangling and remain in the local disk.
Another method to go about this is to use a command docker image prune. This allows us to clean up all unused images.
Creating Private Registry is useful in a scenario where an organization needs to organize all the custom images privately and does not want to publish it to the public docker registry.
An attacker can access insecure private registry remotely using the docker registry HTTP API to enumerate the list of repositories in the private registry.
An attacker can also use this attack vector to download the images in the private registry to localhost via remote API using the blobSum information to check the underlying code for any sensitive information.
The retrieved information can be used for a further attack in the network or application.
Implement Authentication based mechanism to access the private registry (Token-based, bearer, OAuth, etc.).
Implement Content Trust to impose client-side signing and validation of image tags.
Developers use environment variables as a storage place to hardcode all the sensitive information like username, passwords, API keys, etc in the docker container.
This information can then be used by their application running in the container to retrieve the sensitive information from the environment variables to make database queries or API calls. This can impose a great impact on the docker container security.
An attacker having the ability to run operating system commands via web application execution vulnerability can easily view the sensitive information set in the environment variable.
It is recommended to secure the web application and perform proper input validation to stop an attacker from executing system commands.
It is recommended not to store sensitive information like passwords, keys, auth-tokens in the environment variables.
Docker daemon API is set up and configured to allow users to remotely access and administrate the docker related tasks via API. The use of API also helps in building automation scripts for the remote docker deployment without having to log in to the host system where the docker is installed to run the docker tasks.
As there is no authentication implemented by default on Docker daemon API, an attacker can invoke the API remotely and perform an administrative task. An attacker can perform both enumeration and exploitation techniques using a python custom script.
This custom script can be used to compromise a remote host and get a foothold on the host machine where docker daemon is running with root privilege.
It is recommended to implement an authentication mechanism to the Docker daemon API and also implement TLS to the API call.
In an organization, when the development team will need to access the host resources from the container environment, it can be achieved using the “–privileged flag” while running the container.
As the privileged flag is used to access the PID of the host from the container, an attacker having an initial foothold on the container can escape from the container environment and access the host machine with root privilege. This is achieved by injecting a reverse shell payload to the root process of the host machine.
It is recommended to implement container hardening techniques in order to limit the activity of the attacker after getting an initial foothold on to the system.
Hardening techniques can be implemented to increase the docker container security.
For example, the ability to download third party files using wget must be disabled. This is one of the ways to implement docker container security. This can also be achieved using any of the following features:
Containers help developers to create more secure environments because it isolates software. However, using containers also increases the attack surface and risks because containerization of software also adds extra layers of abstraction and complexity which can increase docker vulnerabilities in the container environment.
This poses challenges for both attackers and defenders of docker systems. This can be tackled in the right way by adding an additional level of docker container security like AppArmor, SECcomp and other suitable hardening techniques.