Kubernetes pentest — Bypassing load balancer
In the name of God
As organizations increasingly adopt Kubernetes for their containerized applications, securing these deployments becomes paramount. However, even with robust security measures in place, misconfigurations can introduce vulnerabilities that put critical services at risk.
During the security assessment, a misconfiguration was discovered that allowed for the complete bypass of the load balancer, enabling direct communicate with the desired service. This misconfiguration raises significant security issues, including:
- Traffic Filtering Bypass: Bypassing the load balancer allows traffic to circumvent any traffic filtering or security measures implemented at the load balancer level. This can potentially enable attackers to directly communicate with the reverse proxy and bypass any restrictions or filters intended to protect the exposed services.
- Authentication and Authorization Circumvention: By bypassing the load balancer, attackers may be able to bypass or circumvent authentication and authorization mechanisms that are typically enforced at the load balancer level.
- loss of Load Balancer Features: The load balancer provides various features and capabilities, such as session management, SSL termination, and rate limiting. Bypassing the load balancer means missing out on these important security features, potentially leaving the exposed services more vulnerable to attacks and abuse.
- Increased Attack Surface: Directly accessing the reverse proxy exposes a new entry point for potential attackers. This increases the overall attack surface of the system and introduces additional risk factors that need to be considered and mitigated.
The Story
As a penetration tester, first it is necessary to identify the exposed services in the Kubernetes cluster, there are several ways to detect which services are exposed to the internet in your Kubernetes cluster:
- Use the
kubectl get services --all-namespacesto list all services in your cluster, then look for services that have a type of “LoadBalancer” or “NodePort”. - If you have an Ingress controller set up in your cluster , you can also use this command
kubectl get ingress --all-namespaces
By employing these commands, you can gain insights into the exposed services in your Kubernetes cluster, let’s assume some of the exposed services that we found are service-1.kube.com, service-2.kube.com .
Now let’s run nslookup command to retrieve the IP addresses associated with that hostname:
Now you can try to sending request directly to the LoadBalancer IP with your desired hostname:
curl -i -s -k -X $’GET’ \
-H $’Host: service-1.kube.com’ \
$’https://<load-balancer>/'
The next step in our assessment is to perform a comprehensive port scan across all of the Node’s IPs in Kubernetes cluster. This will help us identify any open ports on the cluster’s nodes, which could potentially reveal misconfigurations or security vulnerabilities.
To see the IP of the nodes you can use kubectl describe nodes command which provides detailed information about the nodes. Once you have obtained the result , run an Nmap scan against each of the IPs to scan all of the ports:
nmap -sV -Pn -p- <node-IPs>
During the analysis of the Nmap output, it was discovered that certain Node’s IPs had port 8888 open. Further investigation revealed that these open ports were associated with the ingress functionality. This misconfiguration allowed direct communication with the reverse proxy by sending requests to the Node’s IP and port combination, bypassing the load balancer entirely.
curl -i -s -k -X $’GET’ \
-H $’Host: service-1.kube.com’ \
$’https://<NODE-IP:8888>/'
To summarize, the misconfiguration of ingress ports on some of the Node’s IPs posed a significant security issue. It allowed bypassing of the load balancer, potentially exposing the services to various security risks.
