IngressNightmare: обнаружение и митигация критических уязвимостей с помощью Luntry
15 апреля 2025
Автор: Сергей Канибор
Что случилось
24 марта 2025 года исследователи из Wiz Research раскрыли серию критических уязвимостей в Ingress NGINX Controller для Kubernetes, получивших общее название IngressNightmare:

• CVE-2025−1097: Auth-TLS-Match-CN Annotation Injection
• CVE-2025−1098: Mirror UID Injection
• CVE-2025−24 514: Auth-URL Annotation Injection
• CVE-2025−1974: NGINX Configuration Code Execution

Уязвимость с идентификатором CVE-2025−1974 позволяет злоумышленнику выполнить Remote Code Execution (RCE). Ей присвоена оценка 9.8 по CVSS. По данным Wiz Research, эксплуатация уязвимости позволяет злоумышленникам получить несанкционированный доступ ко всем секретам во всех Namespaces, что потенциально может привести к полному захвату кластера.

Доступом ко всем секретам в кластере наделена ClusterRole, используемая Service Account ingress nginx для его работы.
Код из файла YAML
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ingress-nginx
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - nodes
  - pods
  - secrets
  - namespaces
  verbs:
  - list
  - watch
…
И сегодня мы посмотрим как Luntry может помочь вам в данном случае, как мы это уже делали с инцидентами xz-utils, ingress kong и CVE-2024−0132.
Знакомство с Admission Controller Ingress NGINX
Все эти уязвимости находятся внутри компонента Admission Controller Ingress NGINX. Этот контроллер проверяет Ingress ресурсы перед их деплоем. По умолчанию этот контроллер доступен в Kubernetes сети без аутентификации, если обратиться на соответствующий адрес webhook (по умолчанию, validate.nginx.ingress.kubernetes.io), что делает его веcьма привлекательным вектором атаки.
Когда Admission Controller Ingress NGINX обрабатывает приходящий в Admission Review Ingress ресурс, он:

• создает конфигурацию NGINX на основе Ingress ресурса;
• проверяет эту конфигурацию с помощью бинарного файла NGINX.

Уязвимости возникают в этом процессе проверки.
Во время эксплуатации уязвимости на сетевой карте Luntry можно увидеть входящие соединения для ingress-nginx-controller-admission и ingress-nginx-controller Service (при легитимной работе этих соединений нет).

Так, на сетевой карте мы видим сетевое взаимодействие всех микросервисов в кластере. Выбрав Deployment ingress nginx в соответствующем неймспейсе, мы можем узнать более подробную информацию о входящих и исходящих соединениях. При легитимной работе ingress nginx controller соединений с Admission Controller нет.
Однако, во время эксплуатации уязвимости на сетевой карте Luntry можно увидеть входящие соединения для ingress-nginx-controller-admission и ingress-nginx-controller Service (от микросервиса alpine).
Эксплуатация уязвимости
Исследователи Wiz продемонстрировали, как эта уязвимость может быть использована для удаленного выполнения кода. Ключевым открытием стало обнаружение того, что директива ssl_engine, входящая в состав модуля OpenSSL, может загружать shared libraries, что являлось недокументированным поведением. В отличие от других директив, таких как load_module, директива ssl_engine может быть использована в любом месте конфигурационного файла.
Цепочка уязвимостей, обнаруженная Wiz, работает следующим образом:
  1. Через уязвимость CVE-2025−1974 полезная нагрузка загружается в виде разделяемой библиотеки в Pod ingress nginx, используя функцию буфера client-body NGINX.
  2. Отправить запрос AdmissionReview на Admission Controller, который содержит инъекцию директивы (CVE-2025−1097).
  3. Инжектированная директива (ssl_engine) заставляет NGINX загрузить указанный файл в качестве разделяемой библиотеки.
  4. При загрузке shared library происходит удаленное произвольное выполнение кода (RCE).
