# CVE-2025-1974 — IngressNightmare (ingress-nginx)
## Введение
В данном документе представлено исследование уязвимости **CVE-2025-1974**, затрагивающей компонент **ingress-nginx** (validating admission controller) для Kubernetes.
CVE-2025-1974 — критическая уязвимость (CVSS 3.1 **9.8**), представляющая собой unauthenticated **Remote Code Execution (RCE)** в контексте процесса ingress-nginx. При выполнении атаки злоумышленник, имеющий доступ к pod-сети (или способ доставить `AdmissionReview` к validating webhook), может добиться выполнения произвольного кода в pod’е контроллера, что потенциально ведёт к раскрытию Secrets и захвату кластера.
Ingress-nginx — один из самых распространённых контроллеров Ingress в Kubernetes (оценки показывали использование в десятках процентов кластеров), поэтому практический импакт уязвимости очень высок. Описание, технический анализ и официальные рекомендации по фиксам опубликованы Kubernetes, исследователями Wiz и рядом вендор-блогов.
---
## Цель отчёта
Пошагово разобрать CVE-2025-1974 и подготовить материалы, необходимые для write-up:
1. **Сбор и структурирование материалов.** Собрать официальные advisories, исследовательские write-ups и vendor-аналитику; выделить ключевые технические детали и PoC-направления.
2. **Понять суть уязвимости и её импакт.** Объяснить root cause, атак-цепочку и возможные последствия (RCE → disclosure of Secrets → cluster takeover).
3. **Определить CPE и условия конфигурации.** Перечислить версии/пакеты и конфигурации Kubernetes/ingress-nginx, при которых уязвимость актуальна.
4. **Дать рекомендации по безопасному тестированию в лабе** и минимизации риска при массовой проверке.
---
## ⚠️ Дисклеймер
Данное исследование проводится **исключительно в образовательных и этичных целях** и ориентировано на тестовые/контролируемые среды.
**Ни при каких условиях** не запускать эксплойты/PoC против чужих кластеров или публично-доступных инстансов без письменного разрешения владельца. Публикация полностью рабочей «weaponized» PoC в открытом виде сильно повышает риск злоупотреблений — в публичной части лучше приводить safe-PoC и методологию. (Официальные advisories и вендоры также подчёркивают осторожность при распространении эксплойтов).
---
## CPE и условия конфигурации
- `cpe:2.3:a:kubernetes:ingress-nginx_controller:<version>` — уязвимые версии ingress-nginx (в advisories указаны конкретные версии; обновите значения при финальной публикации).
- Поставщики/дистрибутивы, включающие уязвимый контроллер:
- RKE2 / Rancher дистрибутивы с ingress-nginx до указанных патч-версий.
- Harvester версии, использующие уязвимый ingress-nginx (вендор-KB содержит конкретные affected builds).
- Пользовательские кластеры, где ingress-nginx установлен отдельно (Helm chart/manifest) — проверять версии chart/image.
**Условия конфигурации, при которых уязвимость актуальна:**
1. **Уязвимая версия ingress-nginx** (до релиза/патча, указанного в advisories). Точные номера версий см. в NVD и вендорских advisories.
2. **Validating admission webhook доступен снаружи pod-сети** — если webhook доступен извне (например, публичный endpoint, провайдер ошибочно пробросил сервис), эксплойт может быть выполнен удалённо. Wiz и другие исследователи указывали на многочисленные случаи публичного экспонирования.
3. **Отсутствие NetworkPolicy / изоляции pod-сети:** если злоумышленник может отправлять запросы из какого-либо pod’а в кластер-сеть (compromised pod), это достаточно для эксплуатации.
4. **Отсутствие дополнительных валидаций/ACL перед admission controller:** дополнительные фильтры/ingress-proxy аутентификации могут снижать риск.
5. **Наличие в контейнере ingress-nginx сервис-аккаунта с широкими правами и доступом к Secrets** — по умолчанию контроллер часто монтирует serviceAccount с широкими правами; это увеличивает импакт при успешной эксплуатации.
---
## Подробности уязвимости
**Краткое резюме.**
Уязвимость обнаружена в компоненте **Validating Admission Controller** контроллера **Ingress-NGINX** и связана с тем, как этот компонент формирует и проверяет временную конфигурацию NGINX на основе входящих `Ingress` / `AdmissionReview`. В процессе обработки контроллер генерирует `nginx.conf` и запускает проверку конфигурации (`nginx -t`). При недостаточной санитизации полей `Ingress`/`AdmissionReview` атакующий может подставить специально подготовленные фрагменты, которые попадут в сгенерированный конфиг и в результате приведут к выполнению команд внутри процесса контроллера — то есть к удалённому выполнению кода (RCE) в pod’е ingress-nginx.
### Основные технические моменты
- **Точка входа.** Входящие `AdmissionReview`/`Ingress` объекты, принимаемые validating webhook контроллера, становятся исходными данными для генерации конфигурации NGINX (включая поля аннотаций, backend-настройки и пр.).
- **Механизм эксплуатации.** Сформированный злонамеренный `Ingress` или прямой `AdmissionReview` может внедрить управляемые строки в шаблоны/фрагменты конфигурации. При проверке/загрузке такого `nginx.conf` процесс проверки (`nginx -t`) и последующие операции с файлом конфигурации могут привести к исполнению произвольного кода, записи/запуску файлов или запуску команд в контексте контроллера.
- **Необходимые условия.** Для успешной эксплуатации требуется: уязвимая версия ingress-nginx; возможность доставить `AdmissionReview` до validating webhook (доступ из pod-сети или прямой сетевой доступ); отсутствие компенсирующих мер — NetworkPolicy, RBAC-ограничений или дополнительной аутентификации webhook. В ряде сценариев обход прав Create/Update возможно путём отправки crafted `AdmissionReview` напрямую к webhook.
### Чем это опасно — последствия эксплуатации
Успешная эксплуатация даёт исполнение кода в контейнере ingress-nginx, что, как правило, позволяет:
- получить токен serviceAccount контроллера и обратиться к Kubernetes API;
- читать Secrets и другую конфиденциальную информацию в доступных namespace’ах;
- создавать/изменять ресурсы кластера и расширить доступ (эскалация привилегий, lateral movement);
- в ряде случаев — полный захват кластера.
### Поведенческие и детекционные наблюдения
- При корректной работе контроллера потоков запросов к Admission Controller обычно **нет** — validating webhook служит внутренним компонентом, работающим в пределах кластера. Во время эксплуатации наблюдается аномалия: на сетевой карте (например, Luntry) появление входящих соединений к `ingress-nginx-controller-admission` и сервису `ingress-nginx-controller` от нестандартных источников (в репортах — от контейнеров типа `alpine`), чего при нормальной работе не должно быть.
- Анализ сетевой карты кластера даёт представление о взаимодействиях между микросервисами; выбрав Deployment ingress-nginx в неймспейсе, можно увидеть входящие/исходящие связи. Появление входящих соединений к admission-endpoint в момент атаки — явный индикатор компрометации.
- Для обнаружения попыток эксплуатации полезно мониторить: POST-запросы к validating webhook, создание атипичных Ingress-объектов, вызовы `nginx -t` и внезапные перезапуски контроллера, а также неожиданные операции записи файлов от процесса ingress-nginx.
### Контекст: что такое Ingress-контроллер NGINX и почему он важен
Ingress-NGINX — один из наиболее широко используемых контроллеров Ingress в Kubernetes (широко применяется для организации внешнего доступа к сервисам). Контроллер выступает как обратный прокси: принимает внешний трафик и проксирует его к соответствующим Service/Pod на основе набора правил Ingress. Проект Ingress-NGINX пользуется большой популярностью и имеет значительную долю установки в интернет-доступных кластерах.
Ingress-NGINX в документации Kubernetes приводится как эталонный пример контроллера Ingress. По оценкам, значительная доля открытых кластеров применяют именно его; в некоторых исследованиях указывается, что порядка 41% публично доступных кластеров используют Ingress-NGINX. Именно из-за широкой распространённости и центральной роли в маршрутизации трафика уязвимости в этом компоненте имеют высокий практический импакт.
### Почему validating webhook становится удобным вектором атаки
- По умолчанию validating webhook контроллера доступен внутри сетевого пространства Kubernetes и зачастую не требует дополнительной аутентификации при обращении на его адрес (например, `validate.nginx.ingress.kubernetes.io`). Это делает его лёгким для обращения изнутри кластера.
- Комбинация: широкое распространение контроллера + его сетевой доступ + потенциально широкие права сервис-аккаунта = критическая комбинация, обеспечивающая эффективный путь для компрометации.
- В реальной практике получить «первую точку входа» в кластер не так трудно: приложения часто содержат уязвимости, приводящие к компрометации отдельного контейнера; далее атакующий из этого контейнера может обратиться к internal webhook-ам. Кроме того, exploitable уязвимости типа SSRF в веб-приложениях часто используются, чтобы инициировать запросы внутрь кластерной сети и задействовать такие webhook.
### Повторное описание exploit-цепочки (конспективно)
1. Атакующий получает возможность отправлять запросы в pod-сеть или напрямую обращаться к validating webhook.
2. Формируется специально crafted `Ingress` / `AdmissionReview`, где определённые поля содержат вредоносные строки, не прошедшие надлежащую фильтрацию.
3. Контроллер генерирует `nginx.conf` на основе этих входных данных и выполняет `nginx -t` / другие операции проверки.
4. Внедрённые фрагменты приводят к выполнению команд/скриптов или записи/запуску файлов в контексте процесса контроллера.
5. Получив исполнение, злоумышленник извлекает serviceAccount token, обращается к Kubernetes API и продолжает перемещение и эскалацию в кластере.
### Замечания по совместимости с другими уязвимостями
Такие уязвимости особенно опасны в связке с другими дефектами: компрометированный pod (или SSRF в публичном приложении) + экспонированный validating webhook даёт высокий шанс полного взлома. Поэтому анализ инцидентов должен учитывать цепочку зависимостей и потенциальных векторов, а не только версию ingress-nginx.
---
Log in to view the POC file snapshot cached by Shenlong Bot
Log in to view