В развиван проект Kubernetes ingress-контролер ingress-nginx бяха открити четири уязвимости, които позволяват изпълнение на собствен код на сървърите на облачни системи, използващи платформата Kubernetes, и получаване на пълен привилегирован достъп до клъстера Kubernetes. Уязвимостите са оценени с критичен ниво на опасност (9.8 от 10). Проучвателите, открили уязвимостите, им присвоиха кодовото име IngressNightmare и отбелязаха, че те засягат около 43% от облачните среди. Уязвимостите са отстранени в версиите ingress-nginx 1.11.5 и 1.12.1.
Ingress-контролерът играе роля на шлюз и се използва в Kubernetes за организиране на достъп от външната мрежа до услугите в клъстера. Контролерът ingress-nginx е най-популярният и прилага сървър NGINX за пренасочване на заявки към клъстера, маршрутизиране на външни заявки и балансиране на натоварването. Проектът Kubernetes предоставя основни ingress-контролери за AWS, GCE и nginx, последният от които не е свързан с контролера kubernetes-ingress, поддържан от компанията F5/NGINX (разглежданите уязвимости не засягат проекти, разработвани от създателите на NGINX, споменаването на nginx в наименованието ingress-nginx е свързано единствено с използването на nginx като прокси).
Уязвимостите позволяват на неаутентифициран атакуващ да постигне изпълнение на собствен код в контекста на контролера ingress-nginx, при възможност да изпрати заявка към уеб-обработчика Admission. По време на сканирането на мрежата бяха открити над 6500 уязвими клъстера Kubernetes, използващи общодостъпни уязвими контролери с отворен за външни заявки обработчик Admission.
В конфигурацията по подразбиране стартираният от атакуващия код може да получи достъп до настройките на обекта Ingress, в които, между другото, се съхраняват и удостоверения за достъп до сървърите на Kubernetes, което позволява получаване на привилегирован достъп до целия клъстер. Като обходна стратегия за защита се препоръчва деактивиране на функцията "Validating Admission Controller" в ingress-nginx.
Контролерът Admission се стартира в отделна под-среда и извършва проверка на входящите ingress-обекти преди разгръщането им. По подразбиране уеб-обработчикът Admission приема заявки без удостоверяване от публичната мрежа. При извършване на проверка, контролерът Admission създава конфигурация за http-сервера nginx на базата на съдържанието на получения ingress-обект и проверява нейната правилност.
Откритите уязвимости позволяват подмяната на собствени настройки в nginx чрез изпращане на специално оформен ingress-обект директно до контролера Admission. Изследователите установиха, че някои свойства на проверочните заявки, зададени в полето „.request.object.annotations“, се вмъкват директно в конфигурацията на nginx. В такъв случай, генерираната конфигурация не се прилага, а само се тества чрез стартиране на изпълнимия файл „nginx“ с опцията „-t“.
В частност, подмяната на външни данни в конфигурацията се извършва за параметрите „mirror-target“, „mirror-host“ (CVE-2025-1098), „auth-tls-match-cn“ (CVE-2025-1097) и „auth-url“ (CVE-2025-24514). Например, в конфигурационния ред „set $target {{ $externalAuth.URL }};“ вместо „{{ $externalAuth.URL }}“ се поставя URL адресът, зададен в параметъра „auth-url“. В този случай, правилността на URL адреса не се проверява. Съответно, атакуващият може да предаде като URL стойност вида „http://example.com/#; настройки“ и да вмъкне своите настройки в конфигурационния файл.
За изпълнението на произволен код в процеса на проверка на конфигурацията с командата „nginx -t“ изследователите използваха факта, че освен проверка на синтаксиса, nginx зарежда библиотеки с модули и отваря файлове, споменати в конфигурацията, за да оценява тяхната наличност. Сред другото, при обработка на директивата ssl_engine се зарежда посочената в директивата споделена библиотека за SSL-движка.
За да заредят своята библиотека на Kubernetes сървъра, изследователите използваха (CVE-2025-1974) факта, че при обработка на големи заявки nginx запазва тялото на заявката в временно файлово, което веднага се изтрива, но в файловата система „/proc“ за този файл остава отворен файлов дескриптор. Така може едновременно да се изпратят заявки за запазване на временното файлово и иницииране на проверка на конфигурацията, в която в директивата „ssl_engine“ е посочен пътят към дескриптора във файловата система „/proc“.
За да се уверите, че файловият дескриптор остава достъпен за продължителен период, стойността на „Content-Length“ в заявката може да бъде зададена предварително на по-голяма, отколкото всъщност предадените данни (сървърът ще чака приемането на останалите данни). Допълнителна сложност представлява необходимостта от познаване на PID на процеса и номера на файловия дескриптор, свързан с заредената споделена библиотека, но тъй като в контейнера обикновено се използва минимален брой стартирани процеси, необходимите стойности се познават чрез опити. В случай на успех и зареждане на подменената споделена библиотека, атакуващият може да получи достъп до параметрите, съхранявани в pod-средата, достатъчни за управление на целия клъстер.
За да проверите използването на уязвимия ingress-nginx, можете да изпълните командата: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Източник: opennet.ru
