This article is a review of the presentation given by Geoffrey SAUVAGEOT-BERTLAND at Hack 2024[1], addressing potential vulnerabilities related to the use of an insecure private Docker registry.
A private Docker registry allows companies to centrally manage and store their Docker images, often for reasons of confidentiality or customization. However, the lack of adequate security, often due to default settings, can expose these registries to targeted attacks.
Why use a private Docker registry?
A private Docker registry provides complete control over the management of application images, particularly for development, testing, and production environments. Unlike the public Docker Hub registry, privately hosted images can include sensitive components or specific configurations. This also helps to meet security and data privacy compliance requirements.
However, improper configuration of these registries can expose sensitive systems to attacks. It is crucial to understand the risks and attack techniques in order to anticipate and properly secure these environments.
This article will cover two attack scenarios:
- Flying and reviewing a private Docker image.
- Modifying an image to compromise the supply chain.
Flight and image review
Identification of a vulnerable private Docker registry
The first step in carrying out an attack is to identify a vulnerable private Docker registry. A simple and effective tool for this task is Nmap, a network scanner used to discover services running on a target machine. By running a scan, it becomes possible to detect a Docker registry on a misconfigured server:
nmap -p- -sV <ip_server>
- The -p- argument allows you to scan all ports on a machine.
- The -sV option allows you to identify the versions of services running on open ports. This makes it easier to identify the Docker registry port.
Once the registry has been located, it is possible to exploit its configuration if it is accessible without authentication (anonymous access).
Image recovery
A first possible action could be to make a request to the following URL:
http://<ip_registre>:<port>/v2/_catalog
This simple check provides two crucial pieces of information:
- Anonymous access: If the server returns an HTTP 200 code, this confirms that the registry is open and accessible without authentication. The attacker can then proceed to retrieve the images.
- List of images: The response includes a list of all hosted images, providing a preview of what can be downloaded and studied.
Once this list has been obtained, the images can then be downloaded using a simple docker pull command:
docker pull <image_name>
Image review
Once the download is complete, the image can be run in a container to examine its contents. By connecting directly to its shell using the following command:
docker run -it <image_docker> sh
This provides access to all components included in the image, including the source code of the applications. This code may contain sensitive information such as:
- API keys.
- Access tokens.
- Environment variables or .env files containing usernames and passwords.
This stage of investigation can prove particularly critical, as it offers the possibility of retrieving confidential information that can then be used to attack other systems connected to the application.
Modifying an image
Amplification of the attack via the supply chain
The consequences of an image theft attack can be amplified by targeting the supply chain directly. The idea is to compromise an image and then reinsert it into the registry without anyone noticing. This can be done by adding a backdoor to the compromised image, for example.
Once modified, the image is sent back to the registry with the same tag and version as the original image. This discreetly replaces the legitimate image without triggering any immediate alerts.
The repercussions of such an attack are potentially serious:
- Any person or system downloading the corrupted image may be compromised.
- Production environments can be infected, creating vulnerabilities in critical infrastructure.
Creation of the backdoor
During the presentation, a web image was used as an example. The Weevely tool was used to generate a simple backdoor to integrate into the image:
weevely generate 123456 backdoor.php
This command generates a backdoor.php file, which can then be used to create a semi-interactive webshell. This webshell is accessible with the password 123456, providing the attacker with discreet remote access.
Adding the backdoor to the image
To integrate the backdoor into the image, a Dockerfile is required. This file contains instructions for modifying the original Docker image:
- FROM: Use the original image as a base.
- COPY: Copy the backdoor.php file to the /var/www/html directory or another suitable location.
- RUN: Install the sudo utility to enable privilege escalation via the webshell.
- RUN: Change the password for the www-data user.
- RUN: Add the www-data user to the sudo group.
Once the changes have been made, the image can be built and sent back to the registry using the following command:
docker build -t <image_tag>:<version>
docker push <image_tag>:<version>
If no version is specified, the latest tag is used by default.
Automatic deployment and monitoring
In some environments, an automated deployment application, such as watchtower, can be used to monitor and automatically deploy new versions of images. This presents an additional risk, as compromised images can be deployed without prior manual verification, thereby amplifying the scope of the attack.
In such a case, the modified image will be immediately put into production after its deployment to the registry.
Operation
Once the modified image has been deployed on a target machine, it is possible to exploit the backdoor by accessing the webshell via the following command:
weevely http://<ip_server>/backdoor.php 123456
Adding the www-data user to the sudo group allows privilege escalation, providing complete control of the container to perform other malicious actions.
Possible remedies
To prevent such attacks, the following security measures can be implemented, for example:
Using image policies
It is essential to implement strict admission policies for Docker images in Kubernetes environments. Tools such as Kyverno or OPA (Open Policy Agent) can be used to define rules that prevent the deployment of images that do not comply with security standards. In addition, vulnerability scanners such as Trivy or Anchore can be used to analyze images before deployment to ensure that they do not contain any known vulnerabilities that could compromise systems.
Using minimal Docker images
To reduce the attack surface, it is recommended to favor minimal Docker images. Using lightweight images, such as Alpine, limits unnecessary components and, consequently, vulnerabilities. It is also important to remove all non-essential packages and components from images to reduce the number of vulnerable dependencies. The less unnecessary software an image contains, the less of a security risk it poses.
Securing TLS certificates
Protecting communications with the Docker registry is crucial. Implementing a policy of regularly rotating certificates and signing keys reduces the period during which a compromised certificate or key could be exploited. Using a certificate manager such as Let's Encrypt can facilitate the automation of TLS certificate management and renewal, thereby strengthening infrastructure security.
Network segmentation
Effective network segmentation is essential to limit exposure of Docker registries. It is recommended to configure firewalls and access control lists (ACLs) to filter and limit access to registries. In addition, separating development, production, and Docker registry management networks helps reduce lateral movement in the event of a compromise, while protecting critical environments.
Signing Docker images
To ensure the integrity of Docker images, it is advisable to implement a digital signature process. Signing images ensures that they have not been modified or corrupted prior to deployment. Tools such as Docker Content Trust (DCT) or Notary are suitable for signing and verifying Docker images. In addition, it is important to configure CI/CD pipelines to accept only signed images, ensuring that only secure and validated images are used in production environments.
Conclusion
In conclusion, this presentation by Geoffrey SAUVAGEOT-BERTLAND at Hack 2024 showed me how poorly secured Docker registries can be a gateway for attacks. However, it also showed me that by taking proactive measures to secure the infrastructure and adopting robust security practices, we can significantly reduce the risks associated with using private Docker registries.
[1] You can watch a replay of the conference at: https://youtu.be/f8t-z0M9C-k?si=UN4_nK12ZQ0JDIoD
