IngressNightterror (CVE-2025-1974)

Обзор

Этот репозиторий содержит моё исследование уязвимости IngressNightmare. В нём находятся файлы развёртывания уязвимого Ingress, сам эксплойт и пейлоад в виде shared object.

CVE

Список индексов CVE:

• CVE-2025-1974 - корневая уязвимость
• CVE-2025-24514 - инъекция через аннотацию auth-url
• CVE-2025-1097 - инъекция через аннотацию auth-tls-match-cn
• CVE-2025-1098 - злоупотребление UID образа

Ссылки

Просто несколько ссылок:

• Оригинальный пост WIZ Research
• Проблема в GitHub Kubernetes
• Пост в блоге Kubernetes
• Бюллетень Amazon AWS
• Бюллетень Google Cloud

Корневая причина

Корень этой уязвимости — отсутствие должной санитизации входных данных. Когда вы отправляете запрос AdmissionReview, создаётся временная конфигурация NGINX, которая затем проверяется на корректность с помощью команды nginx -t. Смотрите исходный код с устранённой ошибкой.

Возможность контролировать содержимое проверяемой конфигурации позволяет нам использовать широкий набор полей конфигурации для инъекции некорректной конфигурации:

• auth-url - передаётся без должной санитизации, что позволяет добавить # и \n. Мы будем использовать эту точку инъекции.
• auth-tls-match-cn - требует только, чтобы поле начиналось с CN= и было корректным регулярным выражением.
• ing.UID - UID попадает в конфигурацию как есть.

Тот факт, что конфигурация NGINX только проверяется, несколько сокращает число директив, которые мы можем использовать. Одной из оставшихся директив является ssl_engine, которая позволяет загружать разделяемые библиотеки. Это удобная точка входа. Но как поместить наш .so-файл в файловую систему пода?

Умные ребята из WIZ придумали отправлять запрос с нашим .so-объектом в теле; если он достаточно большой, NGINX сохраняет его в файл в procfs! Мы также можем подогнать Content-Length, заставив NGINX ждать дополнительные данные, из-за чего он будет некоторое время держать файл в procfs. Фактические номера PID и FD придётся подбирать.

Для получения дополнительной информации читайте оригинальный анализ от исследовательской команды WIZ.

Эксплуатация

Код эксплойта довольно понятен сам по себе. Так что смотрите исходный код.

Настройка стенда

1. Клонируйте репозиторий:

   root@kitploit:~

   git clone https://github.com/I3r1h0n/IngressNightterror
   cd IngressNightterror
   

2. Запустите docker-образ k3s:

   root@kitploit:~

   cd stand
   docker compose up -d
   

3. Разверните NGINX Ingress:

   Если вы используете Linux/Mac, можете развернуть его с помощью скрипта:

   root@kitploit:~

   ./k8s/setup.sh
   

   ---

   Если вы используете Windows или хотите больше контроля над процессом развёртывания, сделайте это вручную:

   Разверните NGINX Ingress:

   root@kitploit:~

   kubectl --kubeconfig=./output/kubeconfig.yaml apply -f ./k8s/ingress.yaml
   

   Теперь вы можете использовать kubectl с конфигурацией, предоставленной в ./output. Не забудьте использовать namespace ingress-nginx.

   Важное примечание: ingress.yaml создан на основе уязвимого NGINX Ingress

Пейлоад (shared object)

Пейлоад — это простой обратный прокси. Не забудьте изменить порт и IP-адрес перед сборкой с помощью:

make all

Он соберёт shared object с помощью docker-контейнера gcc:latest.

Благодарности

Огромное уважение команде WIZ Research, которая первой обнаружила эту уязвимость, а также мейнтейнерам NGINX Ingress.

сделано I3r1h0n.