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.
A CVE-2025-1974 áttekintése
A CVE-2025-1974 egy kritikus template injection sebezhetőség, amelyet az ingress-nginx 1.11.4 és különösen az 1.12.0 verzióig terjedő verzióiban azonosítottak. A Kubernetes fürthöz csomóponti szintű hozzáféréssel rendelkező támadók kihasználhatják ezt a hibát tetszőleges kód futtatására RCE segítségével az ingress-nginx vezérlőn keresztül, amely alapértelmezés szerint széleskörű jogosultságokkal rendelkezik, beleértve a hozzáférést a fürtön belüli kritikus titkokhoz.
A Kubernetes Security Response Committee 9,8-as CVSS v3.1 pontszámot (kritikus súlyosságú) adott ennek a sebezhetőségnek:
Az elemzés fő összetevői
Kubernetes áttekintés
A Kubernetes (K8s) egy nyílt forráskódú platform a konténeres alkalmazások telepítésének, skálázásának és üzemeltetési menedzsmentjének automatizálására. A Kubernetes fürtök jellemzően több gépből állnak, amelyek fizikai hardvert és virtuális gépeket is tartalmazhatnak, és amelyek együttesen működnek, hogy nagy rendelkezésre állású, skálázható és kezelhető alkalmazási környezeteket biztosítsanak.
NGINX Ingress vezérlő
Az NGINX ingress controller (ingress-nginx) egy nyílt forráskódú ingress controller, amely az NGINX webszerverre épül. Egy Kubernetes fürtön belül működik, és elsősorban fordított proxyként és terheléselosztóként funkcionál. Ez a vezérlő értelmezi a felhasználók által meghatározott Ingress-erőforrásokat, és lefordítja azokat a fürtbe és a fürtön belüli forgalomáramlás irányítására szolgáló, használható NGINX-konfigurációkra.
AdmissionReview és szerepe
Az Ingress-nginx az AdmissionReview nevű webhook szolgáltatás segítségével integrálódik a Kubernetesbe. Ez a szolgáltatás kulcsfontosságú a natív Kubernetes Ingress objektumok feldolgozásához és azok validált és szintaktikailag helyes NGINX-konfigurációkba történő lefordításához. Bár az AdmissionReview biztosítja a konfiguráció pontosságát, az ingress-nginx vezérlőtől függetlenül működik, és általában nem rendelkezik szigorú hitelesítési ellenőrzésekkel. A szigorú hitelesítés hiánya az egyik kulcsfontosságú tényező, amely hozzájárult a CVE-2025-1974 kihasználhatóságához.
Sebezhetőségek kihasználása és technikai elemzés
Kihasználási mechanizmus
A CVE-2025-1974 kihasználása alapvetően egy rosszindulatú kéréssel kezdődik. A támadók rosszindulatú kérést intéznek az AdmissionReview webhookhoz, és arra kényszerítik az NGINX-et, hogy dinamikusan töltsön be egy megosztott könyvtárat futásidőben. E mechanizmus alapján munkatársaink elemezték mind az AdmissionReview webhookot, mind az NGINX munkafolyamatát, hogy megértsék ezt a kihasználási utat.
Sablon befecskendezés sebezhetőség
Az AdmissionReview webhook esetében a beérkező kérések feldolgozása során a CheckIngress függvény a Kubernetes Ingress-objektumokat érvényes NGINX-konfigurációs fájlokká alakítja át. A folyamat a következőképpen zajlik:
- Minden konfigurációt feldolgoznak, majd átadják a `generateTemplate` függvénynek, hogy az előre definiált NGINX-sablonok szerint formázódjon.
- Ezt követően a testTemplate ellenőrzi, hogy a generált konfiguráció megfelel-e az alapul szolgáló NGINX bináris fájlnak.
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ót az alábbi kódrészletben látható módon dolgozzák fel:
A bevitel-érvényesítés és -tisztítás azonban nem elegendő. Pontosabban: az Ingress-objektum „uidfield” mezője közvetlenül beillesztésre kerül az NGINX konfigurációs sablonjába, ami egy behatolási pontot hoz létre. Egy támadó ezt kihasználhatja úgy, hogy speciálisan kialakított adatot ad meg, 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 sablonbeviteltől a távoli kódvégrehajtásig
A testTemplate() függvény magyarázata
Miután a `generateTemplate` függvény létrehozta az NGINX-konfigurációt, a `testTemplate` függvény létrehoz egy ideiglenes konfigurációs fájlt, majd az `nginx -c {config_file} -t` paranccsal futtatja az NGINX-könyvtárat. Ez arra kényszeríti az NGINX bináris fájlt, hogy elemezze és érvényesítse a konfigurációt.
A sebezhetőség kihasználásához a támadónak meg kell találnia egy olyan direktívát, amely képes rosszindulatú kód végrehajtására. Kezdetben kollégáink a `load_module` direktívát tartották potenciálisan használhatónak, 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 szakaszában engedélyezett, ami nem egyezik meg a mi behatolási pontunkkal.
A probléma megoldása érdekében folytattuk a kutatást, amely elvezetett az ssl_engine direktívához, amelyet így írnak le: „A modult az OpenSSL dinamikusan betöltheti a konfigurációs tesztelés során.” Ez felkeltette a kíváncsiságunkat a modulok dinamikus betöltésének képessége miatt, ezért alaposabb vizsgálatra volt szükség.
Az ssl_engine irányelv megértése
Annak érdekében, hogy jobban megértsük, hogyan kezeli az NGINX az `ssl_engine` direktívát, valamint hogy meghatározzuk azokat a feltételeket, amelyek mellett az NGINX engedélyezi a további modulok dinamikus betöltését ezen direktíva segítségével, átnéztük az NGINX forráskódját.
Induláskor az NGINX betölti a kezdeti állapotát, majd sorról sorra elemzi a konfigurációs fájlokat. Az egyes utasításokat az `nginx_command_tstructure` kezeli, az `ssl_engine` utasítás pedig közvetlenül az `ngx_openssl_commands`-t hívja meg.
Az ngx_openssl_commands függvény elemzése során kollégáink rájöttek, hogy ez az OpenSSL-támogatásra támaszkodik, konkrétan 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 megállapítottuk, hogy ez lehetővé teszi a megosztott könyvtárak dinamikus betöltését. Ráadásul, ha a könyvtárat a __attribute__((constructor)) kiterjesztéssel fordítják le, a hozzá tartozó függvény már a betöltéskor azonnal végrehajtható. Ez azt jelenti, hogy az ssl_engine direktíva kihasználásával egy támadó tetszőleges megosztott könyvtárakat tölthet be a gazdagépre, ami potenciálisan távoli kódvégrehajtáshoz (RCE) vezethet.
Célzott megosztott könyvtárak és támadási stratégia
A kód megbízható végrehajtásának megkönnyítése érdekében a következő lépés egy megosztott könyvtár azonosítása. Ahelyett, hogy külső könyvtárakra támaszkodnánk, az NGINX saját viselkedéséből adódik egy életképesebb és ellenőrzött megközelítés: az ügyfél testpuffer mechanizmusa. Ez a funkció lehetővé teszi az NGINX számára, hogy a nagyméretű bejövő kéréseket ideiglenes fájlokba pakolja, ami a kiszámítható fájlkezelési viselkedésen alapuló kihasználási lehetőségeket nyit meg.
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 fájlrendszerben való megtalálása a véletlenszerű fájlnév miatt nehéz. A tárolási útvonal a client_body_temp_path segítségével konfigurálható, de a fájlnév futásidőben véletlenszerűen generálódik, így nem jósolható meg. Ez a véletlenszerűség jelentősen megnehezíti a célzott hozzáférést még brute force-módszerrel is. Ennek leküzdésére a csapat a Linux operációs rendszerre jellemző viselkedési mintákat használt ki. Tekintsü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 kizsákmányolás szimulálása
A fenti elemzés alapján az Ingress-NGINX podon belül az RCE gyakorlati kihasználása a következő:
- Egy rosszindulatú megosztott könyvtár feltöltése az NGINX ügyféltest puffermechanizmusának használatával, hogy ideiglenesen a fájlrendszerben tárolja azt.
- A sablonbefecskendezéssel olyan nyers erővel történő próbálkozást kezdeményezhet, amely arra kényszeríti az NGINX-et, hogy a korábban feltöltött megosztott könyvtárat sebezhető direktívákon keresztül töltse be.
A megosztott könyvtárat tartalmazó hasznos teher elkészítése
A kód betöltéskor történő végrehajtásának biztosítása érdekében a rosszindulatú megosztott könyvtáron belül egy belépési pontfüggvényt definiálnak konstruktorkiterjesztéssel. Ez a függvény az NGINX betöltésekor végrehajtódik, és célja, hogy fordított héjkapcsolatot hozzon létre egy távoli állomáshoz.
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 kutatóink ezután olyan kérést állítottak össze, amelyben a Content-Length értéket túlzottan magasra állították (pl. 1 MB), hogy méreteltérést idézzenek elő. Ez azt eredményezte, hogy az NGINX a teljes testet pufferbe tárolta, ahelyett, hogy azonnal feldolgozta volna, így biztosítva, hogy a megosztott objektum egy előre megjósolható helyre kerüljön.
A megosztott könyvtár kiváltása injektálással
Miután a megosztott könyvtár felállt, ezután a sebezhető uidfield segítségével egy rosszindulatú utasítást csempésztünk be az NGINX konfigurációjába. Ez az utasítás tartalmazta az ssl_engine parancsot, amely a pufferelt fájl elérési útjára mutatott:
Az RCE sikeres végrehajtásához az ssl_engine direktívának a pufferelt fájl helyes elérési útjára kell hivatkoznia. Ez egy automatizált brute force szkript segítségével érhető el, amely szisztematikusan végigveszi a folyamatazonosítók és a fájlleírók lehetséges kombinációit, hogy azonosítsa a pufferelt megosztott objektumra mutató érvényes szimbolikus linket.
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.
Kárenyhítés és helyreállítás
A CVE-2025-1974-hez kapcsolódó kockázatok hatékony csökkentéséhez a szervezeteknek olyan megoldásra van szükségük, amely átláthatóságot és ellenőrzést biztosít a nyílt forráskódú komponensek felett.
Az OPSWAT SBOM, a MetaDefender® platform egyik alaptechnológiája, ezt az igényt a szoftverkomponensek, könyvtárak, Docker-konténerek és függőségek leltározásával elégíti ki. Lehetővé teszi a szervezetek számára, hogy nyomon kövessék, biztosítsák és proaktívan frissítsék komponenseiket.
A fenti példában a MetaDefender Core™ SBOM technológiája a CVE-2025-1974 sebezhetőséget tartalmazó nginx-ingress-controller csomagot vizsgálta. A rendszer automatikusan kritikusnak jelölte a problémát, és útmutatást adott az elérhető javított verziókról, így a csapatok gyorsan prioritást adhattak a sebezhetőségnek, és gyorsan javíthatták azt, mielőtt kihasználhatóvá válna.
OPSWAT SBOM elérhető a MetaDefender Core és a MetaDefender Software Supply Chain™ rendszerben, lehetővé téve a biztonsági csapatok számára, hogy gyorsabban azonosítsák a sebezhetőségeket, és gyorsabban reagáljanak rájuk. Az OPSWAT SBOM segítségével a biztonsági csapatok:
- Gyorsan megtalálhatja a sebezhető komponenseket - Azonnal azonosíthatja a deserializációs támadások által érintett nyílt forráskódú komponenseket. Ez biztosítja a gyors intézkedést a sebezhető könyvtárak foltozása vagy cseréje terén.
- Proaktív javítások és frissítések biztosítása - Folyamatosan figyelje a nyílt forráskódú komponenseket OPSWAT SBOM-on keresztül, hogy a deserializációs sebezhetőségek előtt járjon. OPSWAT SBOM képes észlelni az elavult vagy nem biztonságos komponenseket, lehetővé téve az időben történő frissítést és a támadásoknak való kitettség csökkentését.
- Megfelelés és jelentéstétel fenntartása - OPSWAT SBOM segít a szervezeteknek megfelelni a megfelelési követelményeknek, mivel a szabályozási keretek egyre inkább előírják a szoftverellátási láncok átláthatóságát.
