K8s Runtime Attack Scenarios-2
In this article, I will show you to read the sensitive files in the container running in the K8s environment, both by using the application that has the vulnerability and by connecting pod with kubectl.
Introduction
Purpose of attack
In this attack scenario, I will use the Docker image of the .NET Core API application that I have developed before and which has many web vulnerabilities. By using the 2 different vulnerabilities on this application and connecting with pod with kubectl exec command, we will read the sensitive files of the container.
Goal
The goal here should be to generate an alarm and capture this situation when the sensitive files owned by the container are read by the attackers.
Lab Setup
Warning 1
Since I am running the K8s Cluster through Apple Silicon, I changed the container image tag below to “arm64”, but if you are working on a processor using “amd64” architecture, you do not need to make any changes.
“amd64” and “arm64” versions are available on Dockerhub.
Setup
If everything is fine, it will be sufficient to use the file named “environment.yml” in the address I shared below for installation. You can read the file named “README.md” to get information about the content of the relevant file.
To install the environment, it will be enough to run the following command.
kubectl apply -f https://raw.githubusercontent.com/Erdemstar/K8s-Runtime-Attack-Scenario/main/Scenario-2/environment.yml
After the command is run, the output should consist of the following.
Objects under the namespace named “Vulnerable” should display the result below.
Warning 2
In order to create the Kubernetes Cluster environment quickly, I used the tool called Minikube and preferred Docker as the driver. While this preference has the advantage of making the installations fast, it also has the problem of accessing the services created in NodePort type :) If you have made such a choice, it may be useful to follow the steps below to solve this problem.
minikube service --namespace=vulnerable vulnerable-service
After running the above command it should be like bellow image. Here, it is possible to access the vulnerable-service from 2 different IPs. The first Minikube Controlplane Node IP 192.168.49.2 can be used. On the other hand, you can use the port forwarding feature with your Minikube machine and send localhost traffic 192.168.49.2:30080. (The bind port on the localhost side may vary.).
Since there is an access problem caused by the Docker environment, I will access it over localhost. The address I will go to is as follows.
http://127.0.0.1:58027/swagger/index.html
The screen you should see before trying the attack scenario is as follows.
Attack
Preparation
In order to show Request / Response in detail, I will create a sample Remote Code Execution and File Inclusion request via Swagger, send it to Burp Repeater and perform my controls over Burp.
After verifying the existence of the relevant vulnerabilities at this stage, let’s try to read the files that may be sensitive in the container using the vulnerabilities.
While I was writing this article, since I knew the path of the files with sensitive data, I went directly without any exploration, but you can check it in different places using the paths shared in the LFI Wordlist link.
Attack 1
Sensitive files can be read from the container using the Remote Code Execution vulnerability as follows. To be different here, I did the file operation using the “cat” and “head” commands.
Attack 2
Sensitive files can be read from the container using the Local File Inclusion vulnerability as follows.
Since the technology of the application here is .NET Core, it may be useful to read /app/appsettings.json, /app/appsettings.Development.json and /app/web.config. An example request is as follows.
NOTE : Using the Remote Code Execution vulnerability, every possible operation can be done within the container, but Local File Inclusion has a narrower scope. It should not be forgotten that the code of the application can also be read, apart from sensitive files, by exploiting the Local File Inclusion vulnerability.
Here, a request like the one below can be made and the resulting content can be written as a dll file and decompiled in the final case, making the codes readable.
Attack 3
The files read above can also be read by connecting with kubectl exec. Here, I will read the files that are mounted in order for a contanier working in the K8s environment to communicate with the K8s API-Server.
First of all, I list the objects under the “vulnerable” namespace.
Then I get shell access from the relevant pod by running a command like the one below.
kubectl exec -it -n vulnerable pod/vulnerable-deployment-6f866d8df6-nw5pt bash
Then, when I go to the directory below and make a list, I get an output as in the photo.
cd /var/run/secrets/kubernetes.io/serviceaccount/
At this stage, information to communicate with API-Server can be obtained by reading the following files.
Click here to see my other articles about web vulnerabilities. Link