Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
In Kubernetes, it is observed that a default behavior permits the establishment of connections between all containers residing on the same node. This applies irrespective of the namespace distinctions. Such connectivity extends down to Layer 2 (Ethernet). Consequently, this configuration potentially exposes the system to vulnerabilities. Specifically, it opens up the possibility for a malicious container to execute an ARP spoofing attack against other containers situated on the same node. During such an attack, the malicious container can deceitfully intercept or modify the network traffic intended for other containers.
ARP spoofing attacks involve the attacker sending falsified ARP (Address Resolution Protocol) messages over a local area network. This results in the linking of the attacker's MAC address with the IP address of a legitimate computer or server on the network. Post successful execution of such an attack, the attacker can intercept, modify, or even stop data in-transit. The attack is executed on Layer 2 of the OSI model, which is why the default connectivity in Kubernetes at this layer raises security concerns.
In the scenario 4 machines are going to be created:
ubuntu-pe: Privileged machine to escape to the node and check metrics (not needed for the attack)
ubuntu-attack: Malicious container in default namespace
ubuntu-victim: Victim machine in kube-system namespace
mysql: Victim machine in default namespace
If you want more details about the networking topics introduced here, go to the references.
Generally speaking, pod-to-pod networking inside the node is available via a bridge that connects all pods. This bridge is called “cbr0”. (Some network plugins will install their own bridge.) The cbr0 can also handle ARP (Address Resolution Protocol) resolution. When an incoming packet arrives at cbr0, it can resolve the destination MAC address using ARP.
This fact implies that, by default, every pod running in the same node is going to be able to communicate with any other pod in the same node (independently of the namespace) at ethernet level (layer 2).
Therefore, it's possible to perform ARP Spoofing attacks between pods in the same node.
In kubernetes environments you will usually find 1 (or more) DNS services running usually in the kube-system namespace:
In the previous info you can see something interesting, the IP of the service is 10.96.0.10 but the IP of the pod running the service is 172.17.0.2.
If you check the DNS address inside any pod you will find something like this:
However, the pod doesn't know how to get to that address because the pod range in this case is 172.17.0.10/26.
Therefore, the pod will send the DNS requests to the address 10.96.0.10 which will be translated by the cbr0 to 172.17.0.2.
This means that a DNS request of a pod is always going to go the bridge to translate the service IP to the endpoint IP, even if the DNS server is in the same subnetwork as the pod.
Knowing this, and knowing ARP attacks are possible, a pod in a node is going to be able to intercept the traffic between each pod in the subnetwork and the bridge and modify the DNS responses from the DNS server (DNS Spoofing).
Moreover, if the DNS server is in the same node as the attacker, the attacker can intercept all the DNS request of any pod in the cluster (between the DNS server and the bridge) and modify the responses.
Our goal is to steal at least the communication from the ubuntu-victim to the mysql.
As it was already mentioned, if you compromise a pod in the same node of the DNS server pod, you can MitM with ARPSpoofing the bridge and the DNS pod and modify all the DNS responses.
You have a really nice tool and tutorial to test this in https://github.com/danielsagi/kube-dnsspoof/
In our scenario, download the tool in the attacker pod and create a **file named hosts ** with the domains you want to spoof like:
Perform the attack to the ubuntu-victim machine:
If you try to create your own DNS spoofing script, if you just modify the the DNS response that is not going to work, because the response is going to have a src IP the IP address of the malicious pod and won't be accepted. You need to generate a new DNS packet with the src IP of the DNS where the victim send the DNS request (which is something like 172.16.0.2, not 10.96.0.10, thats the K8s DNS service IP and not the DNS server ip, more about this in the introduction).
The tool Mizu is a simple-yet-powerful API traffic viewer for Kubernetes enabling you to view all API communication between microservices to help your debug and troubleshoot regressions. It will install agents in the selected pods and gather their traffic information and show you in a web server. However, you will need high K8s permissions for this (and it's not very stealthy).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
