Útok na npm balíčky Red Hatu: Více než 30 repozitářů šíří zloděje cloudových přihlašovacích údajů

Koordinovaná kampaň krádeže cloudových přihlašovacích údajů prostřednictvím dodavatelského řetězce npm zasáhla jedno z nejznámějších jmen v podnikovém softwaru. Neznámí útočníci kompromitovali více než 30 npm balíčků Red Hat Cloud Services tím, že nejprve převzali účet zaměstnance Red Hatu na GitHubu a poté tento přístup použili k nahrání škodlivých commitů. Malware vložený do těchto balíčků, identifikovaný jako varianta kmene „Mini Shai-Hulud“, se spouští automaticky při instalaci a okamžitě začne odcizovat cloudové přihlašovací údaje včetně přístupových klíčů k AWS, GCP a Azure spolu s SSH klíči a konfiguračními soubory Kubernetes.

Tento incident nevyniká kvůli slabině samotného npm, ale kvůli způsobu, jakým útočníci pronikli: prostřednictvím legitimní, důvěryhodné identity vývojáře.

Jak byly npm balíčky Red Hatu kompromitovány

Útočný řetězec začal kompromitací jediného účtu na GitHubu patřícího zaměstnanci Red Hatu. Jakmile se útočníci dostali dovnitř, měli přístup potřebný k přímému nahrávání kódu do repozitářů spojených s npm balíčky Red Hat Cloud Services. Protože commity pocházely z uznávaného přispěvatelského účtu, automatizované pipeline a recenzenti čelili mnohem vyšší překážce pro odhalení čehokoli podezřelého.

To je definiční rys útoku na dodavatelský řetězec softwaru: škodlivý obsah putuje uvnitř legitimního softwaru, podepsaný a distribuovaný důvěryhodnými kanály. Vývojáři, kteří během okna kompromitace nainstalovali nebo aktualizovali některý z dotčených balíčků, by nevědomky spustili malware na svých vlastních systémech, bez jakéhokoli zjevného varování. Samotné balíčky nadále fungovaly normálně, což detekci ještě ztížilo.

Varianta malwaru „Mini Shai-Hulud“ je speciálně navržena tak, aby se spustila při instalaci, v okamžiku, kdy vývojář zadá npm install. Nečeká na spuštění aplikace ani na interakci uživatele. Tento přístup dramaticky zkracuje dobu mezi infekcí a exfiltrací dat.

Jaké přihlašovací údaje byly odcizeny a proč na nich záleží

Seznam cílů malwaru vypadá jako kontrolní seznam nejničivějších věcí, které by útočník mohl získat z pracovní stanice vývojáře nebo z runneru CI/CD pipeline. Soubory s přihlašovacími údaji pro AWS, Google Cloud Platform a Azure jsou primárními cíli, protože tyto klíče často nesou rozsáhlá oprávnění napříč produkční infrastrukturou. Soukromé SSH klíče a konfigurační soubory Kubernetes doplňují úlovek a dávají útočníkům potenciální cesty laterálního pohybu do interních sítí a clusterů pro orchestraci kontejnerů.

Pro organizace provozující automatizované build pipeline je riziko expozice ještě větší. CI/CD systémy často ukládají dlouhodobé cloudové přihlašovací údaje jako proměnné prostředí nebo připojené tajné klíče. Jediný infikovaný build runner by mohl tiše předat klíče ovládající celá cloudová prostředí, což by potenciálně otevřelo dveře k exfiltraci dat, nasazení ransomwaru nebo trvalému backdoor přístupu.

To je také důvod, proč by bezpečnostní týmy měly mít na paměti, že vstupní body dodavatelského řetězce často řetězí do hlubší kompromitace systému. Nedávné upozornění CISA na CVE-2026-31431, zranitelnost eskalace lokálních oprávnění v Linuxu, je přímou připomínkou: útočníci, kteří se dostanou do systému s odcizenými přihlašovacími údaji nebo počátečním přístupem, u něj málokdy končí. Hledají další článek v řetězci.

Proč jsou útoky na dodavatelský řetězec slepým místem pro standardní bezpečnost

