LiteLLM-toeleveringsketen: 195 TB gelekte sleutels

Veertig minuten. Dat was in maart alles wat aanvallers nodig hadden om routinematige pakketdownloads om te zetten in een enorme gegevensroof.

Ontwikkelaars en engineers die dachten legitieme releases van de open-source AI-integratiebibliotheek LiteLLM (versies 1.82.7 en 1.82.8) te downloaden, haalden in plaats daarvan code binnen die was vervuild met een geheugen-scrapende achterdeur. Eenmaal uitgevoerd kroop de kwaadaardige payload door het systeem-RAM, verzamelde daar gevonden geheimen en streamde ze naar servers die door de indringers werden beheerd. Het resultaat: vele terabytes aan gevoelige informatie geëxfiltreerd van enkele van 's werelds grootste bedrijven.

Hoe een pakketcompromis uitgroeide tot een wereldwijde ramp in de toeleveringsketen

Onderzoekers op het gebied van beveiliging vonden later een cache van in totaal ongeveer 195 terabyte. Binnenin zaten cloudtoegangssleutels, tokens voor containerregistries, SSH-sleutels en actieve databasewachtwoorden gekoppeld aan meer dan 2.500 organisaties. De dataset bevatte ook referenties van meer dan 434.000 CI/CD-pijplijnvermeldingen, waarvan er veel blootgesteld waren door ruim toegestane openbare pijplijnconfiguraties. Kortom: zodra referenties in het geheugen of in pijplijnvariabelen terechtkwamen, waren ze kwetsbaar.

De inbraak begon niet bij LiteLLM. Volgens de technische sporen die onderzoekers hebben samengevoegd, compromitteerden aanvallers eerst een veelgebruikte kwetsbaarheidsscanner, Trivy, en gebruikten dat uitgangspunt om verwante projecten te vergiftigen, zoals KICS en de Telnyx Python SDK. Van daaruit verspreidde de geïnfecteerde keten zich naar de vrijgegeven pakketten van LiteLLM.

De toeschrijving van de operatie is opgeëist door een groep die zichzelf TeamPCP noemt. Meerdere onafhankelijke beveiligingsteams hebben het aanvalspatroon en de tijdlijn bevestigd, waardoor er weinig twijfel blijft dat dit een gecoördineerde campagne tegen de toeleveringsketen was in plaats van een geïsoleerd exploit.

Wie werd getroffen? De uitloop is groot. Technologiegiganten en bedrijven voor kritieke infrastructuur verschijnen in de openbaarmakingen: Nvidia, Amazon Web Services, Samsung, Cisco, Siemens, Volkswagen, Reuters, FedEx, Epic Games, X (voorheen Twitter), HP, Philips en Deutsche Bank behoren tot de bedrijven waarvan blootgestelde sleutels met hoge zekerheid zijn bevestigd.

Waarom escaleerde dit zo snel? Twee factoren kwamen samen: een haast om AI-tools te adopteren en een fragiel vertrouwensmodel in open-source toeleveringsketens. Organisaties die snel AI-capaciteiten wilden integreren installeerden libraries en automatiseringspijplijnen met minimale controle. Geheimen die in omgevingsvariabelen werden bewaard of achterbleven in build-runners werden makkelijk te plukken.

Er is ook een technische reden waarom de aanval zo efficiënt was. De kwaadaardige LiteLLM-builds voerden een geheugen-scraper uit die alle in-memory referenties dumpte en naar een collector stuurde. Dat betekent dat zelfs kortstondige tokens die tijdelijk tijdens deploys werden gebruikt, werden vastgelegd. Kortstondig betekent niet veilig wanneer een aanvaller het RAM kan uitlezen.

Trek alle blootgestelde sleutels en tokens onmiddellijk in en roteer ze.

Die ene dringende opdracht herhalen beveiligingsteams nu voortdurend. Maar herstel is rommelig. Omdat veel gelekte geheimen werden aangetroffen zonder domeinlabels of organisatie-identificatoren, staan verdedigers voor een pijnlijke inventarisatieuitdaging: vaststellen welke sleutels door welke services zijn aangemaakt, en die vervolgens intrekken, roteren en opnieuw configureren. Voor veel engineeringteams betekent dit CI/CD-runners herbouwen, ingebedde geheimen vervangen door kortstondige referenties, en secret-scanning tooling invoeren die lekken markeert voordat ze productie bereiken.

De lessen zijn duidelijk en hard. Ten eerste: herkomst van afhankelijkheden doet ertoe. Haastig installeren van handige libraries zonder checksums en uitgevers te verifiëren creëert risico in de toeleveringsketen. Ten tweede: geheimen horen niet in platte tekst in pijplijnvariabelen of in langlevende tokens te staan. Gebruik waar mogelijk kortstondige service-identiteiten en workload-gebaseerde toegang. Ten derde heeft het open-source-ecosysteem strengere begrenzingen nodig: reproduceerbare builds, ondertekende pakketten en betere uitgevershygiëne zullen dit type aanval afzwakken.

Voor organisaties die LiteLLM of gerelateerde tools gebruiken, moeten de volgende onmiddellijke stappen onder meer omvatten:

• Inventariseer alle referenties en tokens die mogelijk in build- of runtime-geheugen zijn geladen.
• Trek die sleutels in en roteer ze, en geef nieuwe referenties uit met minimaal noodzakelijke machtigingen.
• Controleer CI/CD-pijplijnen en vervang alle platte-tekstgeheimen door in een vault beheerde kortstondige tokens.
• Valideer de integriteit van pakketten door checksums te controleren en de voorkeur te geven aan ondertekende releases van vertrouwde onderhouders.
• Monitor op afwijkend uitgaand verkeer vanaf build-infrastructuur dat op aanwezige achterdeuren kan wijzen.

De aanval is een wake-up call. Het integreren van AI-tools kan grote productiviteitswinst opleveren. Maar wanneer snelheid de beveiliging voorbijstreeft, is de nasleep geen theoretisch risico. Referenties zijn valuta. Zodra ze gelekt zijn, maken ze escalatie, laterale bewegingen en datadiefstal op schaal mogelijk. Teams moeten ervan uitgaan dat compromittering mogelijk is en systemen bouwen die minimaliseren wat een aanvaller in één sessie kan bemachtigen.

Verwacht meer gedetailleerde openbaarmakingen van beveiligingsbedrijven naarmate zij de 195-terabytevondst verder analyseren en getroffen organisaties in kaart brengen. Voor nu is de veiligste houding een snelle, gecoördineerde sleutelrotatie gecombineerd met een forensische beoordeling van build- en deploymentprocessen.