Attack Surface Management – Risks of an Exposed Docker Image
Almost ten years ago, the software would have to be typically deployed on “bare metal” or “virtual machines”. This made the entire process of installing, configuring, and relocating software burdensome. This also hampered the IT industry’s ability to respond swiftly to business changes. There was a requirement for something that would expedite the entire process of packing and deploying applications, environments, etc.
Then came into the picture, DotCloud, what today we know as “Docker“, used to be a platform-as-a-service(PaaS). Earlier, from what started as a solution to solve customer issues of DotCloud Inc. to today being widely adopted amongst the IT industry, Docker has come a long way. Container utilisation is increasing as cloud-native development methodologies become the standard model for developing and executing applications.
Here’s a video of Docker being demoed for the first time in Pycon 2013 [Youtube]
What is Docker?
Docker is an open-source platform for automating the deployment of applications as portable, self-sufficient containers that can run on the cloud or on-premises.
Docker Hub – the container image registry from Docker Inc. is a common repository (both public & private) where a person can find all the docker images published by various organisations or people around the world. Docker Hub allows free public repositories for images.
Docker and its components
Image Source: https://docs.docker.com/get-started/overview/
1) Docker Hub: Docker Hub is a repository where container images can be stored, shared, and managed.
2) Docker Run: The docker run command creates a container from a given image and starts the container using a given command.
3) Docker Image: It is a template that contains the application and all the dependencies required to run that application on Docker.
4) Docker File: It is a text file that contains all the sets of commands required to run a particular image.
Docker is widely used in the IT industry because of its multiple benefits. Along with its benefits, it carries certain risks if security measures are not followed. Because of its widespread implementation, the organisations associated with these risks are also more. This proves to be beneficial for a person with malicious intent.
By default, every image pushed to the Docker Hub through your free account appears in the public registry by default. This business strategy of Docker Inc. to engage more people into purchasing their paid subscriptions puts the free users at risk. Once an attacker finds exposed docker images related to your organisation, there is plenty of information which can be used by the attacker to cause damage to the organisation’s security posture.
1) HardCoded Secrets:
The hard-coded secrets can be in the form of credentials, access tokens, SSH keys, TLS certificates, or any form of data that cannot be stored in the docker in unencrypted form. These sensitive secrets might be present in the Environment variable(ENV), build arguments(ARG), run commands or even hardcoded in the source code of the images.
Build arguments:
A mistake where a person can unintentionally pass sensitive data to the docker image is through build arguments. If the docker image is a single-stage image, and secrets were passed as build arguments(–build-args), the attacker can retrieve them. Using the “docker history” command, we can retrieve the sensitive values.
docker history --no-trunc <image>Environment variables:
Not being just concise to secrets, but other valuable metadata information can be grabbed using the environment variables. These variables can reveal various information such as internal endpoints, runtime environment type(staging/prod), which subdomain/domain this app will serve etc. To view the environment variables of a docker image:
docker run <image_to_inspect> printenvSource code:
The worst thing is to hard-code secrets like API tokens, access keys, credentials, and connection strings in your application’s source code. When you move the application to the docker, these hard-coded secrets also get transferred in the image and can be viewed by the attacker.
2) Sensitive configuration files copied to the docker image
Another method by which sensitive data gets included in the docker image is by copying the config, which includes all the secrets. A particular docker image contains multiple layers of images. Suppose a sensitive configuration file was added in the first layer but later deleted; this doesn’t mean that the contents of the config file aren’t present anymore.
In order to speed up builds, Docker implements caching. If your Dockerfile and related files haven’t changed, a rebuild can reuse some of the existing layers in your local image cache. This means that once the attackers have access to the image, they can retrieve the sensitive secrets.
3) Exposed Git logs/hidden directories/other Dot files
When wildly copying files to the docker image, we can accidentally include the hidden “.git” directory. Once an attacker gets access to the image, they can find emails of all committers, the source of the repository, code changes, and hardcoded secrets. This kind of information not just includes .git files but also includes other important dotfiles like .ssh, .configs, etc.
4) Paid software licenses
At times, organisations accidentally publish docker images with activated software. Yes, this is a sensitive issue, but it can also land the organisation in hot water. As distributing licensed software might also lead to legal charges against the organisation.
5) Risks of a Targetted Cyber Attack
Since the docker image is publicly available, the attacker can further pull the image and analyse all the stacked images and technologies as well as their configurations to determine whether it contains any known vulnerabilities. After analysing the docker image, the attacker may find a misconfiguration or a vulnerability present in the image or in a software component being used in the image. There may also be, information regarding where the particular image is deployed on the internet.
This puts the organisation at risk of a cyber attack since the attacker knows what vulnerability exists and where the docker is deployed.
How to stop exposures in docker images:
Below are certain recommendations to prevent your organisation from the risks associated with the exposed docker image.
– Continuously monitor your exposed docker images: A well-informed team should continuously monitor and observe the exposed docker images related to their organisation. This list of exposed images should be added to the organization’s asset inventory.
– Do not hardcode secrets: Tokens, API keys, passwords, database connection strings, and SSH keys should not be hard coded in docker images.
– Make use of private container registries: To share docker images, make use of private container registries like Azure Container Registry, Amazon Elastic Container Registry, and Github Docker registry.
– Implement the usage of “.dockerignore”: All the sensitive directories that we don’t want to include while building a docker can be added to this “.dockerignore” file.
– Conduct training sessions: Provide training to developers about what are the security best practices for docker.
– Use secrets management tool: Docker secrets are a secure-by-default way to deliver sensitive values across a cluster of Docker hosts.
– Regular updates and patches: Newer updates and bug fixes are often included in update packages.
– Using a paid subscription: Using a paid subscription allows you to push your Docker images to a private repository. Using a private repository straightway cuts off most of the risks.
Our Internet-wide study
We at RedHunt Labs are a very research-oriented organization, where we conduct various internet-wide scans under the name of Project Resonance to study the security posture of the internet.
A few months ago, we conducted an internet-wide study where we scanned millions of publicly exposed Docker containers to assimilate the exposure of secrets. And here’s what we found after scanning 1,684,600 unique Docker Hub accounts.
We observed that 46,076 docker images either hardcoding credentials or copying sensitive config files to docker images.
We at RedHunt Labs help organisations continuously discover their Attack Surface across subdomains, containers, git repos, etc., and help identify security risks on External Attack Surface before attackers do.
Our Agentless Attack Surface Management Platform NVADR has capabilities to continuously monitor your exposed Docker Assets from across the internet and has been able to identify critical data leaks across publicly exposed docker containers for many of our customers.
If you would like to check out your organisation’s Attack Surface, we also offer a Free Scan. Request Free Scan here.
