LiteLLM-pakkeangreb udløste massivt datatyveri og lækager

40 minutter. Det var alt, hvad det tog i marts for angribere at forvandle rutinemæssige pakkenedlastninger til et massivt datatyveri.

Udviklere og ingeniører, der troede, de hentede legitime udgivelser af open-source AI-integrationsbiblioteket LiteLLM (versioner 1.82.7 og 1.82.8), hentede i stedet kode gennemsyret af en hukommelsesskrabende bagdør. Når den blev kørt, gennemsøgte den ondsindede payload systemets RAM, indsamlede hemmeligheder fundet dér og streamede dem til servere kontrolleret af angriberne. Resultatet: mange terabytes følsomt materiale eksfileret fra nogle af verdens største virksomheder.

Hvordan et pakkecompromise blev en global forsyningskædekatastrofe

Sikkerhedsforskere fandt senere et lager på i alt cirka 195 terabyte. Indenfor var cloud-adgangsnøgler, token til containerregistre, SSH-nøgler og aktive databaseadgangskoder knyttet til mere end 2.500 organisationer. Datasættet indeholdt også legitimationsoplysninger fra over 434.000 CI/CD-pipelineindgange, mange eksponeret på grund af for lempelige offentlige pipelinekonfigurationer. Kort sagt: når legitimationsoplysninger befandt sig i hukommelsen eller i pipeline-variabler, var de i fare.

Indbruddet startede ikke hos LiteLLM. Ifølge de tekniske spor, efterforskere har samlet, kompromitterede angriberne først en bredt anvendt sårbarhedsscanner, Trivy, og brugte det fodfæste til at forgifte tilknyttede projekter som KICS og Telnyx Python SDK. Derfra spredte den forgiftede kæde sig ind i de frigivne LiteLLM-pakker.

Operationens tilskrivning er blevet påstået af en gruppe, der kalder sig TeamPCP. Flere uafhængige sikkerhedsteams har bekræftet angrebsmønstret og tidslinjen, hvilket efterlader få tvivl om, at dette var en koordineret forsyningskædekampagne fremfor et isoleret exploit.

Hvem blev ramt? Udbredelsen er stor. Teknologigiganter og kritiske infrastrukturvirksomheder optræder i afsløringerne: Nvidia, Amazon Web Services, Samsung, Cisco, Siemens, Volkswagen, Reuters, FedEx, Epic Games, X (tidligere Twitter), HP, Philips og Deutsche Bank er blandt de virksomheder, hvis eksponerede nøgler er bekræftet med høj grad af sikkerhed.

Hvorfor eskalerede dette så hurtigt? To faktorer gik sammen: en forhastet adoption af AI-værktøjer og en skrøbelig tillidsmodel i open-source-forsyningskæden. Organisationer ivrige efter at integrere AI-funktioner installerede biblioteker og automatiserede pipelines med minimal audit. Hemmeligheder gemt i miljøvariabler eller efterladt i build-runnere blev lette mål.

Der er også en teknisk forklaring på, at angrebet var så effektivt. De ondsindede LiteLLM-builds kørte en hukommelsesskraber, der dumpede alle legitimationsoplysninger i hukommelsen og sendte dem til en indsamler. Det betyder, at selv kortvarige tokens, der blev brugt under deployment, blev fanget. Ephemeral er ikke det samme som sikkert, når en angriber kan læse RAM.

Ophæv og roter straks alle eksponerede nøgler og tokens.

Det er den eneste befaling, sikkerhedsteams gentager nu. Men udbedring er besværlig. Fordi mange lækkede hemmeligheder blev observeret uden domænelabels eller organisationsidentifikatorer, står forsvarere over for en smertefuld opgave med inventar: identificer hvilke nøgler der blev oprettet af hvilke tjenester, og ophæv, roter og rekonfigurer dem. For mange udviklingsteams betyder det genopbygning af CI/CD-runnere, udskiftning af indlejrede hemmeligheder med kortlivede legitimationsoplysninger og implementering af secret-scanning-værktøj, der markerer læk, før de når produktion.

Lektionerne er klare og barske. For det første betyder afhængighedsoprindelse noget. At skynde sig at installere bekvemmelighedsbiblioteker uden at verificere checksums og udgiveridentiteter skaber forsyningskæderisiko. For det andet bør hemmeligheder ikke ligge i klartekst i pipeline-variabler eller som langtlevende tokens. Brug kortlivede serviceidentiteter og workload-baseret adgang hvor muligt. For det tredje har open-source-økosystemet brug for stærkere beskyttelsesforanstaltninger: reproducerbare builds, signerede pakker og bedre udgiverhygiejne vil dæmpe denne type angreb.

For organisationer, der bruger LiteLLM eller andre tilknyttede værktøjer, bør øjeblikkelige skridt omfatte:

• Lav en inventarliste over alle legitimationsoplysninger og tokens, der kan være blevet indlæst i build- eller runtime-hukommelsen.
• Ophæv og roter disse nøgler, og udsted nye legitimationsoplysninger med mindst-mulig-privilegium.
• Revider CI/CD-pipelines og erstat eventuelle klarteksthemmeligheder med vault-baserede kortlivede tokens.
• Valider pakkeintegritet ved at tjekke checksums og foretrække signerede udgivelser fra betroede maintainere.
• Overvåg for unormal udgående trafik fra build-infrastrukturen, som kan indikere tilbageværende bagdøre.

Angrebet er en advarsel. Integration af AI-værktøjer kan give store produktivitetsgevinster. Men når hastighed løber fra sikkerhed, er konsekvenserne ikke teoretiske. Legitimationsoplysninger er valuta. Når de først er lækket, muliggør de eskalering, lateral bevægelse og datatyveri i stor skala. Teams må antage, at kompromittering er mulig og bygge systemer, der minimerer, hvad en angriber kan tilegne sig i én session.

Forvent mere detaljeret offentliggørelse fra sikkerhedsfirmaer, mens de fortsætter med at gennemgå det 195-terabyte store materiale og kortlægge berørte organisationer. For nu er den sikreste holdning hurtig, koordineret nøglerotation kombineret med en retsmedicinsk gennemgang af build- og deploy-processer.