40 minutter på PyPI: LiteLLM-angrepet rammet 2500 selskaper

Nesten ingen skriver all koden sin selv. Trenger du å snakke med en AI-modell, hente ut data fra en fil eller sende en e-post fra programmet ditt, henter du ned en ferdig pakke andre har skrevet. Én kommando, og biblioteket ligger i prosjektet.

For programmeringsspråket Python foregår den nedlastingen fra PyPI, det offisielle pakkeregisteret. Der ligger over 870 000 prosjekter fritt tilgjengelig, et tall som vokser for hver dag. Registeret sjekker ikke innholdet i pakkene som lastes opp.

LiteLLM er en av dem. Programvaren lar utviklere nå mange ulike AI-modeller gjennom ett og samme grensesnitt, slik at koden ikke må skrives om hver gang selskapet bytter fra OpenAI til Anthropic eller Google. Det gjør den til et naturlig sted å oppbevare nøklene til alle sammen.

I mars lå to forgiftede versjoner av LiteLLM, 1.82.7 og 1.82.8, ute på PyPI i rundt 40 minutter.

2500 selskaper på listen

Sikkerhetsselskapet CloudSEK har nå kartlagt hvem som rakk å hente dem ned. LiteLLM-angrepet knyttes til mer enn 2500 organisasjoner og 434 000 CI/CD-pipeliner. På listen står Amazon Web Services, Nvidia, Samsung Electronics, Cisco, Salesforce, ServiceNow, Volkswagen, X Corp og Zscaler.

Eksponering er ikke det samme som innbrudd. At en pakke ble hentet ned i et bygg, beviser ikke at noen faktisk stjal noe fra akkurat den bedriften.

Hvorfor 40 minutter var nok

Førti minutter høres ut som ingenting, og det er nettopp poenget med å angripe leverandørkjeden istedet for målet.

Moderne utvikling er automatisert. Hver gang en utvikler sender inn en kodeendring, starter en byggekjede som henter ned alle avhengighetene på nytt, setter sammen programmet, kjører testene og legger resultatet ut. Kjeden går av seg selv, tusenvis av ganger i døgnet, også klokken tre om natten når ingen ser på.

Ligger den forgiftede pakken ute i det vinduet, installerer maskinene den lydig. Ingen leser koden. Det er hele grunnen til at automatiseringen finnes.

Hullet lå i sikkerhetsverktøyet

Angriperne, som CloudSEK kaller TeamPCP, gikk ikke løs på LiteLLM først. De kom inn i utgivelsesprosessen til Trivy, et verktøy som skanner kode og containere for kjente sårbarheter. Veien inn gikk altså gjennom sikkerhetsverktøyet.

En lekket automatiseringsnøkkel ga dem rundt tyve dager der de kunne dytte ondsinnet kode inn i Trivys utgivelser. LiteLLMs eget byggeoppsett installerte deretter Trivy uten å låse verktøyet til en verifisert versjon, og den forgiftede koden fikk dermed være med da LiteLLM selv ble bygget og lagt ut på PyPI.

Å låse en avhengighet til en bestemt, kontrollert versjon er standard råd og har vært det lenge. Det er den samme blinde tilliten GCC-prosjektet nylig strammet inn på fra motsatt kant, da de sa nei til AI-generert kode.

Nøklene virker fortsatt

Nyttelasten var bygget for å tømme utviklermaskiner og byggeservere for legitimasjon. Den samlet SSH-nøkler, tilgangsnøkler til AWS, Google Cloud og Azure, Kubernetes-tokener, .env-filer med hemmeligheter, og API-nøkler til AI-tjenester.

Slike nøkler er langlivede. De rulleres sjelden, de ligger ofte i flere systemer samtidig, og de gir tilgang uten at noen får et varsel om innlogging.

FBI advarte derfor i et FLASH-varsel 2. juli, referanse FLASH-20260702-01, om at aktører knyttet til gruppen sannsynligvis vil bruke de stjålne detaljene lenge etter selve innbruddet. Fem måneder etter de førti minuttene i mars dukker det fortsatt opp nye ofre.

Claude har bidratt i arbeidet med denne artikkelen.