支持本站 — 捐款将帮助我们持续运营

目标:1000 元,已筹:702

70.2%

POC详情: b559500f64dc8ef3739362161721b98a68b1c2e4

来源
关联漏洞
标题:Kubernetes ingress-nginx 安全漏洞 (CVE-2025-1974)
描述:Kubernetes ingress-nginx是云原生计算基金会(Cloud Native Computing Foundation)开源的Kubernetes 的入口控制器,使用NGINX作为反向代理和负载均衡器。 Kubernetes ingress-nginx存在安全漏洞,该漏洞源于在某些条件下,未认证的攻击者可通过访问pod网络在ingress-nginx控制器环境中执行任意代码,可能导致Secrets泄露。
描述
My view on IngressNightmare vulnerability (CVE-2025-1974)
介绍
# IngressNightterror (CVE-2025-1974)

<p align="center">
<img src="logo.png" width="450"/>
</p>

### Overview

This repository is my research on IngressNightmare vulnerability. It includes a vulnerable Ingress deploy files, exploit itself and shared object payload.

### CVE

The list of CVE indexes:
- [CVE-2025-1974](https://nvd.nist.gov/vuln/detail/CVE-2025-1974) - Root vulnerability
- [CVE-2025-24514](https://nvd.nist.gov/vuln/detail/CVE-2025-24514) - `auth-url` annotation injection
- [CVE-2025-1097](https://nvd.nist.gov/vuln/detail/CVE-2025-1097) -  `auth-tls-match-cn` annotation injection
- [CVE-2025-1098](https://nvd.nist.gov/vuln/detail/CVE-2025-1098) - image UID abuse

### References

Just some refs:
- [Original WIZ Research post](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities)
- [Kubernetes github issue](https://github.com/kubernetes/kubernetes/issues/131009)
- [Kubernetes blog post](https://kubernetes.io/blog/2025/03/24/ingress-nginx-CVE-2025-1974)
- [Amazon AWS bulletin](https://aws.amazon.com/security/security-bulletins/AWS-2025-006/)
- [Google clound bulletin](https://cloud.google.com/support/bulletins/index#gcp-2025-013)

## Root cause

The root of this vulnerability lies in the lack of proper input sanitization. When you send an `AdmissionReview` request, it creates a temporary NGINX configuration that is later tested for validity using the [`nginx -t`](https://linux.die.net/man/8/nginx) command. See the [source code](https://github.com/kubernetes/ingress-nginx/blob/8c1ecd7655bd052a26e64d3361dede3096cd80c6/internal/ingress/controller/controller.go#L425) with the bug mitigated.

The ability to control the content of the configuration being tested allows us to utilize a wide range of config fields to inject malformed config:
* `auth-url` - goes without proper sanitization, allowing us to add a `#` and `\n`. We will use this injection point.
* `auth-tls-match-cn` - only requires the field to start with `CN=` and be a valid regexp.
* `ing.UID` - the UID goes into the config as-is.

The fact that the NGINX config is only tested slightly reduces the number of directives we can use. One of the directives that is left is [`ssl_engine`](https://nginx.org/en/docs/ngx_core_module.html#ssl_engine), which allows us to load shared libraries. This is a nice entry point. But how can we put our `.so` file into the pod filesystem?

The clever folks at WIZ came up with the idea of sending a request with our `.so` object as the body, and if it's big enough, NGINX saves it to a file in procfs! We can also adjust the `Content-Length`, making NGINX wait for more data, causing it to keep the file in procfs for some time. The actual PID and FD number will be guessed.

For more information, read the original analysis [article](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities) by the WIZ research team.

## Exploitation

The exploit code is pretty self-explanatory. So go watch the source.

## Stand Setup

1. Clone the repository:
   ```bash
   git clone https://github.com/I3r1h0n/IngressNightterror
   cd IngressNightterror
   ```
2. Start a docker [k3s](https://docs.k3s.io/) image:
    ```bash
    cd stand
    docker compose up -d
    ```
3. Deploy the NGINX Ingress:
    
    In case you're using Linux/Mac, you can deploy it using script:
    ```bash
    ./k8s/setup.sh
    ```
    
    ---
    If you on windows, or want more control over deployment process, do these by hands:
    
    Deploy NGINX Ingress:
    ```bash
    kubectl --kubeconfig=./output/kubeconfig.yaml apply -f ./k8s/ingress.yaml
    ```

    Now you can use kubectl with config providen in `./output`. Don't forget to use namespace `ingress-nginx`.

    > **Important note**: the ingress.yaml is made from [vulnerable NGINX Ingress](https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.9.5/deploy/static/provider/cloud/deploy.yaml) 

## Payload shared object

The payload is simple reverse proxy. Don't forget to edit the port and ip address before building it with:
```bash
make all
```

It will build the shared object using docker container `gcc:latest`.

## Creds

Great respect to the WIZ Research Team who originaly discorved a vulnerability, and to NGINX Ingress mainterners.

prod by _I3r1h0n_.
文件快照

[4.0K] /data/pocs/b559500f64dc8ef3739362161721b98a68b1c2e4 ├── [4.0K] exploit │   ├── [ 156] pyproject.toml │   ├── [4.0K] resource │   │   ├── [2.2K] admission.json │   │   └── [ 179] config.toml │   └── [4.0K] src │   └── [4.3K] main.py ├── [2.3M] logo.png ├── [4.0K] payload │   ├── [ 246] Makefile │   └── [4.0K] src │   └── [ 780] main.c ├── [4.2K] README.md └── [4.0K] stand ├── [ 559] docker-compose.yaml └── [4.0K] k8s ├── [ 141] check.sh ├── [ 16K] ingress.yaml └── [ 620] setup.sh 8 directories, 12 files
神龙机器人已为您缓存
备注
    1. 建议优先通过来源进行访问。
    2. 如果因为来源失效或无法访问,请发送邮箱到 f.jinxu#gmail.com 索取本地快照(把 # 换成 @)。
    3. 神龙已为您对POC代码进行快照,为了长期维护,请考虑为本地POC付费,感谢您的支持。