LiteLLM traceert besmette release naar masterkeylek

LiteLLM meldt op 23 oktober dat een op 27 mei openbaar geworden, niet-ingetrokken Agent Platform-masterkey op 10 oktober een GitHub-ownertoken opleverde en de weg vrijmaakte voor de besmette release 1.107.0.

Bij een Python-start kon de besmette release model-, cloud- en CI-tokens uit de omgeving verzamelen en een trojan voor toegang op afstand (RAT) starten; Microsoft zegt dat de payload zonder LiteLLM-import bij een Python-start draaide en dat het niet zelfstandig de eerste toegang heeft vastgesteld. Voor teams die deze versie draaiden, omvat het onderzoek nu ook de interne toegangsketen: een openbare sleutel in een agentplatform leidde naar organisatiebrede GitHub-rechten en uiteindelijk de productiegoedkeuring.

Een achtergebleven sleutel gaf toegang tot GitHub

Op 27 mei belandde een configuratiebestand met de masterkey van het LiteLLM Agent Platform per ongeluk in de publieke repository LiteLLM-Labs/lite-harness. Het project zegt dat het de fout snel opmerkte en de commit force-pushte, maar dat maakte de sleutel niet ongeldig. De blootgestelde sleutels moesten worden ingetrokken; de masterkey bleef geldig. Het platform was een interne proefdienst waarmee zelf beheerde agents pull requests naar GitHub-repositories konden openen.

Op 10 oktober, ruim vier maanden later, gebruikte de aanvaller die sleutel om de Agent Platform-API aan te roepen. Op 10 oktober gaf een verzoek de configuratie van alle beheerde agents terug, met daarin een GitHub CLI OAuth-token van een organisatie-eigenaar. Het was geen serviceaccount en niet beperkt tot enkele repositories: LiteLLM zegt dat de token toegang op eigenaarsniveau gaf tot alle repositories. GitHub CLI-tokens zijn na tweestapsverificatie uitgegeven, maar vallen niet onder de extra herauthenticatie voor gevoelige beheerdersacties.

Korte workflows leverden twee maintainer-tokens

Met de owner-token voegde de aanvaller op 10 oktober workflows toe aan tijdelijke branches van BerriAI/litellm en BerriAI/litellm-auto. De eerste stuurde zes geheimen, waaronder GH_TOKEN van een tweede maintainer, naar een aanvallersadres op webhook.site. Vierentwintig seconden later volgde RELEASE_PLEASE_TOKEN, gekoppeld aan een derde maintainer. De branches en workflowruns verdwenen binnen minuten.

LiteLLM koppelt de hash van GH_TOKEN aan de token die later de productiepublicatie goedkeurde; RELEASE_PLEASE_TOKEN komt overeen met de token die de runlogs verwijderde. Op 12 oktober volgde geheimendiefstal in diverse private repositories. LiteLLM zegt dat de extra test- en providerkeys geen rol speelden bij de vergiftigde release en daarna zijn geroteerd.

Socket vond twee kwaadaardige commits van 10 en 12 oktober in GitHub Actions-gegevens. De onderzoekers waarschuwen dat een geslaagde workflowrun niet bewijst dat de geheimen ook zijn verzonden. Beide tijdelijke branches waren binnen minuten verwijderd.

De aanvaller verlegde de bron van de release

Op 21 oktober wees een aanvallerwijziging in BerriAI/project-releaser de bouw naar de gelijkende repository Berri-AI/litellm. Een eerdere push met een maintainer-token was afgewezen omdat GitHub een pull request, twee controles en goedkeuring van de code-eigenaar eiste. Vijf seconden later zette de owner-token branchbescherming uit en force-pushte de wijziging.

Alle tijden zijn UTC: de staging-bouw begon om 10.46, de productiepublicatie om 11.08. Om 11.11 keurde de tweede maintainer-token de productiepoort goed. Zeven PyPI-wheels werden tussen 11.39 en 11.40 gepubliceerd, gevolgd door Docker Hub- en GitHub Container Registry (GHCR)-images om 11.46. Om 11.53 verwijderde de derde token de runlogs. Om 12.24 force-pushte de owner-token main terug naar een eerdere commit, waardoor zowel de wijziging als de terugdraaiing uit de zichtbare geschiedenis verdwenen.

Normaal startte een geautoriseerde engineer de release en keurde een speciale account, vergrendeld op een fysiek apparaat op kantoor, hem goed. Die eis was eerder die week tijdelijk teruggebracht tot twee engineers voor vaker releasen en het terugzetten van foutoplossingen. LiteLLM schrijft dat de owner-token de bescherming zelf had kunnen verlagen; vermoedelijk gebruikte de aanvaller aparte maintainer-tokens om minder op te vallen in auditlogs. De aanvaller gebruikte de versoepelde goedkeuring, maar had met de owner-token ook branchbescherming kunnen uitschakelen.

De nieuwe oorzaak verandert het herstelonderzoek

In een afzonderlijke GhostAction-golf werden tussen 8 en 12 oktober meer dan 30.000 repositories bij circa 3.000 gebruikers en organisaties doelwit; de aanvallers probeerden 3.174 CI-geheimen te stelen. Er is geen verband met LiteLLM aangetoond; hier leidde workflowdiefstal wel tot een pakketpublicatie.

In juli waarschuwde de FBI voor TeamPCP, dat LiteLLM en Trivy via softwareketenaanvallen had aangepast; de aanbevelingen omvatten beperkte CI-tokens en een wachttijd van zeven dagen voor nieuwe pakketten. Die TeamPCP-aanval op LiteLLM en Trivy liep via softwaredistributie; in deze zaak zat de ingang in een sleutel voor een agentdienst. Een pakketwachttijd kan een verse besmette release vertragen, maar maakt een eerder gelekte owner-token niet ongeldig.

LiteLLM noemt de reconstructie van 23 oktober de canonieke tijdlijn. Daarmee vervangt het de eerste hypothese dat GitHub-tokens uit logs van een interne LiteLLM-installatie waren buitgemaakt. Het verband tussen GH_TOKEN en de productiegoedkeuring komt uit LiteLLM’s eigen auditlog. De technische analyse van Microsoft gaat over de schadelijke payload; de oorzaak van de eerste toegang komt uit de reconstructie van LiteLLM.

Voor organisaties die agents aan GitHub koppelen, raakt deze zaak aan de identiteit die de agent gebruikt en de reikwijdte van die token. De tijdlijn loopt van een openbare configuratie via een Agent Platform-API en twee CI-workflows naar een publicatiepoort. LiteLLM zegt alle mogelijk bereikbare tokens te herroepen en belooft volgende week procesverbeteringen te delen; de analyse specificeert die permanente wijzigingen nog niet.