Kubernetes Network Attacks
Last updated
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 的 桥接 实现的。这个桥接被称为“cbr0”。（一些网络插件会安装它们自己的桥接。）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 来分享黑客技巧。
