AWS EKS VPC CNI NetworkPolicy漏洞：已完成Pod导致网络策略绕过

本文详细披露了AWS EKS集群中VPC CNI控制器的一个安全漏洞。当该控制器配置为管理NetworkPolicy时，会对处于“已完成”状态的Pod错误地保留其防火墙规则，导致其他无关Pod在复用相同IP地址时，能绕过既定的网络访问控制策略，造成潜在的防火墙规则失效。

AWS VDP | 报告 #3328291 - 已完成的Pod存在允许绕过Kubernetes NetworkPolicy | HackerOne

跳转到主要内容 > Hacktivity 机会 目录 排行榜 了解更多关于HackerOne 登录 19#3328291 复制报告ID 复制报告ID 已完成的Pod存在允许绕过Kubernetes NetworkPolicy 分享：时间线 savannabungee 向 AWS VDP 提交了一份报告。 2025年9月5日，11:23 AM UTC

描述 当亚马逊 VPC CNI 控制器被配置为管理 NetworkPolicy 规则时，它会错误地将已完成的 Pod 的防火墙规则当作 Pod 仍在运行一样应用，导致这些规则被应用到其他恰好获得了与已完成 Pod 相同 IP 地址的不相关 Pod 上。

例如，如果有一个 IP 地址为 X 的 Pod A。Pod A 通过 NetworkPolicy 被允许某些访问，VPC CNI 控制器通过在节点上为 IP 地址 X 添加防火墙规则来实现这一点。当 Pod A 完成时（例如，如果它是一个 Job），这些防火墙规则不会被移除。由于 Pod 已完成，其他 Pod 可以自由地获得相同的 IP 地址。如果未被 NetworkPolicy 授予任何访问权限的 Pod B 被分配了相同的 IP 地址 X，那么 Pod B 将继承 Pod A 所拥有的网络访问权限，直到已完成的 Pod A 被删除。

正确的行为应该是检查 Pod 的完成状态，并将 Pod 完成视为与 Pod 删除相同，在 Pod 完成时移除防火墙规则。

受影响版本 我在 EKS 版本 1.33 上进行了测试：

  • 启用了网络策略控制器的自动模式
  • 非自动模式，VPC CNI 插件 v1.19.5-eksbuild.1
  • 非自动模式，VPC CNI 插件 v1.20.1-eksbuild.3 严格模式没有任何效果。

POC 在启用了自动模式的 EKS 集群上，或者设置了 enableNetworkPolicy 为 true 的 VPC CNI 控制器上，应用以下预备 Kubernetes 资源：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

---
apiVersion: v1
kind: Namespace
metadata:
  name: networkpolicy-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: networkpolicy-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami:latest
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: whoami
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress
  namespace: networkpolicy-test
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          test: allowed
    ports:
    - protocol: TCP
      port: 80

此 NetworkPolicy 配置将允许以下 Job 连接到 Deployment：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

---
apiVersion: batch/v1
kind: Job
metadata:
  name: allowed
  namespace: networkpolicy-test
spec:
  template:
    metadata:
      name: curl
      labels:
        test: allowed
    spec:
      containers:
        - name: curl
          image: "alpine/curl:latest"
          command: ["curl", "-v", "whoami.networkpolicy-test.svc.cluster.local:80"]
      restartPolicy: Never

但以下 Job 将被阻止并超时：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

---
apiVersion: batch/v1
kind: Job
metadata:
  name: blocked
  namespace: networkpolicy-test
spec:
  template:
    metadata:
      name: curl
      labels:
        test: blocked
    spec:
      containers:
        - name: curl
          image: "alpine/curl:latest"
          command: ["curl", "-v", "whoami.networkpolicy-test.svc.cluster.local:80"]
      restartPolicy: Never

但是，如果存在一个处于已完成状态的允许的 Job，被阻止的 Pod 有机会获得与已完成的允许 Pod 相同的 IP 地址，当这种情况发生时，被阻止的 Pod 将违反 NetworkPolicy，能够访问 Deployment。

为了便于重现，我建议应用附件的 █████████ 文件来创建 20 个允许的 Job。等待所有 20 个 Job 完成，然后应用附件的 ██████████ 来创建 20 个被阻止的 Job。几乎可以肯定，一些被阻止的 Pod 将被分配与已完成的允许 Pod 匹配的 IP 地址，因此将能够连接到 Deployment 并成功退出。一些被阻止的 Pod 将被分配不同的 IP 地址，结果将正确地无法连接到 Deployment，挂起然后报错。

影响 摘要：在依赖 Kubernetes NetworkPolicy 规则来限制网络访问的 EKS 集群上，存在已完成的且被允许某些访问的 Pod 将导致其他 Pod 被授予相同的访问权限。

