Red Hat npm csomagokat ért támadás: 30+ repó felhős hitelesítő adatlopót terjeszt
Egy összehangolt npm ellátási lánc támadási kampány, amely felhős hitelesítő adatok ellopására irányul, a vállalati szoftverek egyik legismertebb nevét érte el. Ismeretlen támadók több mint 30 Red Hat Cloud Services npm csomagot kompromittáltak úgy, hogy először átvették egy Red Hat-alkalmazott GitHub-fiókját, majd ezt a hozzáférést rosszindulatú commitok feltöltésére használták. A csomagokba ágyazott kártevő, amelyet a „Mini Shai-Hulud” törzs egy változataként azonosítottak, automatikusan végrehajtódik a telepítéskor, és azonnal elkezdi kiszivárogtatni a felhős hitelesítő adatokat, többek között az AWS, GCP és Azure hozzáférési kulcsokat, valamint az SSH-kulcsokat és Kubernetes konfigurációs fájlokat.
Ez az incidens nem az npm gyengesége miatt figyelemre méltó, hanem a behatolás módja miatt: egy legitim, megbízható fejlesztői identitáson keresztül történt.
Hogyan kompromittálták a Red Hat npm csomagjait?
A támadási lánc egyetlen Red Hat-alkalmazott GitHub-fiókjának kompromittálásával kezdődött. Miután a támadók bejutottak a fiókba, olyan hozzáférést szereztek, amellyel közvetlenül a Red Hat Cloud Services npm csomagokhoz tartozó repókba tudtak kódot feltölteni. Mivel a commitok egy elismert közreműködői fiókból származtak, az automatizált folyamatok és a kódellenőrzők számára sokkal nehezebb volt bármi gyanúsat észlelni.
Ez a szoftver-ellátási lánc támadás meghatározó jellemzője: a rosszindulatú terhelés legitim szoftver belsejében utazik, aláírva és megbízható csatornákon keresztül terjesztve. Azok a fejlesztők, akik a kompromittálás ablakában telepítették vagy frissítették az érintett csomagok bármelyikét, észrevétlenül futtatták a kártevőt saját rendszerükön, minden nyilvánvaló figyelmeztetés nélkül. Maguk a csomagok továbbra is normálisan működtek, ami tovább nehezítette az észlelést.
A „Mini Shai-Hulud” kártevő változat kifejezetten arra lett tervezve, hogy a telepítés pillanatában fusson, abban a pillanatban, amikor a fejlesztő beírja az npm install parancsot. Nem vár az alkalmazás elindulására, és nem igényel felhasználói interakciót. Ez a megközelítés drámaian lerövidíti a fertőzés és az adatok kiszivárogtatása közötti időt.
Milyen hitelesítő adatokat loptak el, és miért fontosak ezek?
A kártevő célpontlistája olyan, mint egy ellenőrző lista a legkárosabb dolgokról, amiket egy támadó kinyerhet egy fejlesztői munkaállomásról vagy CI/CD folyamatfuttatóról. Az AWS, Google Cloud Platform és Azure hitelesítő fájlok az elsődleges célpontok, mivel ezek a kulcsok gyakran széles körű jogosultságokat biztosítanak a termelési infrastruktúrához. Az SSH privát kulcsok és a Kubernetes konfigurációs fájlok teszik teljessé a zsákmányt, amelyek révén a támadók potenciálisan oldalirányban mozoghatnak belső hálózatokba és konténervezérlő klaszterekbe.
Az automatizált build folyamatokat futtató szervezetek számára a kitettség kockázata megsokszorozódik. A CI/CD rendszerek gyakran hosszú élettartamú felhős hitelesítő adatokat tárolnak környezeti változókként vagy csatolt titkos adatokként. Egyetlen fertőzött build futtató csendben átadhat olyan kulcsokat, amelyek teljes felhőkörnyezeteket irányítanak, ami ajtót nyithat adatkiszivárogtatás, zsarolóvírus telepítés vagy tartós hátsó ajtó hozzáférés előtt.
Ezért a biztonsági csapatoknak észben kell tartaniuk, hogy az ellátási lánc belépési pontjai gyakran láncolódnak további, mélyebb rendszerkompromittálódáshoz. A CISA nemrégiben jelzett CVE-2026-31431, egy Linux helyi jogosultság-kiterjesztési hibája közvetlen emlékeztető: a támadók, akik lopott hitelesítő adatokkal vagy kezdeti hozzáféréssel érkeznek egy rendszerre, ritkán állnak meg itt. A lánc következő láncszemét keresik.
Miért jelentenek vakfoltot az ellátási lánc támadások a szokványos biztonság számára?
A hagyományos biztonsági eszközök arra a feltételezésre épülnek, hogy a fenyegetést a külső, aláíratlan vagy ismeretlen kód jelenti. A tűzfalak, a végponti észlelő ügynökök és az aláírás-alapú szkennerek az anomáliák jelzésére vannak kalibrálva. Az ellátási lánc támadások aláássák ezt a modellt azáltal, hogy olyan szoftverben rejtőznek, amely legitim aláírást hordoz, és várt csatornán keresztül érkezik.
Ebben az esetben a Red Hat márkanév és a kapcsolódó GitHub-fiók előtörténete magas fokú implicit bizalmat kölcsönzött a kompromittált csomagoknak. A Red Hat körüli infrastruktúrán dolgozó fejlesztők pontosan azért telepíthették ezeket a csomagokat, mert azt várták, hogy jól karbantartottak és biztonságosak lesznek.
A szokványos függőség-ellenőrző eszközök, amelyek ismert sebezhető verziókat keresnek, nem kapnák el a telepítéskori hitelesítőadat-lopókat, hacsak a rosszindulatú verziót már nem jelezték egy sérülékenységi adatbázisban. A támadás az „ismerten rossz” észlelés és a viselkedéselemzés közötti rést használja ki.
Rétegzett védelem: titokkezelés, hálózatszegmentálás és VPN-ek
Egyetlen védelem sem állítja meg a kifinomult ellátási lánc támadást, de a rétegzett védelmek jelentősen csökkenthetik a robbanási sugarat.
Titokkezelés a helyi hitelesítő fájlok helyett. A leghatékonyabb enyhítő intézkedés, ha teljesen kiküszöböljük a statikus hitelesítő fájlokat a fejlesztői gépekről és a CI/CD futtatókról. Azok az eszközök, amelyek rövid élettartamú, igény szerinti (just-in-time) hitelesítő adatokat bocsátanak ki, azt jelentik, hogy még ha egy hitelesítő adatot el is lopnak, az lejár, mielőtt a támadó érdemben felhasználhatná.
Függőség rögzítés és sértetlenség-ellenőrzés. A csomagok rögzítése specifikus, ellenőrzött commit hash-ekre a változó verziótartományok helyett korlátozza a váratlan kódváltozásoknak való kitettséget. Ennek kombinálása automatizált sértetlenség-ellenőrzésekkel a csomag tartalmára egy további észlelési réteget hoz létre.
Hálózatszegmentálás és kimenő forgalom szűrése. A Mini Shai-Hulud kártevőnek el kell küldenie valahová a lopott adatokat. A build környezetekből és fejlesztői gépekről érkező kimenő kapcsolatok korlátozása ismert végpontokra megakadályozhatja az adatok kiszivárogtatását még akkor is, ha a kártevő sikeresen végrehajtódik. A VPN-ek és a zéró-bizalom hálózati architektúrák konzisztensen érvényesíthetik ezeket a kimenő forgalomra vonatkozó szabályokat elosztott csapatok esetében is.
Többtényezős hitelesítés minden fejlesztői fiókon. A kezdeti kompromittálódás itt egy GitHub-fiók átvétele volt. Erős MFA követelmények, különösen hardveres biztonsági kulcsok vagy passkey-alapú hitelesítés, jelentősen megnehezítik a fiókeltérítést.
Viselkedésfigyelés a CI/CD folyamatokban. A build fázis során fellépő váratlan kimenő DNS-lekérdezésekre vagy hálózati kapcsolatokra való riasztás felszínre hozhatja a telepítéskori kártevőt, mielőtt a lopott hitelesítő adatokat felhasználnák.
Mit jelent ez Önnek?
Ha az Ön fejlesztői vagy üzemeltetői környezete bármilyen Red Hat Cloud Services npm csomagtól függ, az azonnali prioritás annak ellenőrzése, hogy mely csomagverziók vannak használatban, a kompromittálódásra utaló jelek keresése a hálózati naplókban a telepítési események környékén, valamint az összes felhős hitelesítő adat lecserélése, amelyek jelen lehettek az érintett rendszereken.
Tágabb értelemben ez az incidens arra ösztönöz, hogy vizsgálja felül a teljes felhős hitelesítő adatokkal kapcsolatos higiéniát. A hitelesítő adatok fájlként vannak tárolva a fejlesztői gépeken? A CI/CD környezeti változók a legkisebb jogosultság elvéhez vannak igazítva? Az MFA minden olyan fióknál be van kényszerítve, amely csomagközzétételi joggal rendelkezik?
Az ellátási lánc támadások a bizalom kihasználásával sikeresek. Az ellenszer olyan rendszerek építése, amelyek nem kizárólag az implicit bizalomra támaszkodnak – az ellenőrzött identitások, az időben korlátozott titkok és a viselkedésfigyelés jelentik az alapot. Kezdje még ma egy hitelesítőadat-audittal, és kezeljen minden függőséget potenciális támadási felületként, amely alapos vizsgálatot érdemel.
