Útok na dodavatelský řetězec: únik klíčů z LiteLLM

Čtyřicet minut. To stačilo tento březen útočníkům, aby z rutinního stahování balíčků udělali masivní krádež dat.

Vývojáři a inženýři, kteří si mysleli, že stahují legitimní vydání open-source knihovny pro integraci AI LiteLLM (verze 1.82.7 a 1.82.8), ve skutečnosti získali kód naplněný zadním vchodem pro prohledávání paměti. Po jeho spuštění škodlivý kód procházel systémovou RAM, sklízel tajné údaje nalezené v ní a streamoval je na servery ovládané útočníky. Výsledkem bylo vynesení mnoha terabajtů citlivých dat z některých z největších světových firem.

Jak kompromitace balíčku přerostla v globální katastrofu dodavatelského řetězce

Bezpečnostní výzkumníci později našli úložiště o objemu přibližně 195 terabajtů. Uvnitř se nacházely cloudové přístupové klíče, tokeny registrů kontejnerů, SSH klíče a aktivní databázová hesla vázaná na více než 2 500 organizací. Datový soubor také obsahoval přihlašovací údaje z více než 434 000 záznamů CI/CD pipeline, z nichž mnohé byly vystavené kvůli příliš povolným veřejným konfiguracím pipeline. Stručně: jakmile byly důvěrné údaje v paměti nebo v proměnných pipeline, byly v ohrožení.

Vniknutí nezačalo u LiteLLM. Podle technických stop, které vyšetřovatelé složili, útočníci nejprve kompromitovali široce používaný skener zranitelností Trivy a využili tento odrazový bod k otravě souvisejících projektů, jako jsou KICS a Telnyx Python SDK. Odtud se infikovaný řetězec rozšířil do vydaných balíčků LiteLLM.

Autorství operace přihlásila skupina nazvaná TeamPCP. Více nezávislých bezpečnostních týmů potvrdilo vzorec útoku a časovou osu, takže je málo pochybností o tom, že šlo o koordinovanou kampaň proti dodavatelskému řetězci, nikoli o izolovaný exploit.

Koho to zasáhlo? Únik je rozsáhlý. V zveřejněných datech se objevují technologičtí giganti a firmy z kritické infrastruktury: Nvidia, Amazon Web Services, Samsung, Cisco, Siemens, Volkswagen, Reuters, FedEx, Epic Games, X (dříve Twitter), HP, Philips a Deutsche Bank patří mezi společnosti, jejichž odhalené klíče byly s vysokou důvěrou potvrzeny.

Proč to mělo takový rozsah? Protnuly se dva faktory: spěch při nasazování nástrojů pro AI a křehký model důvěry v open-source dodavatelských řetězcích. Organizace, které se rychle snažily integrovat schopnosti AI, instalovaly knihovny a automatizační pipeline s minimálním auditingem. Tajemství uložená v proměnných prostředí nebo ponechaná v běžících build runnerech se stala snadným cílem.

Existuje také technický důvod, proč byl útok tak efektivní. Škodlivé sestavy LiteLLM spouštěly nástroj, který prohledával paměť a vyhazoval jakékoli přihlašovací údaje z RAM a odesílal je na sběrný server. To znamená, že i dočasné tokeny použité krátce během nasazení byly zachyceny. Krátkodobé neznamená bezpečné, když útočník může číst RAM.

Okamžitě zrušte platnost a vyměňte všechny odhalené klíče a tokeny.

Tento jednoduchý příkaz bezpečnostní týmy nyní opakují. Remediace je ale složitá. Protože bylo mnoho uniklých tajemství pozorováno bez doménových štítků nebo identifikátorů organizací, obránci čelí bolestivému inventárnímu úkolu: identifikovat, které klíče vytvořily které služby, a pak je zrušit, vyměnit a přenastavit. Pro mnoho inženýrských týmů to znamená přestavět CI/CD runnery, nahradit zabudovaná tajemství krátkodobými pověřeními a nasadit nástroje pro skenování tajemství, které vlaje úniky dříve, než se dostanou do produkce.

Poučení jsou jasná a tvrdá. Zaprvé, původ závislostí má význam. Spěch při instalaci pohodlných knihoven bez ověření kontrolních součtů a identity vydavatele vytváří riziko dodavatelského řetězce. Zadruhé, tajemství by neměla žít v prostém textu v proměnných pipeline nebo v dlouhodobých tokenech. Používejte krátkodobé identitní služby a přístup založený na pracovních úlohách, kde je to možné. Zatřetí, open-source ekosystém potřebuje silnější zábrany: reprodukovatelné sestavení, podepsané balíčky a lepší hygienu vydavatelů zmírní tuto třídu útoků.

Pro organizace používající LiteLLM nebo jakékoli propojené nástroje by okamžité kroky měly zahrnovat:

• Proveďte inventuru všech přihlašovacích údajů a tokenů, které mohly být načteny do paměti během buildu nebo běhu.
• Zrušte platnost a vyměňte tyto klíče a vydávejte nové pověření s minimálními oprávněními.
• Proveďte audit CI/CD pipeline a nahraďte všechna tajemství v prostém textu krátkodobými tokeny spravovanými v trezoru.
• Ověřujte integritu balíčků kontrolou kontrolních součtů a upřednostňováním podepsaných vydání od důvěryhodných správců.
• Monitorujte neobvyklý odchozí provoz z build infrastruktury, který by mohl naznačovat přetrvávající zadní vrátka.

Útok je varováním. Integrace nástrojů pro AI může přinést velké produktivní zisky. Ale když rychlost předběhne bezpečnost, následky nejsou teoretické. Přihlašovací údaje jsou měna. Jakmile uniknou, umožňují eskalaci práv, boční pohyby a krádež dat ve velkém měřítku. Týmy musí předpokládat, že kompromitace je možná, a budovat systémy, které minimalizují, co útočník může získat během jedné relace.

Očekávejte podrobnější zveřejnění od bezpečnostních firem, jak budou nadále zpracovávat 195terabajtový soubor a mapovat postižené organizace. Prozatím je nejbezpečnější postoj rychlá, koordinovaná rotace klíčů spojená s forenzním přezkumem build a nasazovacích procesů.