Малициозните LiteLLM изданија поврзани со Trivy хакот можеби изложиле повеќе од 2.100 организации

Две малициозни изданија на LiteLLM се наоѓале на PyPI околу 40 минути во март, носејќи код за крадење акредитиви способен да собира cloud клучеви, SSH клучеви, Kubernetes токени, лозинки за бази на податоци и други тајни од системите на кои биле инсталирани.

Компанијата за разузнавање за сајбер-закани CloudSEK сега наведува дека датасетот што го добила, создаден од приближно 434.000 датотеки што ги презеле напаѓачите, укажува на потенцијална изложеност на повеќе од 2.500 организации.

Сепак, овие бројки не претставуваат број на жртви. CloudSEK за The Hacker News изјавил дека материјалот потекнува од доверливи разузнавачки извори и се состои од украдени податоци и логови кои компанијата ги проценила како поврзани со кампањата, а не од податоци собрани директно од организациите што се наведени. Со други зборови, датотеките биле украдени.

CloudSEK го објави датасетот како јавна алатка за пребарување, каде што може да се пребарува според име или домен и да се филтрира според нивото на доверба. Секој запис го прикажува името и доменот на организацијата, бројот на изложени тајни, бројот на извршувања и ознака High или Medium.

Припишувањето со висока доверба се однесува на тоа од чии системи потекнува секоја датотека. Проценката се темели на сигнали за идентитетот во компромитираната CI околина, првенствено идентитетот на хостот и легитимните домени на commit-ерите. За организацијата да добие највисока оценка, нејзиниот сопствен домен мора да се појавува во податоците.

Самото совпаѓање со namespace на repository овозможува само проценка со средна доверба. Меѓу записите се наоѓаат NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens и X Corp. Сепак, самото присуство во датасетот не докажува дека украдените акредитиви биле искористени. Токму затоа и CloudSEK и LiteLLM ги советуваат потенцијално погодените организации да ги ротираат акредитивите, наместо да чекаат доказ дека биле злоупотребени.

LiteLLM е open-source AI gateway кој се користи за поврзување на апликации со повеќе провајдери на модели.

Проектот потврди дека верзиите 1.82.7 и 1.82.8 биле компромитирани и биле достапни на 24 март од 10:39 UTC околу 40 минути, пред PyPI да ги стави во карантин. Сепак, LiteLLM ги советува корисниците да го сметаат за сомнително секое инсталирање направено тој ден до 16:00 UTC.

The Hacker News на 12 август потврдил преку PyPI дека ниту една од овие две верзии повеќе не се појавува во историјата на изданијата на пакетот, додека верзиите 1.82.6 и 1.83.0 остануваат достапни.

FBI на 2 јули, во советувањето FLASH-20260702-01, предупреди дека поврзаните напаѓачи најверојатно ќе се обидат да ги искористат украдените акредитиви од TeamPCP кампањата и долго по првичниот компромис.

FBI им препорача на организациите да ги ротираат CI/CD тајните, publishing токените и cloud акредитивите до кои напаѓачите можеле да имаат пристап во релевантните периоди на изложеност.

Што значи ова практично?

Ако организација инсталирала LiteLLM 1.82.7 или 1.82.8 во наведениот период, ризикот не е ограничен само на самиот LiteLLM. Малициозниот код можел да бара чувствителни податоци во средината во која бил извршен — вклучително и cloud credentials, SSH клучеви, Kubernetes токени, database credentials и CI/CD secrets.

Затоа најбезбедниот пристап е ротација на сите потенцијално изложени credentials и токени, проверка на CI/CD логовите и audit на cloud и repository активноста, дури и ако сè уште нема доказ дека украдените податоци биле злоупотребени.

Долготраен таен клуч копиран во текот на тој период — статички cloud клуч, SSH клуч или publishing токен — останува употреблив сè додека не биде ротиран или отповикан. Токму затоа упатствата на бирото се фокусирани на акредитивите, а не само на пакетот, и затоа и бирото и Aqua им препорачуваат на тимовите да се оддалечат од долготрајни токени и да користат привремени токени.

Верзијата 1.82.8 содржела датотека наречена litellm_init.pth, која Python ја обработува при стартување на интерпретерот. Тоа значи дека кодот се извршувал секогаш кога ќе се стартувал Python процес во таа околина, без разлика дали тој процес воопшто го увезувал LiteLLM.

Компромитираните пакети биле дизајнирани да собираат environment variables, SSH клучеви, cloud акредитиви, Kubernetes токени и лозинки за бази на податоци, по што украдените податоци биле шифрирани и испраќани до models.litellm[.]cloud — домен контролиран од напаѓачите, кој не е поврзан со самиот проект.

Анализот на кампањата од Unit 42 покажува дека payload-от ги читувал environment variables во кои се наоѓаат API клучеви за AI модели, вклучително и OPENAI_API_KEY и ANTHROPIC_API_KEY.

