Massivt globalt dataintrång via AI-paket: LiteLLM-läckage

Fyrtio minuter. Det var allt som krävdes i mars för att angripare skulle förvandla rutinmässiga paketnedladdningar till en massiv datastöld.

Utvecklare och ingenjörer som laddade ner vad de trodde var legitima utgåvor av open-source AI-integrationsbiblioteket LiteLLM (versionerna 1.82.7 och 1.82.8) hämtade istället kod full av en minnesskrapande bakdörr. När den kördes genomsökte den skadliga nyttolasten systemets RAM, samlade in hemligheter som fanns där och strömmade dem till servrar kontrollerade av angriparna. Resultatet: flera terabyte känsligt material exfiltrerades från några av världens största företag.

Hur ett paketkompromiss blev en global leveranskedjekatastrof

Säkerhetsforskare fann senare en cache som totalt uppgick till ungefär 195 terabyte. Inuti fanns molnåtkomstnycklar, containerregistertokens, SSH-nycklar och aktiva databaslösenord kopplade till mer än 2 500 organisationer. Datasetet innehöll också autentiseringsuppgifter från över 434 000 CI/CD-pipelineposter, många exponerade på grund av tillåtande offentliga pipelinekonfigurationer. Kort sagt: när autentiseringsuppgifter levde i minnet eller i pipelinevariabler var de i riskzonen.

Intrånget började inte hos LiteLLM. Enligt de tekniska spår utredarna satte ihop komprometterade angripare först en brett använd sårbarhetsskanner, Trivy, och använde detta fotfäste för att förgifta relaterade projekt såsom KICS och Telnyx Python SDK. Därifrån spreds den förgiftade kedjan in i LiteLLM:s utgivna paket.

Attribution av operationen har påståtts av en grupp som kallar sig TeamPCP. Flera oberoende säkerhetsteam har bekräftat angreppsmönstret och tidlinjen, vilket lämnar liten tvivel om att detta var en koordinerad leveranskedjekampanj snarare än ett isolerat utnyttjande.

Vem drabbades? Utsläppet är omfattande. Teknikjättar och företag inom kritisk infrastruktur dyker upp i avslöjandena: Nvidia, Amazon Web Services, Samsung, Cisco, Siemens, Volkswagen, Reuters, FedEx, Epic Games, X (tidigare Twitter), HP, Philips och Deutsche Bank är bland de företag vars exponerade nycklar har bekräftats med hög tilltro.

Varför eskalerade detta så snabbt? Två faktorer korsade varandra: en våg av snabb adoption av AI-verktyg och en bräcklig förtroendemodell i open-source-leveranskedjor. Organisationer som snabbt ville integrera AI installerade bibliotek och automationspipelines med minimal granskning. Hemligheter som hängde kvar i miljövariabler eller i byggkörningar blev lätta byten.

Det finns också ett tekniskt skäl till att angreppet var så effektivt. De skadliga LiteLLM-byggarna körde en minnesskrapa som dumpade alla autentiseringsuppgifter i minnet och skickade dem till en insamlare. Det innebär att även kortlivade tokens som användes under deployment fångades. Kortlivat betyder inte säkert när en angripare kan läsa RAM.

Återkalla och rotera alla exponerade nycklar och tokens omedelbart.

Det är den uppmaning som säkerhetsteam nu upprepar. Men sanering är komplicerad. Eftersom många läckta hemligheter observerades utan domänetiketter eller organisationsidentifierare står försvararna inför en smärtsam inventeringsuppgift: identifiera vilka nycklar som skapats av vilka tjänster, för att sedan återkalla, rotera och omkonfigurera. För många ingenjörsteam innebär det att bygga om CI/CD-runners, ersätta inbäddade hemligheter med kortlivade behörigheter och införa verktyg för hemlighetsskanning som flaggar läckor innan de når produktion.

Lärdomarna är tydliga och hårda. För det första spelar beroendeursprung roll. Att skynda sig att installera bekvämlighetsbibliotek utan att verifiera checksummor och utgivaridentiteter skapar risk i leveranskedjan. För det andra bör hemligheter inte lagras i klartext i pipelinevariabler eller som långlivade tokens. Använd kortlivade tjänsteidentiteter och arbetsladsbaserad åtkomst där det är möjligt. För det tredje behöver open-source-ekosystemet starkare säkerhetsstaket: reproducerbara byggen, signerade paket och bättre utgivarhygien kommer att dämpa den här typen av attacker.

För organisationer som använder LiteLLM eller relaterade verktyg bör omedelbara åtgärder inkludera:

• Inventera alla autentiseringsuppgifter och tokens som kan ha laddats in i bygg- eller körminne.
• Återkalla och rotera dessa nycklar, och utfärda nya autentiseringsuppgifter med minsta nödvändiga behörighet.
• Granska CI/CD-pipelines och ersätt eventuella klartexthemligheter med kortlivade token som lagras i en vault.
• Verifiera paketintegritet genom att kontrollera checksummor och föredra signerade releaser från betrodda underhållare.
• Övervaka för onormal utgående trafik från bygginfrastruktur som kan indikera kvarvarande bakdörrar.

Angreppet är en väckarklocka. Att integrera AI-verktyg kan ge stora produktivitetsvinster. Men när snabbhet går före säkerhet blir konsekvenserna verkliga. Autentiseringsuppgifter är valuta. När de väl läcker möjliggör de eskalering, laterala rörelser och datastöld i stor skala. Team måste anta att kompromiss är möjlig och bygga system som minimerar vad en angripare kan fånga under en session.

Räkna med mer detaljerade redogörelser från säkerhetsföretag när de fortsätter analysera den 195-terabyte stora troven och kartlägga påverkade organisationer. För nu är den säkraste hållningen snabb, koordinerad nyckelrotation i kombination med en forensisk översyn av bygg- och distributionsprocesser.