Skip to main content

Challenge 1 - DNSing with the stars

You have shell access to compromised a Kubernetes pod at the bottom of this page, and your next objective is to compromise other internal services further. As a warmup, utilize DNS scanning to uncover hidden internal services and obtain the flag. We have “loaded your machine with dnscan to ease this process for further challenges.

Challenge 2 - Hello?

Sometimes, it seems we are the only ones around, but we should always be on guard against invisible sidecars reporting sensitive secrets.
Let’s look at the tcpdump to see the traffic that the sidecar is making
Let’s pole around the ip to see if there is other info. Poked around with nmap but did not find anything much. Read the description again and understood the secret was reported by the sidecars in the traffic.

Challenge 3 - Exposed File Share

The targeted big corp utilizes outdated, yet cloud-supported technology for data storage in production. But oh my, this technology was introduced in an era when access control was only network-based 🤦‍️.
It says exposed file share so lets check the information on the file system
There is an efs fs-0779524599b7d5e7e.efs.us-west-1.amazonaws.com
Going through from more information and hints https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-efs-enum
Looked at some nfs-ls writeups and libnfs found a workaround

Challenge 4 - The Beauty and The Ist

Apparently, new service mesh technologies hold unique appeal for ultra-elite users (root users). Don’t abuse this power; use it responsibly and with caution.
Policy
The policy shows us that there is an endpoint istio-get-flag we can request the flag from. However the HTTP verbs POST and GET are denied by an ISTIO policy which we need to bypass. We know the endpoint but not the name of the service. Lets do a dnscan to poke around and find out .
hold unique appeal for ultra-elite users (root users) Let’s look at /etc/passwd to check all the users once, seeing that some of the users could appeal the pod.
There is a user called istio which has shell service. Lets try to switch to the user istio and see if we can do a curl to the istio-pod.

Challenge 5 - Who will guard the guardians?

Where pods are being mutated by a foreign regime, one could abuse its bureaucracy and leak sensitive information from the administrative services.
Policy
Let’s start off with a dnscan to check the services
Let’s understood Kyverno before we dive inKyverno is a tool for Kubernetes that helps manage configurations and enforce policies across clusters. It ensures compliance and security by defining rules through custom resource definitions (CRDs), giving precise control over resource management and behavior.The policy given in the challenge is saying that any pod created in the _sensitive-ns _will have the secret injected in the FLAG env variable.
When a request is made to the Kubernetes API server it is then forwarded to a validator/mutating webhook without authentication. In our case it Kyverno (kyverno-svc.kyverno.svc.cluster.local), if the pod matches the policy apply-flag-to-env it will modify the pod’s specifications (its configuration) after it has been created, but before it’s persisted in the Kubernetes API server.
To create a pod admission request , we can use a tool called kube-review. On your local machine save a pod with a yaml file with the below code, Use the same namespace from the policy initially given to us.
pod.yaml
To create the admission request, download kube-review locally and run the below command
Paste the JSON in a pastebin file and transfer the file to the shell and store in a file named pod.json
We can see the response patch is in base64 converting it on CyberChef we get the flag
Cet2 Avi