Giftige Python-package compromitteert AI-keys van NASA, Netflix en NVIDIA

Giftige Python-package compromitteert AI-keys van NASA, Netflix en NVIDIA

Een simpel pip install was genoeg om alle AI-API keys te stelen. Een populaire package met 97 miljoen downloads per maand is recent vergiftigd. Het schokkende? De malware zat in LiteLLM, een tool die juist bedoeld is om al je AI-credentials veilig te beheren.

Dit incident laat zien hoe kwetsbaar de supply chain van AI-tools eigenlijk is. Zelfs grote organisaties als NASA, Netflix, Stripe en NVIDIA liepen risico.

Wat is er precies gebeurd?

Iemand heeft een kwaadaardige versie van LiteLLM gepubliceerd op PyPI. Deze package wordt door duizenden bedrijven gebruikt om API-keys van OpenAI, Anthropic, Google, Amazon en andere AI-providers te beheren via één centrale proxy.

Het meest verontrustende aspect: je hoefde de package niet eens te importeren of een functie aan te roepen. Zodra de malware op je machine stond, activeerde deze zichzelf automatisch bij het opstarten van Python.

De vergiftigde versie bevatte geen code op GitHub, geen release tag en onderging geen review-proces. Het was een direct geüploade malicious package die direct uitvoerbare code bevatte.

Hoe werd de aanval ontdekt?

Ironisch genoeg werd de aanval alleen ontdekt omdat de malware zó slordig was geschreven dat computers crashten. De malware gebruikte extreem veel RAM, waardoor een developer argwaan kreeg en zijn machine ging onderzoeken.

Tijdens dit onderzoek ontdekte hij dat LiteLLM was binnengehaald via een Cursor MCP plugin waar hij zich niet eens bewust van was. Zonder deze crash hadden duizenden bedrijven mogelijk weken of maanden ongemerkt gecompromitteerd kunnen zijn.

De aanvalsketen: van Trivy naar LiteLLM

De aanval was bijzonder goed voorbereid en volgde een slimme keten:

Stap 1: Compromitteren van een security tool

De groep TeamPCP hackte eerst Trivy, een populair security scanning tool, op 19 maart. LiteLLM gebruikte Trivy in zijn eigen CI/CD pipeline. Zo werden de credentials van een security product gebruikt om het AI-product te compromitteren dat alle andere credentials beheert.

Stap 2: Escalatie door vijf package ecosystemen

Vervolgens wisten de aanvallers toegang te krijgen tot:

  • GitHub Actions
  • Docker Hub
  • npm
  • Open VSX

In twee weken tijd wisten ze vijf verschillende package-ecosystemen te infiltreren, waarbij elke inbraak hen de sleutels gaf voor de volgende.

Wat deed de malware precies?

De payload bestond uit drie stadia:

  1. Data harvesting: Alle SSH-keys, cloud tokens, Kubernetes secrets, crypto wallets en .env bestanden werden verzameld.
  2. Cluster infiltratie: Er werden geprivilegieerde containers gedeployed over alle nodes in een cluster.
  3. Persistente backdoor: Een achterdeur die wacht op nieuwe instructies van de aanvallers.

Dit betekende dat niet alleen individuele machines, maar hele infrastructuren in één klap gecompromitteerd konden raken.

De grotere les: supply chain risico's in AI

Dit incident toont een fundamenteel probleem aan in hoe snel AI-tools worden geadopteerd. Veel bedrijven implementeren AI-oplossingen zonder goed zicht te hebben op de onderliggende afhankelijkheden.

De meeste AI-agents, copilots en interne tools draaien tegenwoordig op honderden packages. Vaak worden deze packages indirect geïnstalleerd als dependency of a dependency of a plugin. Eén gecompromitteerd maintainer-account kan zo een kettingreactie veroorzaken.

TeamPCP liet na de aanval op Telegram weten: "Many of your favourite security tools and open-source projects will be targeted in the months to come... stay tuned."

Hoe bescherm je jezelf tegen supply chain attacks?

1. Beperk het vertrouwen in packages

Installeer niet automatisch elke package die een tool aanbeveelt. Controleer regelmatig welke afhankelijkheden je indirect binnenhaalt met tools als pip list of pipdeptree.

2. Gebruik dependency scanning

Integreer tools als Dependabot, Snyk of Renovate in je CI/CD pipeline om kwetsbaarheden en verdachte updates vroegtijdig te detecteren.

3. Beperk rechten

Geef ontwikkelomgevingen en CI/CD pipelines zo min mogelijk rechten. Gebruik het principe van least privilege, vooral voor tools die met credentials werken.

4. Monitor ongebruikelijke activiteit

Houd RAM-gebruik, netwerkverkeer en procesactiviteit in de gaten. Ongebruikelijke pieken kunnen, zoals in dit geval, een indicatie zijn van malware.

5. Overweeg alternatieven voor credential management

Voor het beheren van API-keys zijn er robuustere oplossingen dan het centraal routeren via één package. Overweeg secrets managers zoals HashiCorp Vault, AWS Secrets Manager of Azure Key Vault.

Conclusie: We moeten kritischer worden

De razendsnelle adoptie van AI-tools heeft geleid tot een situatie waarin we meer vertrouwen hebben in open source packages dan verstandig is. Dit incident met LiteLLM is een wake-up call voor iedereen die AI ontwikkelt of implementeert.

De bedrijven die momenteel het snelst AI deployen, hebben vaak de minste zichtbaarheid op wat er zich onder de motorkap afspeelt.

Tijd om actie te ondernemen. Neem vandaag nog de tijd om je dependency management onder de loep te nemen. Controleer welke packages je gebruikt voor AI-ontwikkeling, implementeer betere scanning tools en beperk de rechten van je ontwikkelomgevingen.

Want de volgende aanval komt eraan. En de volgende keer is de malware misschien niet zo slordig gecodeerd.

Heb je vragen over hoe je jouw AI-supply chain beter kunt beveiligen? Laat een reactie achter of neem contact op.