savannabungee 更新了漏洞信息。 2025年9月5日，11:27 AM UTC

h1_analyst_lucas HackerOne triage 将状态更改为“需要更多信息”。 更新于 13 天前

您好 ████████， 感谢您的报告。我们感谢您在披露此事上付出的时间和努力。

虽然您的报告提供了有关安全担忧的有价值的高级信息，但我们需要更多详细信息来正确验证和分类此问题。由于我们的安全团队将从头开始重现此问题，我们将从更全面的设置和验证说明中受益匪浅。

请您提供：

  1. 详细的逐步说明，说明测试此问题所需的初始设置
  2. 完整的重现步骤，假设读者对此特定问题没有先验知识
  3. 关于如何验证存在的问题（不对系统造成任何损害）的明确指导
  4. 关于安全影响的更具体细节，包括：
    • 机密性：暴露了哪些具体数据或信息？
    • 完整性：系统完整性如何受到影响？
    • 可用性：对服务可用性的潜在影响是什么？

再次感谢您提请我们注意此问题。我们期待您的回复，以便我们能够正确地评估和处理此问题。

此致， ███████

savannabungee 将状态更改为“新建”。 更新于 13 天前

您好 ███████，我很乐意尝试提供更详细的设置说明。这些步骤用简单的术语解释了初始环境设置（步骤 1-3）、错误重现（步骤 4、6 和 7）以及如何验证问题已复现（步骤 8）。

逐步说明 如果没有可用的、配置了 VPC CNI 控制器来管理 NetworkPolicies 的现有 Kubernetes 集群，设置具有 VPC CNI 控制器的环境的最简单方法是创建一个启用了自动模式的新 EKS 集群。对于大多数初始设置，标准的 AWS 指南就足够了，因此我将参考这些指南。

  1. 创建一个启用自动模式的 EKS 集群：https://docs.aws.amazon.com/eks/latest/userguide/create-cluster-auto.html 如果通过 AWS 控制台操作：
    • 1.1 为集群命名任意名称。
    • 1.2 使用“创建推荐角色”按钮创建一个集群角色（可以命名为任意名称）。
    • 1.3 在集群设置页面选择创建的集群角色。
    • 1.4 所有其他设置可以保留为默认值。
  2. 当集群创建完成后，配置 kubectl：https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
    • 2.1 使用 aws CLI 最容易做到：https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html
    • 2.2 然后应该可以简单地运行 aws eks update-kubeconfig --name <步骤 1 中创建的集群名称>
  3. 启用网络策略管理（参考：https://docs.aws.amazon.com/eks/latest/userguide/auto-net-pol.html）
    • 3.1 运行 kubectl apply -f enable-network-policy.yaml
    • 3.2 运行 kubectl patch nodeclass default --type=merge -p '{"spec":{"networkPolicyEventLogs":"Enabled"}}'
    • 3.3 （此步骤可能不需要）它可能不会对现有节点生效，因此为了以防万一，通过运行 kubectl drain -l karpenter.sh/nodepool=general-purpose --ignore-daemonsets --delete-emptydir-data 清空所有现有节点。
  4. 通过运行 kubectl apply -f setup.yaml 来设置测试 Kubernetes 命名空间和资源。
  5. 验证 Kubernetes NetworkPolicies 是否在集群上正常工作。
    • 5.1 运行 kubectl apply -f blocked-job.yaml
    • 5.2 使用 kubectl get pod -n networkpolicy-test -l test=blocked 检查创建的 Pod 的状态。最初它将显示 Running 状态，然后在超时后将显示 Error 状态。存在状态为 Error 的 Pod 表明 Kubernetes 集群上启用了 NetworkPolicy 管理。存在状态为 Completed 的 Pod 表明集群上 NetworkPolicy 管理未正确配置（返回步骤 3）
    • 5.3 通过运行以下命令清理 Job：kubectl delete job -n networkpolicy-test blocked
  6. 创建旨在能够连接到 whoami deployment 的 Jobs
    • 6.1 运行 kubectl apply -f ████
    • 6.2 所有 Job 都应该启动并在没有错误的情况下完成（即显示 Completed 状态），这可以通过 kubectl get pod -n networkpolicy-test 或 kubectl get job -n networkpolicy-test 来检查。
  7. 创建应该被 NetworkPolicy 阻止的 Jobs
    • 7.1 运行 kubectl apply -f blocked-job20.yaml
    • 7.2 等待片刻，让所有 Pod 启动。
  8. 验证
    • 8.1 使用 kubectl get pod -n networkpolicy-test -l test=blocked 检查被阻止 Pod 的状态。
    • 8.2 所有被阻止的 Pod 本应被配置的 NetworkPolicy 阻止。如果一些 Pod 显示 Completed 状态而其他 Pod 显示 Error 或 Running 状态，则漏洞得到确认。
    • 8.3 为了进一步确认漏洞，通过运行 kubectl get pod -n networkpolicy-test -o wide 检查 Pod 的 IP 地址。所有 IP 地址与一个或多个允许 Pod 的 IP 地址冲突的被阻止 Pod 应显示 Completed 状态。任何 IP 地址与允许 Pod 的 IP 地址不匹配的被阻止 Pod 应显示 Error 或 Running 状态。

