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.
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
> tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ns-d4e2eb, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:15:28.034418 IP 192.168.10.255.45492 > reporting-service.k8s-lan-party.svc.cluster.local.http: Flags [S], seq 824150725, win 64240, options [mss 1460,sackOK,TS val 4127382585 ecr 0,nop,wscale 7], length 0
12:15:28.035025 IP reporting-service.k8s-lan-party.svc.cluster.local.http > 192.168.10.255.45492: Flags [S.], seq 4148269520, ack 824150726, win 65160, options [mss 1460,sackOK,TS val 494105167 ecr 4127382585,nop,wscale 7], length 0
12:15:28.035036 IP 192.168.10.255.45492 > reporting-service.k8s-lan-party.svc.cluster.local.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 4127382586 ecr 494105167], length 0
12:15:28.035079 IP 192.168.10.255.45492 > reporting-service.k8s-lan-party.svc.cluster.local.http: Flags [P.], seq 1:215, ack 1, win 502, options [nop,nop,TS val 4127382586 ecr 494105167], length 214: HTTP: POST / HTTP/1.1
12:15:28.035400 IP reporting-service.k8s-lan-party.svc.cluster.local.http > 192.168.10.255.45492: Flags [.], ack 215, win 508, options [nop,nop,TS val 494105168 ecr 4127382586], length 0
12:15:28.038611 IP reporting-service.k8s-lan-party.svc.cluster.local.http > 192.168.10.255.45492: Flags [P.], seq 1:206, ack 215, win 508, options [nop,nop,TS val 494105171 ecr 4127382586], length 205: HTTP: HTTP/1.1 200 OK
12:15:28.038619 IP 192.168.10.255.45492 > reporting-service.k8s-lan-party.svc.cluster.local.http: Flags [.], ack 206, win 501, options [nop,nop,TS val 4127382589 ecr 494105171], length 0
12:15:28.038717 IP 192.168.10.255.45492 > reporting-service.k8s-lan-party.svc.cluster.local.http: Flags [F.], seq 215, ack 206, win 501, options [nop,nop,TS val 4127382590 ecr 494105171], length 0
12:15:28.038930 IP reporting-service.k8s-lan-party.svc.cluster.local.http > 192.168.10.255.45492: Flags [F.], seq 206, ack 216, win 508, options [nop,nop,TS val 494105172 ecr 4127382590], length 0
> dig +short reporting-service.k8s-lan-party.svc.cluster.local A
10.100.171.123
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.
# -A prints the packet in ASCII format
> tcpdump -A | grep wiz
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ns-d4e2eb, link-type EN10MB (Ethernet), snapshot length 262144 bytes
wiz_k8s_lan_party{good-crime-comes-with-a-partner-in-a-sidecar}
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
> dig +short fs-0779524599b7d5e7e.efs.us-west-1.amazonaws.com
192.168.124.98
> nfs-ls nfs://192.168.124.98
Failed to mount nfs share : mount_cb: nfs_service failed
# Times out
Looked at some nfs-ls writeups and libnfs found a workaround
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.
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.
Kyverno 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.
> host kyverno-svc.kyverno.svc.cluster.local
kyverno-svc.kyverno.svc.cluster.local has address 10.100.232.19
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.
