Hunting Secrets from Containers by Analysing Docker Images
Docker images are used to create containers and contain some secrets that can be extremely useful when exploiting applications. In this post, you will learn how to search for such information in Docker images or Dockerfiles in order to gain unauthorised access.
Hello World! As you know containers are created from images. These images can be easily found on the Docker registry. Most of the time the developer or the DevOps teams include secrets in the local file while the development or deployment process and forget to ignore the file. This misconfiguration can be pulled from the registry and can be used to retrieve secret files.
Although we would call it a stupidity to store a classified information on the webserver. Isn't it?
Today you will see three different scenarios where such misconfigurations will go wrong.
- Examining Docker Image to Find Hidden Directories (Link to Lab)
- Getting SSH Keys from the Docker Image (Link to Lab)
- Hunting for Credentials in the Dockerfile from Public Repository (Link to Lab)
For your practice, I have left a lab. Check out at AttackDefense – Embedded Credentials
Examining Docker Image to Find Hidden Directories
There is a flag file hidden in the serving directory of the web app that is difficult to brute force (you will see why). The job is to find the path of the flag and open it in the browser.
As usual, let's start off by enumerating open ports on the target's ip address using Nmap nmap -sV IP --min-rate 2000
.
You will find out that the Bludit service is running on the system but there is no way it can be exploited so that you can use the reverse shell and as the description of the lab says, it is also difficult to brute force the directory.
The registry would be in the same network only, you can find the nmap to scan live hosts on the network by providing the CIDR range as shown below.
The Docker registry is served on port 5000 of 192.73.244.4 host, and now you can get the list of all the images using the curl command as the docker service is not working on the attacker system and anywhere on the network.
There is only one image in the registry and also it has only one tag latest. Download the code from Exploiting Insecure Docker Registry and create the bash script on the remote server.
Execute it with the registry host and the image name. This will download all the layers for you and dump them in the webserver
folder in the same order you would get by calling /v2/webserver/manifests/latest
endpoint.
The flag file would be of the name "flag.txt" or "*flag*" pattern. Search it in the directory using the find command.
Usually the webservers, /var/www/html
is configured as the root directory for serving content. Therefore it means that the flag file can be retrieved from the /bf294d06b99e/flag.txt
endpoint on the target server.
Getting SSH Keys from the Docker Image
In this lab, the target server is running an SSH server on the default port and only a private key is allowed for accessing the server. The flag file is stored in the target server home directory (/root).
Find the docker registry as we did in the previous lab above and find out the image name and tag name for the script used earlier. After downloading the file system from the remote, you will find the private with the name private_key.pem
in the 6th layer.
Just fyi, the image name is ssh-server
and there is only one tag (latest)
Use the private key to login into the server and retrieve the flag from the home directory of the root user.
Hunting for Credentials in the Dockerfile from Public Repository
This lab is different from what you have seen earlier in this post. Here you are given the webserver running on the target and the Gitlab username of the administrator account hosting the repository of the app. You are supposed to find the flag from the server and it is protected by HTTP Basic Auth.
Allow me to share a very interesting incident with you, that will tell you how the shits go real in the infosec community.
ENV
instructions. I found that they are from the root user of the client's account and I could do RW operations on their entire infrastructure. As you can confirm the server does not allow you to get the contents of the index.php execution and with the error message it is confirmed that Apache webserver is being used.
You can find in the description of the challenge that the root user of Gitlab is served and that contains a public repository web-server-container which contains docker file and can leak information.
Spoiler Alert! There is no such juicy information the Dockerfile but you will find htaccess
and htpasswd
file in /files/app
directory and that contains the login credentials for the HTTP Basic Auth.
If you would dig deeper and look the configuration in the htaccess file, you will see that only GET request is protected with the valid-user guard. This means you can use other request methods.
GET and POST are the two methods that I know is supported by the Apache server. You cannot set the POST request directly with the browser, but with curl using -XPOST
, use the same URL and get the flag.
Can you as a developer or the devops engineer save this? Of course, you can! Docker allows you to add build-time or runtime secrets that are encrypted and can not be retrieved easily. Checkout docker secret
command with swarm or kubernetes architecture.