Samme dag ble LiteLLM forgiftet og Railway brutt, begge etter nøklene

Onsdag dukket LiteLLM 1.107.0 opp på PyPI, pakkeregisteret for Python. Versjonen så ut som en vanlig oppdatering av verktøyet som lar utviklere snakke med over hundre KI-modeller gjennom ett felles grensesnitt, men ifølge sikkerhetsselskapet SafeDep inneholdt den et program som samler SSH-nøkler, skylegitimasjon og nøklene til KI-leverandørene, pluss en bakdør som henter ny kode hver time. Samme dag meldte hostingtjenesten Railway at en uvedkommende kan ha fått tak i kundenes miljøvariabler, stedet der utviklere legger passord og API-nøkler.

Ingen har vist at de to sakene henger sammen. Railway skriver selv at bruddet er en del av en serie angrep mot plattformselskaper, med mål om å komme til leverandører av KI-drift, men det er selskapets egen vurdering, og den er ikke bekreftet utenfra. Det som er felles, er målet: en nøkkel til en KI-modell er penger, for den som har den, kan bruke modellen på andres regning. Sikkerhetsbildet har vært urolig i hele oktober, fra en åpen KI-agent som ble mistenkt for angrep på sju koreanske finansselskaper til Anthropics varsel om små modeller som kan spre seg mellom TV-bokser.

Under to timer på PyPI kan være nok til en kvart million nedlastinger

LiteLLM er et av de mest brukte leddene i KI-stakken. Bloggen Redreamality, som har satt opp tidslinjen for hendelsen, siterer Datadog på rundt 23 millioner nedlastinger i uka. Samme blogg skriver at den forgiftede versjonen lå ute i 1 time og 43 minutter på PyPI og i omtrent to og en halv time som offisielt Docker-bilde, mens SafeDep peker på at den ble bygget utenfor det offentlige kodelageret, noe som tyder på en kompromittert byggeprosess eller stjålet PyPI-tilgang. Hvordan det skjedde, er ikke bekreftet.

Et grovt regnestykke viser hvorfor det korte vinduet ikke trøster. Med 23 millioner i uka blir det rundt 137 000 nedlastinger i timen, og under to timer gir da i størrelsesorden 235 000, forutsatt jevn trafikk. Mange av dem er automatiske bygg som henter siste versjon uten at noen ser på det, og tyvprogrammet kjører hver gang Python starter, ikke bare når pakken brukes. Tallet er vårt eget anslag og forteller ikke hvor mange som faktisk ble rammet, men det viser hvorfor Redreamality anbefaler å vente noen dager med nye versjoner.

Railway sier ikke hvor mange kunder som er rammet

Railway oppdaget unormal aktivitet i systemene som lagrer miljøvariabler onsdag morgen. Selskapet skriver at krypterte variabler kan være lest, at innholdet er dekryptert for noen, og at det kan gjelde API-nøkler, databasepassord og tilgang til containerregistre. Alle utrullinger er stanset mens saken undersøkes, og alle kunder bes bytte alt som ligger lagret hos Railway.

Det Railway ikke sier, er viktigere for den som må vurdere skaden: hvor mange kontoer som er rammet, hvilket lager angriperen kom inn i, og hvordan krypterte verdier kunne dekrypteres. Selskapet mener påvirkningen kan være begrenset til en undergruppe, men anbefaler likevel alle å bytte. For norske virksomheter er det mer enn en teknisk rutine. Ligger det personopplysninger bak en stjålet databasenøkkel, kan bruddet utløse meldeplikt til Datatilsynet innen 72 timer etter at virksomheten ble kjent med det, og det er virksomheten selv som er behandlingsansvarlig, ikke Railway.

KI finner hullene på dager, men PHP brukte 58 dager på å rette dem

Det tredje tilfellet viser hvor ujevn farten er. Sikkerhetsselskapet Wiz fant to kritiske feil i PHP, språket bak store deler av nettet, med hjelp av KI-modeller fra blant andre Google og OpenAI. Den første ble funnet 19. august, og to dager senere hadde Wiz bekreftet at den kunne brukes til å ta over en WordPress-installasjon uten innlogging. PHP ble varslet 24. august og ga ut rettelser først 21. oktober, 58 dager senere.

Før rettelsene kom, ble opplysninger om feilene lagt ut på nettet, uten teknisk oppskrift, skriver SecurityWeek. Benjamin Harris, sjef i sikkerhetsselskapet WatchTowr, bekrefter at feilene er ekte, og Sansec ventet masseutnyttelse innen et kvarter etter at rettelsen ble sluppet. Den ene feilen kan lekke minne fra serveren, med passord, tokens og API-nøkler, så også her handler det til slutt om nøkler.

Smale nøkler og ventetid avgjør hvem som slipper billig unna

De tre sakene har ulike innganger: en pakke, en hostingplattform og en webserver. Felles er at tilgangen til KI-modellene ofte ligger samlet på få steder, med bred rekkevidde og lang levetid. Team som bruker én hovednøkkel per miljø og kjører alt gjennom én LiteLLM-server, har mest å tape. Team med én nøkkel per app, utgiftstak hos leverandøren og noen dagers ventetid på nye versjoner, mister en liten del.

Tre ting bør følges de nærmeste dagene: Railways oppfølging med antall rammede kontoer og en forklaring på hvordan verdier kunne dekrypteres, LiteLLMs gjennomgang av hvordan versjonen kunne bygges utenfor det offentlige kodelageret, og om overvåkere ser utnyttelse av PHP-feilene i stor skala. Så langt er ingen av dem besvart i det som er publisert.

Det er ikke første gang for LiteLLM: ifølge Redreamality lå to andre versjoner forgiftet i omtrent 40 minutter i mars.