Pachetele LiteLLM malițioase au furat secrete CI/CD: ce înseamnă cele 2.500 de potriviri

Eliminarea pachetului malițios oprește distribuția, dar nu revocă nimic din ceea ce a fost deja copiat. O cheie cloud statică, o cheie SSH, un token de publicare sau o parolă de bază de date rămâne utilizabilă până când expiră, este revocată sau rotită. Evaluarea expunerii trebuie să urmeze durata de viață a credențialei, nu intervalul în care pachetul a existat pe PyPI.

LiteLLM recomandă auditarea unei ferestre mai largi—10:39–16:00 UTC pe 24 martie—deoarece o instalare fără versiune fixată, un build Docker, un framework pentru agenți AI, un server MCP sau o dependență de orchestrare ar fi putut descărca tranzitiv una dintre versiunile afectate. Imaginile Docker oficiale LiteLLM Proxy au fost declarate neafectate deoarece foloseau dependențe fixate. Instalările din repository-ul GitHub al proiectului nu au trecut nici ele prin calea PyPI compromisă.

Pe 11 august, CloudSEK a publicat analiza unui set de date despre care spune că provine din surse confidențiale de intelligence și este construit din material capturat de atacatori. Compania raportează aproximativ 434.000 de fișiere sau evenimente de exfiltrare și potriviri la nivel organizațional pentru peste 2.500 de entități. Instrumentul public etichetează potrivirile High sau Medium și afișează agregat numărul de „secrets” și „runs”.

Cifrele nu trebuie transformate în 434.000 de pipeline-uri unice sau 2.500 de victime confirmate. CloudSEK a explicat pentru The Hacker News că un fișier capturat corespunde aproximativ unei execuții de job, dar setul nu a fost deduplicat independent în joburi unice. Eticheta High confidence indică semnale de identitate mai puternice—precum identitatea hostului, domenii legitime ale contributorilor și domeniul organizației—nu confirmarea organizației și nici dovada că atacatorul a utilizat o credențială.

Setul CloudSEK este util ca notificare de expunere și semnal de triaj. Nu este o concluzie forensică independentă pentru fiecare nume. De aceea nu reproducem lista organizațiilor, volumele de secrete sau materialul capturat. O companie care se regăsește trebuie să valideze semnalul în propriile loguri CI, evidențe de dependențe, audit cloud și inventar de credențiale.

Incertitudinea privind dimensiunea setului nu transformă TeamPCP într-o campanie teoretică. CERT-EU și Comisia Europeană au evaluat cu încredere ridicată că o versiune Trivy compromisă a expus un secret AWS folosit pentru accesarea infrastructurii cloud a Comisiei. CERT-EU a raportat exfiltrarea a aproximativ 91,7 GB de date comprimate și a precizat că pot fi afectate informații legate de cel puțin alte 29 de entități ale Uniunii.

Impactul Trivy confirmat nu demonstrează compromiterea fiecărei organizații potrivite de CloudSEK în cazul LiteLLM. Demonstrează însă lanțul de atac pe care apărătorii trebuie să îl testeze: o dependență de securitate de încredere rulează în CI, citește un mediu valoros, exfiltrează o credențială și creează un acces care supraviețuiește după eliminarea dependenței.

Raportul LiteLLM listează versiunile auditate până la 1.82.6 drept curate și spune că 1.83.0 a fost produsă printr-un pipeline redesenat. Proiectul a continuat să publice versiuni după martie, deci remedierea făcută astăzi trebuie să urmeze recomandarea oficială curentă pentru versiunea suportată și să verifice proveniența artefactului, nu să facă downgrade automat la un build vechi.

• Caută dovezi că LiteLLM 1.82.7 sau 1.82.8 a fost instalat ori păstrat în cache pe 24 martie, inclusiv în loguri CI, lockfiles, manifeste de build, layere de imagini, cache-uri de pachete și dependențe tranzitive
• Izolează hosturile sau runner-ele afectate și păstrează probele înainte de curățare; caută litellm_init.pth, modificări de persistență și conexiuni către indicatorii defangați models.litellm[.]cloud și checkmarx[.]zone
• Presupune că fiecare secret accesibil procesului a fost expus: rotește chei cloud și API pentru furnizori AI, chei SSH, tokenuri Kubernetes, credențiale de baze de date, registry și publicare CI/CD
• După rotație, invalidează sesiunile și credențialele derivate, elimină cheile sau conturile neautorizate și verifică logurile AWS, Azure, GCP, GitHub, GitLab, Kubernetes și ale bazelor de date pentru utilizare ulterioară expunerii
• Reconstruiește mediile afectate din artefacte verificate și o versiune LiteLLM suportată; ștergerea pachetului sau upgrade-ul în același mediu nu demonstrează că hostul este curat

Execuția prin fișierul .pth arată și de ce „aplicația noastră nu îl importă” nu este un test suficient. Inventarul trebuie să descrie ce a fost instalat în mediul Python și în imagine, nu doar ceea ce apare în graful de import al aplicației.

• Înlocuiește secretele CI cu durată lungă prin credențiale temporare legate de workload acolo unde cloud-ul, registry-ul și ecosistemul de pachete le suportă
• Fixează acțiunile și dependențele la digesturi sau commit SHA imuabile, păstrează SBOM-uri și verifică dacă artefactul publicat corespunde unei revizii de cod aprobate
• Separă identitățile de build, test și publicare pentru ca un scanner de securitate compromis să nu moștenească automat dreptul de a publica pachete sau administra producția

Pentru organizațiile europene, incidentul se leagă direct de disciplinele NIS2 privind gestionarea incidentelor, continuitatea, securitatea lanțului de aprovizionare, gestionarea vulnerabilităților, criptografia și evaluarea eficacității controalelor. Dacă evenimentul depășește un prag de raportare depinde de organizație și impactul real, dar evaluarea nu poate începe fără inventar cu responsabil și dovezi de expunere.

Managementul ar trebui să poată răspunde: cine deține dependențele gateway-ului AI, cine vede toate secretele primite de runner, cine autorizează rotația între cloud și engineering și ce dovedește că o credențială suspectă nu a fost folosită după martie? Lista versiunilor rezolvă doar primul minut al incidentului.

Awarely Monitor leagă informațiile despre vulnerabilități și avize din NVD, CISA KEV, EUVD și GitHub Security Advisories de inventarul activelor, responsabilitate, starea remedierii și dovezi de audit. Într-un incident de supply chain, această evidență transformă alerta globală într-o listă demonstrabilă de sisteme afectate, responsabili și acțiuni verificate.