WIZ CTF | K8S LAN PARTY Walkthroughtype
status
date
slug
summary
tags
category
icon
password
0x01 RECON
DNSing with the stars
You have compromised a Kubernetes pod, 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 preloaded 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{*}
这个题目环境不存在域传递漏洞也不存在CoreDNS Wildcards利用，这里是利用 k8s 的 ip 域名PTR（DNS 指针记录，提供与 IP 地址关联的域名）反解特性来获取服务的服务名，具体可以看 https://thegreycorner.com/2023/12/13/kubernetes-internal-service-discovery.html#kubernetes-dns-to-the-partial-rescue
简单来说就是通过ip获取service名
这个 ip地址 就是要爆破的范围了
svc 的ip地址一般在apiserver所在的b段，查看 apiserver ip
扫b段即可，题目内置了一个 dnscan 工具 https://gist.github.com/nirohfeld/c596898673ead369cb8992d97a1c764e
发现一个服务，访问即可拿到 flag
Esonhugh 师傅写了个挺好用的工具：https://github.com/Esonhugh/k8spider 除了service的ip域名反解，同时集成了SRV端口信息收集、CoreDNS Wildcards 特性 和 域传递漏洞功能
0x02 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.
扫一下service网段
请求了一下，但是没啥，但是咧，题目描述说有 sidecar 的话，我们当前容器的Pod肯定还有一个容器，通过网络流量发包，这会我们直接抓包看看他发了啥（一般网络命名空间都是共享的，所以能抓包，网卡用的是同一个）
果然有一个服务在发送请求，flag在请求体里
0x03 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 🤦️.
意思是网络文件共享，先看看 mount
有个 flag，但没权限
直接查看会失败，查了下 nfs-ls 的代码在 https://github.com/sahlberg/libnfs 默认使用 NFSv3
而根据
mount 信息使用的是 nfsv4即可看到 flag.txt，此时直接获取会提示权限不足
但 nfs 可能存在配置问题（比如配置了
no_root_squash 客户端以 root 访问会映射为 nfs服务端本地的root用户），允许客户端伪造 uid 和 gid。根据 libnfs 文档，对应的参数为即可拿到 flag
实际业务场景下，很多时候不得不使用
no_root_squash 然后采用一些其他方式限制正常用户访问，还是希望 NFS 后续能推出更好的颗粒度更小的权限划分功能0x04 BYPASSING BOUNDARIES
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
收集一下 Istio svc
为：
istio-protected-pod-service.k8s-lan-party.svc.cluster.local.直接请求
会被policy授权策略禁止访问
NCC Group 2020年对Istio做过一次安全评估：（报告里搜索
Istio Client-Side Bypasses）提到Istio客户端存在一些bypass方法
- UDP协议，因为 Istio 不处理 UDP 数据包
- 1337 用户 UID，Istio的sidecar创建基于UID的iptables规则。如果Pod中的主容器以UID 1337运行就能绕过使用Envoy代理sidecar的iptables规则，规则详情见 https://github.com/istio/istio/wiki/Understanding-IPTables-snapshot#use-pid-to-get-iptables
CAP_SETUID容器权限，当容器具有CAP_SETUID（一个默认权限）时，任何具有该权限的进程都可以将其UID更改为1337，从而实现上述绕过
- 当容器被授予
CAP_NET_ADMIN权限时，它可以重写自己的iptables规则并绕过Envoy代理
- 入站端口绕过，和这题没什么关系
根据题目介绍，以及我们用的 shell，这次给的用户是 root
Pod 内的主容器和sidecar容器共享用户命名空间
因此可以利用 1337 用户 UID 绕过 Istio 的出站规则
即可拿到 flag
0x05 LATERAL MOVEMENT
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
在 sensitive-ns 命名空间创建 Pod 容器会触发动态准入控制回调到kyverno API（这里是注册到K8S Mutating Webhook）然后修改资源对象，把 FLAG 环境变量注入到新的资源对象中，也就是我们最终要拿到的 flag，但当前的Pod没有权限创建Pod，换个角度，我们在K8S集群内部，可以尝试能否直接请求 kyverno 暴露的API接口来调用该回调接口
先收集一下 svc
看到metric，搜了一下端口为8000
请求可以看到一些请求路由，搜一下，路由写在 kyverno/pkg/config/config.go 里
有两个接口比较引人注目，可以触发 Mutating Webhook，不过第1个按字面意思应该是更改policy的，这里选用第2个，该路由对应的服务为 kyverno-svc.kyverno.svc.cluster.local. ，监听443端口
接下来就是构造请求参数了，题目描述k8s文档里有一个例子
不过他不是创建Pod的，可以自己写一个在sensitive-ns命名空间创建Pod的yaml，
扔给 GPT 让他结合上面官方给的例子帮忙转下即可（其中有不少字段是可以扔掉的，不过像 requestKind、requestResource等一些字段是不能扔掉的，完整入参见
k8s.io/api/admission/v1/types.go:AdmissionRequest）
把 patch 部分 base64 解码就可以得到 flag 了
题目提示1：https://github.com/anderseknert/kube-review 这个工具可以将创建Pod的yaml文件直接转AdmissionReview请求json参数，就不用GPT了，也不用对着AdmissionRequest入参一个个敲
这种利用手段主要是在实际利用中获取敏感信息，并不是所有开发都会把敏感信息放 secret 里的（亲身体验