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

时间线 savannabungee 向 AWS VDP 提交了一份报告。 2025年9月5日，上午11:23 (UTC)

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

例如，如果你有一个IP地址为X的Pod A。通过NetworkPolicy，Pod A被允许某些访问，VPC CNI控制器通过为节点上的IP地址X添加防火墙规则来实现此效果。当Pod A完成时（例如，如果它是一个Job），这些防火墙规则不会被移除。由于Pod已完成，其他Pod可以自由获取相同的IP地址。如果Pod B未被NetworkPolicy授予任何访问权限，却被分配了相同的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) 在启用自动模式或设置enableNetworkPolicy为true的VPC CNI控制器的EKS集群上，应用以下准备性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 (UTC)

h1_analyst_lucas HackerOne 分类员 将状态更改为 需要更多信息。 更新于 7 天前

你好 ████████， 感谢您的报告。我们感谢您在披露方面投入的时间和精力。

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

请您提供：

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

再次感谢您向我们报告此问题。我们期待您的回复，以便我们能正确地评估和处理此问题。

此致， ███████

savannabungee 将状态更改为 新建。 更新于 7 天前

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

分步指南 如果无法获得配置了VPC CNI控制器管理NetworkPolicies的现有Kubernetes集群，则创建具有自动模式的新EKS集群是设置VPC CNI控制器环境的最简单方法。对于大部分初始设置，标准的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 的Job。
   • 6.1 运行 kubectl apply -f ████
   • 6.2 所有Job都应该启动并完成且无错误（即显示状态为 Completed），这可以通过 kubectl get pod -n networkpolicy-test 或 kubectl get job -n networkpolicy-test 检查。
7. 创建那些应被NetworkPolicy阻止的Job。
   • 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 而另一些显示状态为 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 分类员 将严重性从 中等 (4.4) 更新为 中等 (4.3)。 2025年9月7日，上午6:58 (UTC)

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

h1_analyst_lucas HackerOne 分类员 将状态更改为 待项目方审查。 更新于 7 天前

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

gabagh00l418 AWS VDP 工作人员 发表评论。 更新于 7 天前

你好 ████████， 我是AWS VDP团队负责协调漏洞披露的成员。感谢您将您的关切告知我们。我们正在审查您的报告，并将根据进展情况，每月向您提供更新。 同时，如果您有任何疑问，欢迎告诉我。 此致， ████

gabagh00l418 AWS VDP 工作人员 将状态更改为 已分类。 更新于 7 天前

你好 ████████， 感谢您的提交！我们能够验证您的报告，并且正在创建相应的修复措施。 在我们进行修复的同时，我们还想确认您是否计划在任何期刊或其他平台发布您的发现。如果是，我们很乐意与您合作。 感谢您协助我们帮助保护客户的安全。如果您有任何进一步的问题、意见或疑虑，请随时与我们联系。 此致， ███████

savannabungee 发表评论。 2025年9月22日，下午1:18 (UTC)

谢谢。当您认为合适时，如果您能将报告公开，我将不胜感激。 我看到该问题已在代码库中修复，关于修复何时部署以及用户是否需要采取任何措施的指导将非常感谢。

gabagh00l418 AWS VDP 工作人员 发表评论。 更新于 7 天前

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

gabagh00l418 AWS VDP 工作人员 关闭了报告并将状态更改为 已解决。 更新于 7 天前

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

gabagh00l418 AWS VDP 工作人员 请求披露此报告。 7 天前

gabagh00l418 AWS VDP 工作人员 披露了此报告。 7 天前

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