[AKTUALIZACJA #1] Uwaga! 0day w Kubernetesie

Aktualizacja #1 (25.03.2025 01:30)
W momencie publikacji niniejszego artykułu oficjalny raport nie był jeszcze dostępny. Zamieszanie z jego opóźnionym wydaniem wyjaśniamy niżej.
Wpis aktualizujemy o podstawową mitygację i wysokopoziomowy opis zagrożenia.

W mediach branżowych pojawiła się dzisiaj informacja o nowej podatności wykrytej przez zespół Wiz Research, działający w ramach firmy skupionej na aspektach bezpieczeństwa w środowiskach chmurowych. Niedawno wykupiło ich Google za kwotę 32 miliardów dolarów. Zespół odpowiedzialny jest m.in. za wykrycie ChaosDB (2021, podatność w Azure Cosmos DB) i niedawnego wycieku wrażliwych danych z DeepSeek AI.

Luka nazwana IngressNightmare pozwala na zdalne wykonanie kodu w popularnym komponencie Ingress NGINX Controller. Zasada działania tego oprogramowania podobna jest do równie popularnego Traefika - jest to odwrotny serwer proxy i load balancer. Jego głównym zadaniem jest zarządzanie zewnętrznym dostępem do usług HTTP w klastrze Kubernetes. Według wstępnych obliczeń, około 40% aplikacji wystawionych do internetu w ramach klastrów Kubernetesowych jest obecnie podatna na atak.

Podatność ta ma szansę na uzyskanie kultowej rangi, obok EternalBlue i Log4Shell.

schemat ataku IngressNightmare | źródło: Wiz Research

Co poszło nie tak?

Kilka zagranicznych portali opublikowało swoje artykuły dokładnie opisujące lukę. W jednym z nich możemy przeczytać:

“Wykorzystanie tych podatności prowadzi do nieautoryzowanego dostępu do wszystkich sekretów przechowywanych we wszystkich przestrzeniach nazw w klastrze Kubernetes przez atakujących, co może skutkować przejęciem kontroli nad klastrem” - powiedziała firma w raporcie udostępnionym The Hacker News.

Jak wygląda raport, na który się powołują? (stan na moment publikacji artykułu w bezpieka.com)

nieistniejąca strona, raport nie został jeszcze opublikowany

Według informacji, do których udało nam się dotrzeć, Wiz Research planował skoordynowane upublicznienie podatności. Media otrzymały materiały prasowe, na podstawie których powstały artykuły informujące o zagrożeniu. Publikacja miała nastąpić po wydaniu łatek bezpieczeństwa. Ale ktoś się pośpieszył i artykuły ujrzały światło dzienne w momencie, gdy żadne z tysięcy publicznie dostępnych instancji Kubernetesa nie mogły jeszcze zostać w prosty sposób załatane.

Ze względu na minimalizację okna podatności, jednoczesne udostępnienie informacji o luce i łatki zmniejsza czas, w którym systemy są narażone na atak. Hakerzy często wykorzystują podatności zero-day, czyli luki odkryte przed przygotowaniem poprawki przez producenta oprogramowania.

W takich warunkach, IngressNightmare to błąd z klasy 0day.

W obecnej chwili (dwie godziny po publikacji pierwszych artykułów) łatki nie trafiły jeszcze do oficjalnego wydania. Podczas [aktualizacji #1] nadal nie wydano poprawionej wersji.

otwarte pull requesty w repozytorium

Osoby odpowiedzialne za utrzymanie repozytorium Github podatnego narzędzia Ingress NGINX Controller zdają się mieć problemy z automatycznymi testami kodu. Proces nie dochodzi do skutku (testy wykrywają niezgodność z założonymi regułami testowania) i nie pozwalają włączyć kodu łatek do głównej gałęzi repozytorium.

nieudane testy automatyczne

[Aktualizacja #1]: około godziny 23:30 (24.03.2025) Wiz Research opublikował raport o podatności. Od opisania luki przez media do publikacji raportu minęło 3.5 godziny. Nadal nie wydano łatek bezpieczeństwa.

Mitygacja

W chwili publikacji [aktualizacji #1] do niniejszego artykułu nie została wydana poprawiona wersja podatnego oprogramowania.

Jeżeli korzystasz z Ingress Nginx Controller w wersji niższej niż 1.12.1 lub 1.11.5 (backport) - Twój klaster jest podatny.

Oficjalny raport proponuje kilka tymczasowych rozwiązań naprawiających problem. Najprostrze z nich to wyłączenie podatnego komponentu (admission controller).

Jeżeli zainstalowałeś ingress-nginx przy użyciu Helm, przeinstaluj pakiet z controller.admissionWebhooks.enabled=false

Jeżeli zainstalowałeś ingress-nginx ręcznie, usuń config ValidatingWebhookConfiguration nazwany ingress-nginx-admission, a także usuń argument --validating-webhook z DaemonSetu lub Deploymentu kontenera.

Do testowania podatności dostępna jest templatka Nuclei.

Wysokopoziomowy opis podatności

Słowniczek:
ingress - kierunek wchodzący
obiekty - opisują zakładany stan klastra, instrukcje uruchamiania i zarządzania konteneryzowanymi aplikacjami

ingress-nginx wdraża komponent admission controller działający zazwyczaj w tym samym podzie, w którym uruchomiony jest główny kontroler. Nasłuchuje na porcie 8443. Odpowiada za walidację obiektów ingress przed ich wdrożeniem. Domyślnie admission controller jest dostępny przez sieć bez uwierzytelniania!

Gdy admission controller przetwarza przychodzący obiekt ingress, tworzy z niego konfigurację NGINX, a następnie sprawdza jej poprawność za pomocą binarki NGINX. W tym właśnie procesie została wykryta luka, która pozwala na zdalne wstrzyknięcie dowolnej konfiguracji NGINX poprzez wysłanie złośliwego obiektu ingress bezpośrednio do admission controllera - przez sieć.

Podczas fazy walidacji konfiguracji, wstrzyknięta konfiguracja NGINX powoduje, że walidator NGINX wykonuje ją, efektywnie umożliwiając zdalne wykonanie kodu (RCE) na podzie, na którym uruchomiony jest kontroler.

Podwyższone uprawnienia admission controllera oraz nieograniczona dostępność sieciowa tworzą krytyczną ścieżkę eskalacji. Wykorzystanie tej luki pozwala atakującemu na wykonanie dowolnego kodu i dostęp do wszystkich sekretów klastra we wszystkich przestrzeniach nazw, co może prowadzić do przejęcia pełnej kontroli nad klastrem.