WIZ CTF | K8S LAN PARTY Walkthrough
2024-3-22
| 2024-5-28
0  |  阅读时长 0 分钟
type
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
notion image
发现一个服务,访问即可拿到 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肯定还有一个容器,通过网络流量发包,这会我们直接抓包看看他发了啥(一般网络命名空间都是共享的,所以能抓包,网卡用的是同一个)
notion image
果然有一个服务在发送请求,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
notion image
为:istio-protected-pod-service.k8s-lan-party.svc.cluster.local.
 
直接请求
会被policy授权策略禁止访问
 
NCC Group 2020年对Istio做过一次安全评估:(报告里搜索 Istio Client-Side Bypasses
提到Istio客户端存在一些bypass方法
  • UDP协议,因为 Istio 不处理 UDP 数据包
  • 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
notion image
 
看到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
notion image
把 patch 部分 base64 解码就可以得到 flag 了
 
题目提示1:https://github.com/anderseknert/kube-review 这个工具可以将创建Pod的yaml文件直接转AdmissionReview请求json参数,就不用GPT了,也不用对着AdmissionRequest 入参一个个敲
 
这种利用手段主要是在实际利用中获取敏感信息,并不是所有开发都会把敏感信息放 secret 里的(亲身体验
 
  • 云安全
  • Kubernetes
  • CTF
  • Writeup
  • Wiz-CTF
  • 云安全CTF
  • 谷歌Flank潜藏3年的Github Action供应链攻击CVE-2022-0492导致的容器逃逸无法复现原因分析
    Loading...
    目录