LiteLLM 1.107.0 stal API-sleutels en SSH-keys

Van LiteLLM, de veelgebruikte open source gateway die één API-interface legt over OpenAI, Anthropic, Gemini en tientallen andere aanbieders, is één release besmet geweest. Versie 1.107.0 op PyPI bevatte een credential stealer en een remote access trojan. PyPI heeft de versie inmiddels verwijderd en de Docker-images zijn teruggedraaid, maar wie 1.107.0 heeft geïnstalleerd moet ervan uitgaan dat zijn secrets weg zijn.

Wat er precies in zat

Het onderzoeksteam van Upwind documenteerde de vondst in een issue in de LiteLLM-repository. Alle zeven wheels van 1.107.0 bleken drie extra bestanden te bevatten die pip rechtstreeks in de hoofdmap van site-packages neerzet: cook.pth, cook.py en sitecustomize.py.

Die eerste is het mechanisme. Een .pth-bestand wordt door Python bij elke interpreterstart ingelezen, en dit bestand bevat niets anders dan import cook. Daarmee loopt de stealer in cook.py bij iedere Python-start in die omgeving, zonder dat iemand LiteLLM hoeft aan te roepen. sitecustomize.py wordt om dezelfde reden automatisch uitgevoerd en start een losgekoppelde daemon die elk uur bij de infrastructuur van de aanvaller nieuwe commando's ophaalt.

De stealer harkt breed: opgeslagen en ontsleutelde wachtwoorden en cookies uit Chromium-browsers, logins.json en key4.db van Firefox, de inhoud van ~/.ssh/, shell- en databasehistorie, en de credentials van AWS, Azure, gcloud, kubectl, Docker, de GitHub CLI, rclone en .netrc. Volgens The Register horen daar ook de API-sleutels van de LLM-aanbieders zelf bij. De buit gaat versleuteld via een HTTP-POST naar een domein dat op een healthcheck-endpoint lijkt.

Pijnlijk detail: de payload zat niet in de git-tag van 1.107.0. Hij is tussen het uitchecken en het bouwen in de build-boom gezet, via een toegevoegde regel data = "cook" in pyproject.toml. De release werd volgens Upwind gebouwd uit Berri-AI/litellm, een repository waarvan de naam één streepje verschilt van de echte organisatie BerriAI. Hoe de buildomgeving of het PyPI-token is gecompromitteerd, is niet bekend.

Waarom dit breder telt dan LiteLLM

Een LLM-gateway staat op precies de verkeerde plek om bestolen te worden. Het is het ene proces in je omgeving dat de sleutels van al je modelaanbieders kent, meestal naast een databasewachtwoord en een cloud-identiteit. Eén besmette container in een CI-runner levert zo in één keer de hele sleutelbos op. LiteLLM werd volgens The Register in maart al eens langs deze weg geraakt.

Wat je nu kunt doen

De veilige versie is 1.106.2; dat is op het moment van schrijven ook de nieuwste release op PyPI. Upwind adviseert verder:

Begin niet met pip install. Elke Python-start in een besmette omgeving voert de payload opnieuw uit, en dat geldt ook voor pip zelf.
Verwijder vanuit de shell cook.pth, cook.py, sitecustomize.py en de bijbehorende __pycache__-bestanden uit élke getroffen site-packages, en beëindig de daemon die /tmp/remote_code_loader.lock vasthoudt.
Bestaat /tmp/.pc_once_*, dan is de exfiltratie zeker gelukt. Bestaat het niet, dan bewijst dat niets: containers en tmp-opruiming wissen het bestand.
Bouw images en virtualenvs liever opnieuw op dan dat je ze repareert, en pin daarbij litellm==1.106.2.
Roteer wat de host kon bereiken: de IAM-rol van de instance, álle aanbieder-sleutels in de LiteLLM-proxydatabase inclusief de master- en virtual keys, het wachtwoord in DATABASE_URL en elk secret dat in de omgeving van een proces op die host stond.