影响 同一 Kubernetes 集群上的 Pod 能够访问按 NetworkPolicy 规则（防火墙绕过）应被阻止访问的网络端点。 具体来说，NetworkPolicy 规则被随机错误应用（基于 IP 地址分配）。一些 Pod 将被授予它们本不应拥有的访问权限。这实际上使 EKS 中的 NetworkPolicy 规则无效。

  • 机密性：暴露了哪些具体数据或信息？ 依赖网络控制来保护数据的在 EKS 中运行的服务可能会暴露该数据。
  • 完整性：系统完整性如何受到影响？ 依赖 NetworkPolicy 规则防止未经授权访问端点的服务可以被访问。
  • 可用性：对服务可用性的潜在影响是什么？ 基本不适用。

h1_analyst_lucas HackerOne triage 将严重性从中等 (4.4) 更新为中等 (4.3)。 2025年9月7日，6:58 AM UTC

根据 POC 中提供的证据，我认为严重性显示了以下影响： 同一 Kubernetes 集群上的 Pod 能够访问按 NetworkPolicy 规则应被阻止访问的网络端点，这实际上创建了一个防火墙绕过。因此，适用中等严重性。 请注意，在团队基于补偿控制和上下文做出最终评估后，这可能会发生变化。

h1_analyst_lucas HackerOne triage 将状态更改为“待项目审核”。 更新于 13 天前

您好 ██████， 感谢您的提交！我们能够验证您的报告，并已将其提交给适当的修复团队进行审核。他们将告知我们对此报告的最终裁决，以及是否/何时实施修复。请注意，状态和严重性可能会发生变化。 谢谢， ████████

gabagh00l418 AWS VDP staff 发表了一条评论。 更新于 13 天前

您好 ████████， 我是负责协调漏洞披露的 AWS VDP 团队成员。感谢您将您的关切提请我们注意。我们目前正在审核您的报告，并将每月向您提供可用的更新。 同时，如果您有任何问题，请随时告诉我。 此致， ████

gabagh00l418 AWS VDP staff 将状态更改为“已分类”。 更新于 13 天前

您好 ████████， 感谢您的提交！我们能够验证您的报告，并且正在制定适当的修复方案。 在我们进行修复的同时，我们还想确认您是否计划在任何期刊或其他场合发表您的研究成果。如果是，我们很乐意与您合作。 感谢您协助我们帮助保护客户。如果您有任何进一步的问题、意见或疑虑，请随时与我们联系。 此致， ███████

savannabungee 发表了一条评论。 2025年9月22日，1:18 PM UTC

谢谢。当您认为合适时，我希望您能将报告公开。 我看到此问题已在代码库中修复，关于修复何时部署以及用户是否需要做任何事情的信息，将不胜感激。

gabagh00l418 AWS VDP staff 发表了一条评论。 更新于 13 天前

您好 █████， 感谢您在完成修复过程期间的耐心等待。我很高兴地通知您，我们已经完成了修复程序到所有 EKS 区域的部署，并且客户无需采取任何操作即可应用该修复程序。在披露之前，我们将完成我们的标准准备过程。报告公开后，我会通知您。 此致， ████████

gabagh00l418 AWS VDP staff 关闭了报告并将状态更改为“已解决”。 更新于 13 天前

您好 █████████ 感谢您的耐心等待。我们已经完成了剩余流程，现在我将着手解决此案，并努力使该报告公开可用。 此致， ███

gabagh00l418 AWS VDP staff 请求披露此报告。 13 天前

gabagh00l418 AWS VDP staff 披露了此报告。 13 天前

报告于 2025年9月5日，11:23 AM UTC 报告人 savannabungee 报告给 AWS VDP 管理参与者 报告 ID #3328291 已解决 严重性 中等 (4.3) 披露于 2025年11月19日，11:05 PM UTC 弱点 不正确的访问控制 - 通用 CVE ID 无 赏金 无 账户详情 无

看起来您的 JavaScript 被禁用了。要使用 HackerOne，请在浏览器中启用 JavaScript 并刷新此页面。

comments powered by Disqus
© 2020 - 2026 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次