k8slanparty
k8slanparty
challenge1
题目描述
1 | DNSing with the stars |
1 | 使用星星进行DNS |
解题过程
查看/etc/resolv.conf配置
1 | player@wiz-k8s-lan-party:~$ cat /etc/resolv.conf |
search域名后缀列表，其中包含了k8s-lan-party.svc.cluster.local，svc.cluster.local，cluster.local等 Kubernetes 默认的域名后缀。这意味着，所有未完全限定的域名查询会自动尝试追加这些后缀。- nameserver 10.100.120.34
表示 DNS 服务器的 IP 地址为10.100.120.34。所有 DNS 查询会通过这个 DNS 服务器进行解析。 - ndots:5
表示，若查询的域名中至少包含 5 个点（.），则会尝试直接进行查询，而不会追加search` 域名后缀。
通过内置的dnscan扫描
1 | player@wiz-k8s-lan-party:~$ dnscan -subnet 10.100.*.* |
配置对应图
1 | +----------------------------------------------------------+ |
然后直接curl就可以出来flag
1 | player@wiz-k8s-lan-party:~$ curl 10.100.136.254 |
后语
本章学习知识，dns扫描
权限进入
这个挑战限制了权限，但是如果是正常的权限进入pod的操作
1 | #找到对应的 Pod 名称 |
DNS 扫描的作用：通过 DNS 扫描可以在没有直接访问权限的情况下，发现 Kubernetes 集群中的服务和资源。
dnscan工具
https://gist.github.com/nirohfeld/c596898673ead369cb8992d97a1c764e
challenge2
题目描述
1 | Hello? |
1 | 你好？ |
解题过程
1 | player@wiz-k8s-lan-party:~$ cat /etc/resolv.conf |
这里通过流量监听操作获取内容
1 | player@wiz-k8s-lan-party:~$ tcpdump -i ns-28fab6 -nn -vvv host 10.100.171.123 |
后语
本章学习知识，Sidecar 容器
https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/
Sidecar 模式是 Kubernetes 中的一种常见设计模式，通常是指将一个附加的容器（Sidecar 容器）与主应用容器（Primary 容器）一起部署在同一个 Pod 中。这些 Sidecar 容器通常提供辅助功能，如日志处理、监控、代理、身份验证、配置管理等。
不安全的容器通信
问题：
Sidecar 容器与主应用容器之间的通信可能未加密或未授权。比如，一些容器可能在明文方式下传输敏感数据，或者 Sidecar 容器未经授权地访问主容器的数据。
攻击路径：
- 如果 Sidecar 容器作为代理容器或日志收集器工作，它可能会与主容器之间进行通信，传输敏感信息。如果该通信没有加密，攻击者可能通过监听容器间的流量来窃取信息。
操作：
监听容器间通信：
如果容器使用了共享的网络命名空间，可以尝试监听容器间的通信流量。攻击者可以使用tcpdump或类似的工具来捕获未加密的流量。1
tcpdump -i eth0 -nn -vvv
这将捕获所有网络接口的流量，可以识别出主应用和 Sidecar 容器之间的通信。
分析流量：
如果捕获的数据包是未加密的，攻击者可以通过分析流量来获取敏感信息，例如身份验证令牌、日志内容等。注入恶意数据：
如果攻击者能通过某些方式拦截并修改容器间的通信流量，就可能执行中间人攻击（MITM），篡改应用数据或执行权限提升。
challenge3
题目描述
1 | Exposed File Share |
1 | 暴露的文件共享 |
解题过程
这里题目打不开了，看参考链接师傅的wp可以看到是网络文件共享问题
1 | mount可以直接看到文件，但是由于权限问题直接获取不了，就用了nfsv4去获取 |
等环境好了再去复现吧
challenge4
题目描述
1 | The Beauty and The Ist |
1 | 美丽与第一 |
1 | apiVersion: security.istio.io/v1beta1 |
解题过程
1 | root@wiz-k8s-lan-party:~# cat /etc/resolv.conf |
Istio 的 Sidecar 代理（通常是 Envoy）通过 iptables 规则拦截和管理 Pod 的网络流量，以实现服务网格的功能。然而，某些配置可能被利用来绕过这些流量管理机制。以下是常见的绕过方法及其实现原理：
- UDP 协议绕过：Istio 默认仅处理 TCP 流量，而不拦截 UDP 数据包。因此，使用 UDP 协议的通信不会经过 Envoy 代理，从而绕过 Istio 的流量管理和安全控制。
- 使用 UID 1337 的用户：Istio 的 Sidecar 代理通常以 UID 1337 运行，并在 iptables 中设置规则，避免拦截该 UID 的流量。如果 Pod 中的主容器也以 UID 1337 运行，其流量将被视为代理自身的流量，从而避开流量重定向，直接与外部通信。
ISTIO - CAP_SETUID 权限的利用：如果容器具有 CAP_SETUID 权限（默认授予），进程可以将其 UID 更改为 1337。通过将进程的 UID 设置为 1337，流量同样可以绕过 Istio 的流量拦截机制。
- CAP_NET_ADMIN 权限的利用：拥有 CAP_NET_ADMIN 权限的容器可以修改自身的网络设置，包括 iptables 规则。攻击者可以利用此权限更改或清除 Istio 设置的 iptables 规则，从而绕过 Envoy 代理的流量管理。
这里是用不了kubectl，所以用其他方法绕过
1 | id |
1 | root@wiz-k8s-lan-party:~# su istio |
后语
这里有bypass的内容
具体方式
https://github.com/istio/istio/wiki/Understanding-IPTables-snapshot#use-pid-to-get-iptables
challenge5
题目描述
1 | Who will guard the guardians? |
1 | 谁来守护守护者？ |
1 | apiVersion: kyverno.io/v1 |
策略为每个容器注入一个名为 FLAG 的环境变量。
解题过程
1 | player@wiz-k8s-lan-party:~$ dnscan -subnet 10.100.*.* |
| 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 | 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}}' |
1 | W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL2NvbnRhaW5lcnMvMC9lbnYvMC92YWx1ZSIsInZhbHVlIjoid2l6X2s4c19sYW5fcGFydHl7eW91LWFyZS1rOHMtbmV0LW1hc3Rlci13aXRoLWdyZWF0LXBvd2VyLXRvLW11dGF0ZS15b3VyLXdheS10by12aWN0b3J5fSJ9LCB7InBhdGgiOiIvbWV0YWRhdGEvYW5ub3RhdGlvbnMiLCJvcCI6ImFkZCIsInZhbHVlIjp7InBvbGljaWVzLmt5dmVybm8uaW8vbGFzdC1hcHBsaWVkLXBhdGNoZXMiOiJpbmplY3QtZW52LXZhcnMuYXBwbHktZmxhZy10by1lbnYua3l2ZXJuby5pbzogcmVwbGFjZWQgL3NwZWMvY29udGFpbmVycy8wL2Vudi8wL3ZhbHVlXG4ifX1d |
后语
flag问题
这个漏洞的核心是 Kyverno 的策略定义了 自动注入环境变量 FLAG 的规则。每当一个新的 Pod 被创建时，Kyverno 会自动根据策略修改 Pod 的配置，并注入指定的环境变量。
漏洞问题
这里核心问题就是 不安全配置 和 Admission Webhook 的滥用 导致的漏洞，而不是 Kubernetes 系统本身的问题。
url问题
**这个一定是 https://kyverno-svc.kyverno.svc.cluster.local/mutate **这个路径，因为是基于 Kyverno 的 Mutating Admission Webhook，所以必须要发送请求到它的 /mutate 路径。原因如下：
- 为什么是
/mutate路径？kyverno-svc是 Kyverno 的核心服务，用于处理 Admission Webhook 请求。- 路径
/mutate是专门用来处理资源（如 Pod）创建或修改请求的入口。它会按照定义的策略修改请求的对象（例如自动注入环境变量）。
- 其他路径的作用
/policymutate是用来修改策略的，通常和策略本身有关，而不是用于修改资源（如 Pod）。/metrics等路径主要是暴露监控信息，和实际的 Admission Webhook 请求无关。
所以，这个思路必须发送到 /mutate，这是漏洞利用的核心。
data 数据
data 数据 不能完全随便写，需要符合一定的格式要求，特别是 Kubernetes Admission Webhook 的 AdmissionReview 格式。具体细节如下：
哪些字段是必须的？
- 基本结构 AdmissionReview 是一个标准的 Kubernetes API 结构，必须包含以下字段：
apiVersion: 必须是"admission.k8s.io/v1"。kind: 必须是"AdmissionReview"。request: 请求内容，具体描述你要操作的资源。
- 关键字段
- **
uid**：这个字段是随机生成的唯一 ID，用于追踪请求。你可以随意设置一个 UUID，但不能省略。 - **
kind和resource**：必须明确你操作的资源类型。例如，kind: Pod表示你在操作 Pod。 - **
operation**：操作类型，通常是CREATE，表示创建一个新资源。 - **
namespace**：必须指定目标命名空间，例如sensitive-ns。 - **
object**：具体描述要创建的资源（如 Pod），这部分内容需要包含资源的详细配置。
- **
- 哪些字段可以修改？
userInfo中的字段（如username,uid）可以随意修改，因为 Kyverno 通常不会严格验证这些字段。但为了模拟合法用户，建议保留类似的格式。
- 哪些字段不能省略？
- 必须包含
object，描述具体的资源对象（如 Pod）。 - 必须包含
dryRun: true，否则请求可能会被实际执行，导致不可预测的结果。
- 必须包含
参考链接
https://tari.moe/2024/k8slanparty.html#9367d23efb7e4568bcbd0e1fd86da080
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 一颗鲸！
