L’ANALISI
LiteLLM 1.107.0 compromessa: come verificare e bonificare gli ambienti
LiteLLM 1.107.0 compromessa: artefatti coinvolti, finestra di esposizione, indicatori, rotazione delle credenziali e procedura di bonifica.
In breve: Se LiteLLM 1.107.0 è stata installata da PyPI o avviata da uno dei tag container coinvolti nella finestra indicata, l’ambiente va considerato compromesso. La risposta prudente è isolare l’host, ricostruire da una base pulita, tornare a una versione esplicita precedente e ruotare ogni segreto che quel sistema poteva leggere.
Che cosa è stato compromesso
Il progetto indica sette wheel PyPI di litellm 1.107.0 e i tag container v1.107.0, latest, main-latest e main-stable. Il tag sorgente GitHub 1.107.0 non contiene i file malevoli: gli artefatti sarebbero stati costruiti da un repository controllato dall’attaccante.
La finestra da verificare
Il pacchetto PyPI è rimasto disponibile circa due ore, dalle 11:39 alle 13:23 UTC del 21 ottobre. I tag Docker Hub coinvolti hanno puntato all’immagine compromessa dalle 11:46 alle 14:20 UTC; GHCR è stato reso indisponibile entro le 13:51 UTC.
Perché un semplice downgrade non basta
L’avvio di Python nell’ambiente interessato può eseguire cook.pth e sitecustomize.py. Per questo il progetto avverte di non iniziare la bonifica eseguendo pip nello stesso ambiente e preferisce la ricostruzione completa di container e virtual environment.
Quali segreti ruotare
Il report cita ruoli IAM, chiavi dei provider conservate dal proxy LiteLLM, master key, virtual key, password DATABASE_URL e ogni altro segreto presente nell’ambiente o raggiungibile dall’host. La rotazione va accompagnata da ricerca di utilizzi anomali fuori dall’infrastruttura.
Come leggere la causa
LiteLLM riferisce che l’attaccante aveva credenziali GitHub CLI di più sviluppatori e ha aggirato controlli indipendenti fino a modificare il flusso di build. Il caso mostra che firma, repository privato e tag immutabili riducono il rischio solo se identità e autorizzazioni del processo di release restano integre.
Condizioni e limitazioni
L’indagine è ancora in corso. L’assenza dei file indicatore non dimostra che l’host sia pulito; il progetto raccomanda di ricostruire ambienti e immagini, ruotare tutte le credenziali raggiungibili e verificare gli eventi cloud, non soltanto di fare downgrade del pacchetto.
Checklist pratica
- Isolare host e workload che hanno eseguito LiteLLM 1.107.0.
- Non avviare Python o pip dentro l’ambiente sospetto prima di acquisire le evidenze.
- Verificare versione installata, digest container e intervallo di esecuzione.
- Cercare cook.pth, cook.py, sitecustomize.py, bytecode correlato e il lock del loader.
- Ricostruire immagini e virtual environment da una base pulita e pin verificato.
- Ruotare chiavi provider, ruoli cloud, master key, virtual key, database e segreti di processo.
- Controllare CloudTrail e gli altri log per uso esterno delle credenziali.
- Conservare timeline, digest e log per l’eventuale risposta all’incidente.