LiteLLM-versjon med skadevare stjal nøkler: bytt hemmeligheter hvis dere installerte 1.107.0
En angriper fikk publisert LiteLLM 1.107.0 med skadevare som stjeler legitimasjon. Pakken lå ute i rundt to timer 21. oktober. LiteLLM ber berørte behandle miljøet som kompromittert og bytte alle nøkler.
LiteLLM, en mye brukt åpen kildekode-gateway for språkmodeller, ble rammet av et angrep på leverandørkjeden onsdag 21. oktober. En angriper fikk publisert versjon 1.107.0 med skadevare som stjeler legitimasjon og laster inn verktøy for fjernstyring. Ifølge selskapet lå den skadelige pakken ute på PyPI i rundt to timer, og forgiftede Docker-bilder var tilgjengelige litt lenger.
For ledere er konsekvensen enkel å formulere. LiteLLM sitter ofte mellom interne systemer og modelleverandører som OpenAI, Anthropic og Google, og har derfor tilgang til API-nøkler og andre hemmeligheter. Har en virksomhet installert eller startet den berørte versjonen, ber LiteLLM selv om at miljøet behandles som kompromittert og at nøklene byttes.
Hva som skjedde
LiteLLM publiserte en hendelsesrapport på sin egen blogg 21. oktober, signert av blant andre administrerende direktør Krrish Dholakia og sikkerhetsdirektør Oliver Jensen. Siste oppdatering vi leste, var datert samme dag klokken 22.30 norsk tid. Status var da at hendelsen var under kontroll, men at etterforskningen pågikk.
Ifølge rapporten lå sju skadelige pakker av litellm 1.107.0 på PyPI fra klokken 13.39 til 15.23 norsk tid. På Docker Hub pekte taggene v1.107.0, latest, main-latest og main-stable til et kompromittert bilde fra 13.46 til 16.20. På GitHubs containerregister var de samme taggene berørt til 15.51. Selskapet skriver at den offisielle kildekoden for 1.107.0 på GitHub ikke inneholder de skadelige filene. Pakkene ble bygget fra et lagringssted angriperen kontrollerte, med et navn som lignet det ekte.
LiteLLM oppgir at kunder som bruker selskapets private enterprise-utgave, ikke er rammet.
Slik kom angriperen inn
Rapporten beskriver en kjede av svikt, ikke én enkelt feil. LiteLLM hadde strammet inn utgivelsesløpet etter en tidligere hendelse i mars. Mandag samme uke utvidet selskapet midlertidig utgivelsesrettighetene, slik at to ingeniører kunne publisere daglige feilrettinger til kunder.
Angriperen hadde ifølge LiteLLM tilgang til tre sett med GitHub CLI-legitimasjon fra utviklere. Én av dem tilhørte en eier av GitHub-organisasjonen. Med den ble grenbeskyttelsen slått av, og en endret arbeidsflyt pekte utgivelsen mot den falske kodebasen. En tredje konto ble brukt til å slette loggene fra arbeidsflyten, noe som begrenser etterforskningen.
LiteLLM skriver også at selskapet har observert tilfeller der Claude Code legger en brukers GitHub CLI-token inn i et svar, og at slike tokens kan havne i LiteLLM-logger når svar logges. Selskapet mener angriperen kom seg inn i en intern LiteLLM-installasjon som var eksponert mot internett, og hentet tokens fra loggene der. Hvordan angriperen fikk tilgang, er ikke bekreftet. LiteLLM mistenker en nylig rettet sårbarhet. Dette er selskapets egne funn og vurderinger, og de er ikke uavhengig verifisert.
Hva berørte virksomheter må gjøre
LiteLLM sier at virksomheter er berørt hvis de installerte en ulåst versjon via pip i tidsrommet for PyPI, eller startet de nevnte Docker-bildene i tidsrommet for registrene. Selskapet anbefaler å låse versjonen til 1.106.2 eller en annen eksplisitt eldre versjon.
Rådene i rapporten er konkrete. Ikke start med å kjøre pip install i et berørt miljø, fordi enhver Python-oppstart kjører skadevaren på nytt. Fjern de skadelige filene, stopp prosessen den startet, og bygg helst miljøer og bilder på nytt fra bunnen. Har en maskin med utgående internettilgang hatt 1.107.0 installert, skal virksomheten anta at data er sendt ut.
Deretter må alt maskinen kunne nå, byttes. LiteLLM nevner særlig IAM-rollen til instansen, alle leverandørnøkler lagret i LiteLLM-proxyens database, hoved- og virtuelle nøkler, databasepassordet og alle hemmeligheter i miljøet til prosessene på maskinen.
Hva norske ledere bør spørre om nå
Det første spørsmålet er om LiteLLM brukes, også i eksperimenter og interne verktøy. Det er ofte utviklingsmiljøer som henter siste versjon automatisk. Det andre er om noen henter tagger som latest i drift, i stedet for faste versjoner. Det var nettopp slike oppsett som ble rammet.
Det tredje gjelder logging. Ifølge LiteLLMs egen forklaring havnet utviklertokens i logger fra en KI-gateway. Logger fra slike systemer kan derfor inneholde mer enn ledelsen tror, og bør beskyttes som hemmeligheter.
LiteLLM opplyser også at en annen sårbarhet er rettet i en hemmeligholdt utgave til enterprise-kunder, med planlagt offentliggjøring 27. oktober. Virksomheter som bruker åpen kildekode-utgaven, bør følge med på den datoen.
hogby.ai har ikke selv undersøkt pakkene. Tallene og tidspunktene over er hentet fra LiteLLMs rapport.
Kilder og medier
Kilde: LiteLLM.
Illustrasjon: KI-generert med Grok Bot / hogby.ai
