Last updated
学习与实践 AWS 黑客技术： 学习与实践 GCP 黑客技术：
在 Kubernetes 中，观察到默认行为允许在 同一节点上所有容器之间建立连接。这适用于命名空间的区别。这样的连接延伸到 第 2 层（以太网）。因此，这种配置可能使系统暴露于漏洞之中。具体而言，它为 恶意容器 执行 ARP 欺骗攻击 提供了可能性，目标是同一节点上的其他容器。在这种攻击中，恶意容器可以欺骗性地拦截或修改针对其他容器的网络流量。
ARP 欺骗攻击涉及 攻击者在局域网中发送伪造的 ARP（地址解析协议）消息。这导致 攻击者的 MAC 地址与网络上合法计算机或服务器的 IP 地址关联。在成功执行此类攻击后，攻击者可以拦截、修改或甚至停止传输中的数据。该攻击在 OSI 模型的第 2 层上执行，这就是为什么 Kubernetes 在此层的默认连接性引发安全担忧。
在场景中，将创建 4 台机器：
ubuntu-pe: 特权机器，用于逃逸到节点并检查指标（攻击不需要）
ubuntu-attack: 恶意 容器在默认命名空间中
ubuntu-victim: 受害者 机器在 kube-system 命名空间中
mysql: 受害者 机器在默认命名空间中
如果您想了解这里介绍的网络主题的更多细节，请查看参考资料。
一般来说，节点内部的 pod-to-pod 网络是通过一个连接所有 pod 的 bridge 实现的。这个 bridge 被称为“cbr0”。（一些网络插件会安装它们自己的 bridge。）cbr0 还可以处理 ARP（地址解析协议）解析。当一个传入的数据包到达 cbr0 时，它可以使用 ARP 解析目标 MAC 地址。
这一事实意味着，默认情况下，在同一节点上运行的每个 pod都能够在以太网级别（第 2 层）与同一节点上的任何其他 pod 进行通信（与命名空间无关）。
因此，可以在同一节点的 pod 之间执行 ARP 欺骗攻击。
在 Kubernetes 环境中，您通常会发现 1 个（或多个）DNS 服务正在运行，通常在 kube-system 命名空间中：
在之前的信息中，你可以看到一些有趣的内容，服务的IP是10.96.0.10，但运行该服务的pod的IP是172.17.0.2。
如果你检查任何pod内部的DNS地址，你会发现类似这样的内容：
然而，pod 不知道如何到达该地址，因为在这种情况下pod范围是172.17.0.10/26。
因此，pod将把DNS请求发送到地址10.96.0.10，该地址将被cbr0转换为172.17.0.2。
这意味着pod的DNS请求****总是会通过桥接来转换****服务IP到端点IP，即使DNS服务器与pod在同一子网络中。
了解这一点，并且知道ARP攻击是可能的，节点中的pod将能够拦截在子网络中每个pod与桥接之间的流量并修改来自DNS服务器的DNS响应（DNS欺骗）。
此外，如果DNS服务器与攻击者在同一节点中，攻击者可以拦截集群中任何pod的所有DNS请求（在DNS服务器和桥接之间）并修改响应。
我们的目标是窃取至少从ubuntu-victim到mysql的通信。
正如之前提到的，如果你攻陷了与DNS服务器pod在同一节点的pod，你可以通过ARPSpoofing对桥接和DNS pod进行中间人攻击并修改所有DNS响应。
在我们的场景中，下载攻击者pod中的工具并创建一个**名为hosts的文件**，其中包含你想要欺骗的域名，例如：
对ubuntu-victim机器执行攻击：
如果你尝试创建自己的 DNS 欺骗脚本，仅仅修改 DNS 响应是不行的，因为响应将会有源 IP，即恶意 pod 的 IP 地址，并且不会被接受。 你需要生成一个新的 DNS 数据包，其源 IP是受害者发送 DNS 请求的DNS（类似于 172.16.0.2，而不是 10.96.0.10，那是 K8s DNS 服务 IP，而不是 DNS 服务器 IP，更多内容在介绍中）。
你可以在找到一个很好的工具和教程来测试这个。
工具 是一个简单而强大的 API 流量查看器，用于 Kubernetes，能够让你查看微服务之间的所有 API 通信，以帮助你调试和排查回归问题。 它将在选定的 pods 中安装代理，收集它们的流量信息并在一个 web 服务器上显示。然而，你需要高权限的 K8s 权限（而且这并不是很隐蔽）。
学习与实践 AWS 黑客技术： 学习与实践 GCP 黑客技术：
查看 !
加入 💬 或 或 在 Twitter 上关注 🐦 .
通过向 和 github 仓库提交 PR 来分享黑客技巧。
