Challenge: Recon
Statement-
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.
All the flags in the challenge follow the same format: wiz_k8s_lan_party{*}
Checking current permissions-
kubectl auth can-i --list
Environment variables-
Found subdomains in .kube folder-
acme.cert-manager.io
admissionregistration.k8s.io
apiextensions.k8s.io
apiregistration.k8s.io
authentication.k8s.io
authorization.k8s.io
cert-manager.io
certificates.k8s.io
coordination.k8s.io
crd.k8s.amazonaws.com
discovery.k8s.io
elbv2.k8s.aws
events.k8s.io
extensions.istio.io
flowcontrol.apiserver.k8s.io
install.istio.io
kyverno.io
networking.istio.io
networking.k8s.aws
networking.k8s.io
node.k8s.io
rbac.authorization.k8s.io
scheduling.k8s.io
security.istio.io
servergroups.json
storage.k8s.io
telemetry.istio.io
vpcresources.k8s.aws
wgpolicyk8s.io
Found Istio user in Linpeas output-
Kubernetes access token-
By default, service account tokens are mounted in a pod at the following location
/var/run/secrets/kubernetes.io/serviceaccount
namespace- k8s-lan-party
token-
eyJhbGciOiJSUzI1NiIsImtpZCI6IjM3NTcyZTczM2RmZjExYmUyNzIwOTgzNzBhMjgyOGE5MThiNGVmNjYifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjIl0sImV4cCI6MTc1NTE3NTE2NSwiaWF0IjoxNzIzNjM5MTY1LCJpc3MiOiJodHRwczovL29pZGMuZWtzLnVzLXdlc3QtMS5hbWF6b25hd3MuY29tL2lkL0MwNjJDMjA3QzhGNTBERTRFQzI0QTM3MkZGNjBFNTg5Iiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJrOHMtbGFuLXBhcnR5IiwicG9kIjp7Im5hbWUiOiJhdHRhY2tlci1kZXBsb3ltZW50LTc2ZDg1OTA3LTZjODRjNDk0Nzkta2hwY3giLCJ1aWQiOiI2ZjQwZjJjMC1hYzFhLTQ1ZGEtOTVhNy05OGI5MDQyZTZmODAifSwic2VydmljZWFjY291bnQiOnsibmFtZSI6ImRlZmF1bHQiLCJ1aWQiOiIxODc3ZTQyZC1hNWUxLTQ2NTctYjc2NC05YTMxMTA5ZWQwNjEifSwid2FybmFmdGVyIjoxNzIzNjQyNzcyfSwibmJmIjoxNzIzNjM5MTY1LCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6azhzLWxhbi1wYXJ0eTpkZWZhdWx0In0.GbDXYHusTMU_ZnEq9Q5xQn84rlIGNIKrPPSTDLm6RG1j2pwPTTEsxiSe9Y8fdH_UX2nWwwRmHmbaaqW-DqlvNOIEVAg3aZ6gWjrBXXcVmiAvmtBBxJv9ExvET-VbRNwhfbr9w84JiUJAUjV6G__KuC0Ob4kEkoHVKtNDgD7qK0m2t8DPpmexqgN9IecOAI94zBJRnZQkMXSch3-2opyqfelQGvrx6kf12aha8Q7QfJZjVOTvBrEaInocOeDxE9YBFzR1VLgRN06GPEkcwKTX6X51vibMTeLzudSojAgyuJVF9M5Bvl_xWh-6TayJd_jSlnEdOjQoRV1x7VnHGtaaQw
DNS server-
/etc/resolv.conf
- The
search
directive specifies a list of domain suffixes that will be automatically appended to DNS queries when a hostname is not fully qualified (i.e., it doesn't have a dot in it). - The search domains are tried in order until a match is found.
- For example, if you try to resolve the hostname
webserver
, the system will try the following: webserver.k8s-lan-party.svc.cluster.local
webserver.svc.cluster.local
webserver.cluster.local
webserver.us-west-1.compute.internal
This is particularly useful in environments like Kubernetes, where services within the cluster might be resolved using shorter names.
Running reverse DNS lookup on the-
seq 0 255 | xargs -P 50 -I {} bash -c 'for j in {0..255}; do dig -x 10.100.{}.$j +short | grep . && echo "10.100.{}.${j}"; done'
OR
dnscan -subnet 10.100.0.1/16
Challenge: Finding Neighbours
Hello?
Sometimes, it seems we are the only ones around, but we should always be on guard against invisible sidecars reporting sensitive secrets.
https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/
Using linpeas.sh for enumeration.
#Transfer linpeas to the container and add execute permissions to the binary
./linpeas.sh | tee linpeas.out
In linpeas output, We found that our current container has interesting capabilities(Group of system calls)-
cat /proc/1/status | grep -i 'CapEff'
#0000000000003000
capsh --decode=0000000000003000
quick search over AI about these capabilities.
Checking if any network sniffing tools exist and we found it @ /usr/local/bin/tcpdump
Capturing network traffic -
tcpdump -i <interface> -w <output.pcap>
OR
tcpdump -v
Transferred this pcap to local system and upon analyzing pcap we get the flag.
Based upon the HTTP response, we can see istio is being used in the cluster.
Challenge: Data Leakage- 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 🤦‍️.
Again going through the linpeas output-
/efs is non default directory which exists in the container.
Checking mounts /proc/mounts
Found flag .txt in /efs share but didn’t had permissions to read it.
Let us try to remount the share on other directory.
I was unable to mount this share. Then took hint from the challenge.
Got to know about nfs-ls and nfs-cat
nfs-ls nfs://192.168.124.98/?version=4&uid=0&gid=0
nfs-cat 'nfs://192.168.124.98//flag.txt?version=4&uid=0&gid=0'
And after solving 3 challenges I got a certificate
Challenge: 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.
We have been provided with a policy-
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: istio-get-flag
namespace: k8s-lan-party
spec:
action: DENY
selector:
matchLabels:
app: "{flag-pod-name}"
rules:
- from:
- source:
namespaces: ["k8s-lan-party"]
to:
- operation:
methods: ["POST", "GET"]
Running reverse DNS lookup again-
seq 0 255 | xargs -P 50 -I {} bash -c 'for j in {0..255}; do dig -x 10.100.{}.$j +short | grep . && echo "10.100.{}.${j}"; done'
OR
dnscan -subnet 10.100.0.1/16
Istio is an open-source service mesh that helps manage communication, security, and observability in microservices architectures. It provides a way to control how different parts of an application share data with one another
Learning more about ISTIO -
https://www.youtube.com/watch?v=16fgzklcF7Y
https://www.aquasec.com/blog/istio-kubernetes-security-zero-trust-networking/
Security Issues in ISTIO -
Envoy runs as user with UID 1337. The iptables direct all the traffic in the pod to the envoy, except for the traffic of the user with UID 1337. Therefore, in order to circumvent the envoy’s control on the outbound traffic, e.g. to prevent logging and monitoring of the outbound requests, the attacker can perform requests from user with uid 1337.
https://github.com/istio/istio/issues/4286
Challenge: 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-
apiVersion: kyverno.io/v1
kind: Policy
metadata:
name: apply-flag-to-env
namespace: sensitive-ns
spec:
rules:
- name: inject-env-vars
match:
resources:
kinds:
- Pod
mutate:
patchStrategicMerge:
spec:
containers:
- name: "*"
env:
- name: FLAG
value: "{flag}"
10.100.86.210 -> kyverno-cleanup-controller.kyverno.svc.cluster.local.
10.100.126.98 -> kyverno-svc-metrics.kyverno.svc.cluster.local.
10.100.158.213 -> kyverno-reports-controller-metrics.kyverno.svc.cluster.local.
10.100.171.174 -> kyverno-background-controller-metrics.kyverno.svc.cluster.local.
10.100.217.223 -> kyverno-cleanup-controller-metrics.kyverno.svc.cluster.local.
10.100.232.19 -> kyverno-svc.kyverno.svc.cluster.local.
I am unable to solve after this for now.