Компрометация ingress nginx позволит атакующему получить доступ ко всем секретам в кластере, что в некоторых случаях может привести к полному захвату Kubernetes кластера. На скриншотах из Luntry из раздела RBAC видно, что срабатывает правило Allow read Secrets из встроенной библиотеки правил на Role и Cluster Role ingress-nginx, позволяющие прочитать секреты во всём кластере.
Обнаружение IngressNightmare в Luntry
Прежде всего, уязвимость можно обнаружить на ранней стадии, через анализ образов контейнеров. Luntry может сканировать образы в Runtime, CI и Regsitry. По результатам сканирования видно, что в образе присутствует уязвимость CVE-2025−1974, позволяющая получить RCE, у неё есть эксплойт и высокая оценка по EPSS, что говорит о высокой вероятности её эксплуатации злоумышленниками.
В то же время Luntry позволяет обнаружить попытку эксплуатации таких уязвимостей с помощью гибридного подхода (который появился в Luntry с версии 4.3) — благодаря поведенческому анализу и правилам/сигнатурам. Данный подход мы реализовали первые в мире, что позволяет нам сочетать лучшие стороны whitelist и blacklist подходов.

Ввиду технических деталей эксплуатации уязвимости атакующему необходимо угадать нужный PID и FD. Для этого он будет чрезвычайно часто обращаться к /proc/*/fd/*, что мы и увидим в аномалиях (позволяет обнаружить эксплуатацию даже 0day уязвимости):
Также, зная эту особенность (удобно для обнаружения 1day уязвимостей), мы можем создать Runtime Rule для однозначного определения вредоносной активности атакующего.
Отдельно стоит отметить, что решения, которые ориентируются на запрет или приостановку запрещенных исполняемых файлов, здесь не помогут, так как происходит подгрузка библиотеки, а не запуск исполняемого файла.

Также в случае реагирования на инцидент нужно полностью завершить скомпроментированный контейнер, предварительно сняв артефакты для форензики. Это также можно сделать с помощью Reaction Policy в Luntry.
Митигация IngressNightmare
1. Обновляйте ПО
Не забывайте про обновление системного и инфраструктурного программного обеспечения. Luntry позволяет контролировать это помимо контроля уязвимостей пользовательских образов. Но помните, что всегда есть окно времени между тем, как выйдет патч и тем, когда он будет применен во всей инфраструктуре.

2. Используйте Network Policy
Эксплуатация уязвимости подразумевает сетевое взаимодействие с Admission Controller NGINX. Однако, легитимные нагрузки никогда не будут обращаться напрямую в Admission Controller NGINX.
Есть только исходящие соединения из данного сервиса.
Таким образом, уязвимость можно митигировать, применив Network Policy, ограничив взаимодействие с ним по сети. Это можно сделать с помощью Luntry, сгенерировав необходимую Network Policy в формате Native, Calico или Cilium, и прямо применив из интерфейса.
В сгенерированной Cilium Network Policy мы видим, что политика в нашем случае разрешает исходящее соединение только к легитимным компонентам Luntry и Kubernetes API. Никаких входящих соединений не разрешено.
3. Контролируйте поведение приложений в контейнерах
Очень важно видеть, понимать и контролировать происходящие внутри контейнеров, чтобы обнаруживать атаки в процессе их осуществления. Luntry дает самый передовой способ для работы с runtime защитой — гибридный подход. Это позволит командам SOC быть готовым к абсолютно любым ситуациям.

Оставьте запрос

и узнайте, как Luntry может помочь вам выстроить эшелонированную оборону вашей инфраструктуры

Оставить запрос
Выводы
В Cloud Native инфраструктуре уязвимости и атаки могут быть чрезвычайно изощренными и IngressNightmare является прекрасным примером. Для противодействие такому роду атак нужно использовать целый комплекс мер от встроенных NetworkPolicy, до продвинутых runtime защит. Только эшелонированная оборона поможет сделать действительно надежное и безопасное окружение.


Подпишитесь

и получайте подборку лучших постов блога в почту