Konvenční bezpečnostní nástroje jsou postaveny na předpokladu, že hrozbou je externí, nepodepsaný nebo neznámý kód. Firewally, agenti pro detekci koncových bodů a skenery založené na signaturách jsou kalibrovány k označování anomálií. Útoky na dodavatelský řetězec tento model podvracejí tím, že se skrývají uvnitř softwaru, který nese legitimní podpis a přichází očekávaným kanálem.

V tomto případě by značka Red Hat a související historie účtu na GitHubu propůjčily kompromitovaným balíčkům vysokou míru implicitní důvěry. Vývojáři pracující na infrastruktuře spojené s Red Hatem mohli tyto balíčky nainstalovat právě proto, že očekávali, že budou dobře udržované a bezpečné.

Standardní nástroje pro skenování závislostí, které kontrolují známé zranitelné verze, by nezachytily zloděje přihlašovacích údajů spouštěné při instalaci, pokud by škodlivá verze již nebyla označena v databázi zranitelností. Útok využívá mezeru mezi detekcí „známého špatného“ a behaviorální analýzou.

Vrstvená obrana: správa tajných klíčů, segmentace sítě a VPN

Žádná jednotlivá kontrola nezastaví sofistikovaný útok na dodavatelský řetězec, ale vrstvená obrana může výrazně snížit rozsah dopadu.

Správa tajných klíčů namísto lokálních souborů s přihlašovacími údaji. Nejúčinnějším opatřením je zcela odstranit statické soubory s přihlašovacími údaji z vývojářských strojů a CI/CD runnerů. Nástroje, které vydávají krátkodobé, just-in-time přihlašovací údaje, znamenají, že i když je přihlašovací údaj odcizen, vyprší dříve, než jej útočník může smysluplně využít.

Připnutí závislostí a ověřování integrity. Uzamčení balíčků na konkrétní ověřené hashe commitů místo plovoucích rozsahů verzí omezuje expozici neočekávaným změnám kódu. Kombinace s automatizovanými kontrolami integrity obsahu balíčku přidává další vrstvu detekce.

Segmentace sítě a filtrování odchozího provozu. Malware Mini Shai-Hulud potřebuje odcizená data někam odeslat. Omezení odchozích spojení ze sestavovacích prostředí a vývojářských strojů na známé koncové body může zabránit exfiltraci, i když se malware úspěšně spustí. VPN a architektury s nulovou důvěrou mohou tyto politiky odchozího provozu konzistentně vynucovat napříč distribuovanými týmy.

Vícefaktorová autentizace na každém vývojářském účtu. Počáteční kompromitace zde byla převzetí účtu na GitHubu. Silné požadavky na MFA, zejména hardwarové bezpečnostní klíče nebo autentizace založená na passkeys, ztěžují převzetí účtu podstatně více.

Behaviorální monitorování v CI/CD pipeline. Upozorňování na neočekávané odchozí DNS dotazy nebo síťová spojení během fáze sestavení může odhalit malware spouštěný při instalaci dříve, než jsou odcizené přihlašovací údaje použity.

Co to znamená pro vás

Pokud vaše vývojové nebo provozní prostředí závisí na jakýchkoli npm balíčcích Red Hat Cloud Services, okamžitou prioritou je auditovat, které verze balíčků se používají, zkontrolovat indikátory kompromitace v síťových záznamech kolem událostí instalace a rotovat všechny cloudové přihlašovací údaje, které mohly být na dotčených systémech přítomny.

V širším měřítku je tento incident podnětem k revizi hygieny cloudových přihlašovacích údajů od začátku do konce. Jsou přihlašovací údaje ukládány jako soubory na vývojářských strojích? Jsou proměnné prostředí CI/CD omezeny na nejnižší oprávnění? Je MFA vynucována na každém účtu s právy k publikování balíčků?

Útoky na dodavatelský řetězec uspějí zneužitím důvěry. Protiopatřením je budovat systémy, které nespoléhají pouze na implicitní důvěru – ověřené identity, časově omezené tajné klíče a behaviorální monitorování tvoří základ. Začněte ještě dnes auditem přihlašovacích údajů a ke každé závislosti přistupujte jako k potenciálnímu útočnému povrchu, který si zaslouží důkladnou kontrolu.