IngressNightmare: CVE-2025-1974 Távoli kódvégrehajtás sebezhetőség és javítás

2025 májusában nyilvánosságra hoztak egy kritikus biztonsági sebezhetőséget, a CVE-2025-1974-et, az IngressNightmare-t, amely a Kubernetes ingress-nginx vezérlőt érinti, és széles körben elterjedt a felhőalapú infrastruktúrákban. Ez a sebezhetőség lehetővé teszi a nem hitelesített támadók számára, hogy tetszőleges konfigurációkat injektáljanak az NGINX-be, ami potenciálisan jogosulatlan RCE (távoli kódfuttatás) és teljes klaszter kompromittálódásához vezethet.

Az OPSWAT ösztöndíjprogram részeként ösztöndíjasaink mélyreható technikai elemzést végeztek, hogy jobban megértsék a probléma kiváltó okát, kiaknázási útvonalát és az ezt a nagy horderejű problémát övező enyhítési stratégiákat.

1. Minden egyes konfigurációt elemez és átad a generateTemplate-nek, hogy az előre definiált NGINX sablonok szerint formázza meg.
2. Ezt követően a testTemplate ellenőrzi a generált konfigurációt az alapul szolgáló NGINX bináris rendszerrel szemben.

Minden NGINX konfiguráció az ingress-nginx forráskódjában található nginx.tmpl fájlban található előre definiált sablonokon alapul:

A generateTemplate függvényen belül a konfiguráció feldolgozása a következő kódrészletben látható módon történik:

A bemeneti érvényesítés és a szanálás azonban nem elegendő. Konkrétan, az Ingress objektumból származó uid mezőt közvetlenül az NGINX konfigurációs sablonjába illesztik be, ami injekciós pontot hoz létre. Egy támadó ezt kihasználhatja, ha olyan szerkesztett bemenetet ad meg, mint például uid="1234#;\n\n}\n}\n}\n injection_value".

Ez a rosszindulatú bemenet lehetővé teszi a globális hatókörbe való befecskendezést az NGINX sablonba, lehetővé téve a támadók számára, hogy tetszőleges NGINX direktívákat indítsanak el, és potenciálisan RCE-t érjenek el.

A sebezhetőség kihasználásához a támadónak azonosítania kell egy olyan utasítást, amely képes rosszindulatú kódot végrehajtani. Kezdetben munkatársaink a load_module direktívát azonosították potenciálisan hasznosnak, mivel ez a direktíva lehetővé teszi az NGINX számára külső bővítmények betöltését. Ez a direktíva azonban csak a konfigurációelemzés korai fázisában engedélyezett, ami nem felel meg a mi befecskendezési pontunknak.

E kihívás megoldása érdekében további kutatásokat folytattunk, amelyek az ssl_engine direktívához vezettek, amelyet így írtunk le: "A modult az OpenSSL dinamikusan betöltheti a konfigurációs tesztelés során". Ez kíváncsiságot keltett a modulok dinamikus betöltésének képessége miatt, ami mélyebb vizsgálatot tett szükségessé.

Indításkor az NGINX betölti a kezdeti állapotát, majd soronként elemzi a konfigurációs fájlokat. Minden egyes direktívát az nginx_command_t struktúra kezel, az ssl_engine direktíva pedig közvetlenül az ngx_openssl_commands-t hívja meg.

Az ngx_openssl_commands függvény elemzése során munkatársaink felfedezték, hogy az OpenSSL támogatásra támaszkodik, különösen az ENGINE_by_id függvényre, amelyet a hardveresen gyorsított SSL modulokhoz használnak.

Az ENGINE_by_id függvény elemzése során pedig megállapítottuk, hogy lehetővé teszi a megosztott könyvtárak dinamikus betöltését. Sőt, ha a könyvtárat az __attribute__ ((constructor))) kiterjesztéssel fordítjuk le, akkor a kapcsolódó függvényt betöltéskor azonnal végre lehet hajtani. Ez azt jelzi, hogy az ssl_engine direktíva kihasználásával egy támadó tetszőleges megosztott könyvtárakat tölthet be a gépre, ami potenciálisan RCE-hez vezethet.

Alapértelmezés szerint, ha egy bejövő kérés meghaladja a 8 KB-ot, az NGINX a kérés testét egy ideiglenes fájlba írja, amely a /tmp/nginx/client-body címen található, cfg-{random_value} formátumú fájlnévvel. Ezek az ideiglenes fájlok legfeljebb 60 másodpercig maradnak meg a beérkezett üzenet sikeres darabjai között.

Miután a kérés részleges testét egy ideiglenes fájlba írta, az NGINX addig halogatja a törlést, amíg a teljes test meg nem érkezik. Ha a kérés hiányos marad, és 60 másodpercig nem érkezik adat, a fájl végül törlésre kerül. Az utolsó adatdarab szándékos visszatartásával azonban egy támadó használatban tarthatja az ideiglenes fájlt, így az kihasználhatóvá válik.

Bár a feltöltött fájl tartalma ellenőrizhető, a véletlenszerű fájlnév miatt nehéz megtalálni azt a fájlrendszerben. A tárolási útvonal a client_body_temp_path segítségével konfigurálható, de a fájlnév véletlenszerűen generálódik futásidőben, így kiszámíthatatlan. Ez a véletlenszerűség jelentősen megnehezíti a célzott hozzáférést még nyers erővel is. Ennek kiküszöbölésére a csapat a Linux operációs rendszerben rejlő viselkedéseket használta ki. Vegyük a következő példát:

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

A fordítás után az eredményül kapott megosztott könyvtár mérete kényelmesen meghaladta a 8 KB-ot, így az NGINX további kitöltés nélkül pufferelte.

A munkatársaink ezután egy felnagyított Content-Length értékű (pl. 1MB) kérést állítottak össze, hogy méretbeli eltérést mutassanak. Ez arra késztette az NGINX-et, hogy a teljes testet pufferelje ahelyett, hogy azonnal feldolgozná, biztosítva ezzel, hogy a megosztott objektum egy kiszámítható helyre íródjon.

A sikeres RCE megköveteli, hogy az ssl_engine utasítás hivatkozzon a pufferelt fájl helyes elérési útvonalára. Ez egy automatizált, nyers erővel végrehajtott szkript segítségével érhető el, amely szisztematikusan végigjárja a folyamatazonosítók és fájlleírók lehetséges kombinációit, hogy azonosítsa a pufferelt megosztott objektumra mutató érvényes szimbolikus hivatkozást.

Az alábbiakban egy minta a generált NGINX sablonból, amely az exploitot kiváltotta.

Sikeres kihasználás után a támadó shell hozzáférést szerezhetett az ingress-nginx pod kontextusában, amely alapértelmezés szerint hozzáférhetett az érzékeny Kubernetes fürt titkaihoz.