Ова го менува вообичаеното прашање при истрагата. Тоа дали тимот намерно користи LiteLLM е помалку важно од тоа дали нешто на хостот го инсталирало. Во безбедносното известување на проектот се наведува дека и нефиксирана транзитивна зависност, вклучително и зависност што ја внесува agent framework или orchestration алатка, можела да го достави малициозниот пакет без корисникот намерно да го избере.

Инцидентот со LiteLLM е дел од поширока TeamPCP supply-chain кампања, поврзана со Trivy scanner на Aqua Security. Google ја следи групата TeamPCP под ознаката UNC6780.

Aqua соопшти дека напаѓачите го задржале пристапот по нецелосна ротација на акредитивите и на 19 март извршиле force-push на малициозни commit-и кон 76 од 77 trivy-action version tags и кон сите седум setup-trivy тагови. Истовремено бил објавен и малициозен Trivy 0.69.4.

Компромитирањето на екосистемот се следи како CVE-2026-33634, кое на 26 март било додадено во каталогот Known Exploited Vulnerabilities (KEV) на CISA. The Hacker News на 12 август потврдил дека записот за CVE сега ги наведува и BerriAI LiteLLM 1.82.7 до 1.82.8 како погодени, заедно со Trivy компонентите.

Точно како малициозните LiteLLM изданија стигнале до PyPI било предмет на различни објаснувања во објавените извештаи. Извештајот на CloudSEK наведува дека компромитираниот build ги создал и објавил изданијата. Сопствениот извештај на LiteLLM за инцидентот упатува на директен upload на PyPI, со кој бил заобиколен официјалниот CI/CD workflow. Во меѓувреме, Unit 42 опишува дека напаѓачите ги таргетирале PyPI publishing токените по компромисот на Trivy.

На прашањето за ова несовпаѓање, CloudSEK одговорил дека станува збор за различни фази од истиот нападен синџир, а не за спротивставени објаснувања. Нивните докази покажуваат како бил добиен акредитивот, додека наодите на LiteLLM и Unit 42 покажуваат како потоа бил искористен.

И PyPA во своето безбедносно известување за малициозните изданија го опишува истиот тек: API токен бил изложен преку компромитираната Trivy зависност, а потоа бил искористен за upload на двете верзии. Во моментот на пишувањето, BerriAI не одговорил на прашањата за тоа кои детали ги потврдува неговата сопствена форензичка анализа.

CloudSEK наведува дека припишувањето на датотеките во датасетот се врши преку две независни проверки. Еден индекс ја поврзува секоја датотека со CI identity variables, додека одделна проверка на сопственоста повторно ја утврдува сопственоста преку преземените логови и може да ја промени првичната проценка.

Доколку двете проверки не се совпаѓаат, извештајот за тој запис се задржува, а конечната проценка ја користи пониската од двете нивоа на доверба.

Бројката од 434.000 се однесува на преземени датотеки и exfiltration events, а не на бројот на уникатни pipeline-и, runs или jobs. CloudSEK наведува дека една преземена датотека приближно одговара на едно извршување на job, но не го претставува вкупниот број како број на уникатни jobs без независна дедупликација и верификација.

Компанијата одбила да коментира дали организациите наведени во датасетот биле известени пред неговото објавување и не кажала дали некоја од нив ја оспорила својата појава во списокот.

Последиците од кампањата се потврдени

Влијанието на кампањата врз други организации е потврдено, дури и ако бројките на CloudSEK за нејзиниот вкупен размер сè уште не се независно потврдени.

Checkmarx соопшти дека акредитивите добиени преку нападот врз Trivy овозможиле неовластен пристап до неговите GitHub repositories и објавување малициозни артефакти.

Mercor соопшти дека бил погоден од малициозните LiteLLM верзии и дека во неговата средина била забележана неовластена активност.

Одделно, CERT-EU со висока доверба проценил дека AWS сметка на Европската комисија била компромитирана преку Trivy supply-chain нападот, при што биле ексфилтрирани околу 91,7 GB компресирани податоци.

Што треба да проверат организациите?

Организациите што проценуваат дали биле погодени треба да ги преземат следните чекори:

• Проверете дали LiteLLM 1.82.7 или 1.82.8 биле инсталирани за време на audit периодот на LiteLLM на 24 март, од 10:39 до 16:00 UTC.
• Ротирајте ги сите тајни и акредитиви до кои тие системи можеле да имаат пристап.
• Пребарајте ги GitHub организациите за repositories со имиња tpcp-docs или docs-tpcp, кои FBI ги наведува како индикатори поврзани со кампањата.

Важно е дека пребарувањето само по точните имиња може да не биде доволно. Според советувањето на Aqua, малициозниот софтвер создавал repositories со префикс tpcp-docs- и ги поставувал украдените податоци како release assets со ознака во формат data-<timestamp>.

Затоа, при проверката треба да се бараат и варијации со tpcp-docs- префиксот, како и сомнителни release assets со имиња што следат data-<timestamp> шема.

Извори:

• The Hacker News – Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations The Hacker News