TeamPCP wprowadza backdoory do LiteLLM (wersje 1.82.7–1.82.8) przez atak na Trivy CI/CD

Świat bezpieczeństwa łańcucha dostaw oprogramowania (Software Supply Chain) stanął w obliczu kolejnego poważnego kryzysu, który uderza bezpośrednio w ekosystem sztucznej inteligencji. Grupa hakerska znana jako TeamPCP, odpowiedzialna za niedawne ataki na popularne narzędzia skanujące takie jak Trivy oraz KICS, rozszerzyła swoje działania na bibliotekę LiteLLM. To niezwykle popularny pakiet Pythonowy, służący jako uniwersalny interfejs do integracji z wieloma modelami językowymi (LLM), takimi jak OpenAI, Anthropic czy Google Vertex AI. Skala zagrożenia jest o tyle duża, że LiteLLM stanowi fundament wielu komercyjnych i open-source’owych aplikacji AI, co czyni go idealnym celem dla napastników szukających dostępu do wrażliwych danych korporacyjnych.

Według raportów opublikowanych przez czołowe firmy zajmujące się cyberbezpieczeństwem, w tym Endor Labs oraz JFrog, zainfekowane wersje oprogramowania pojawiły się bezpośrednio w oficjalnym repozytorium. Atakujący zdołali przemycić złośliwy kod do wersji 1.82.7 oraz 1.82.8. Mechanizm infekcji sugeruje, że nie był to przypadkowy błąd programisty, lecz precyzyjnie zaplanowana operacja typu CI/CD compromise, prawdopodobnie wykorzystująca luki w procesach automatyzacji publikacji kodu, które wcześniej pozwoliły tej samej grupie na uderzenie w Trivy.

Arsenał TeamPCP ukryty w paczkach Pythona

To, co wyróżnia ten atak na tle typowych kampanii typu "typosquatting", to stopień zaawansowania złośliwego oprogramowania zaszytego wewnątrz LiteLLM. Badacze zidentyfikowali trzy główne moduły, które czynią zainfekowane wersje 1.82.7 i 1.82.8 ekstremalnie niebezpiecznymi dla środowisk produkcyjnych. Po pierwsze, kod zawiera credential harvester – narzędzie zaprojektowane do automatycznego wyszukiwania i kradzieży kluczy API, haseł oraz tokenów dostępowych przechowywanych w zmiennych środowiskowych serwera. W kontekście narzędzia takiego jak LiteLLM, które z natury operuje na kluczach do drogich modeli AI, ryzyko finansowe i operacyjne jest gigantyczne.

Drugim elementem jest Kubernetes lateral movement toolkit. Jest to zestaw skryptów pozwalający atakującym na eskalację uprawnień i przemieszczanie się wewnątrz klastrów Kubernetes. Ponieważ nowoczesne aplikacje LLM są niemal zawsze konteneryzowane i uruchamiane w chmurze, obecność takiego narzędzia sugeruje, że TeamPCP celuje w przejmowanie całych infrastruktur chmurowych, a nie tylko pojedynczych aplikacji. Trzecim, i być może najgroźniejszym komponentem, jest persistent backdoor, który gwarantuje hakerom stały dostęp do zainfekowanego systemu, nawet po próbie usunięcia złośliwych plików lub restartu usług.

• Zainfekowane wersje: LiteLLM 1.82.7 oraz 1.82.8.
• Główne zagrożenia: Kradzież poświadczeń, eskalacja w Kubernetes, trwały backdoor.
• Prawdopodobny wektor: Kompromitacja potoków CI/CD (prawdopodobnie powiązana z incydentem Trivy).
• Rekomendacja: Natychmiastowa aktualizacja do wersji wolnych od złośliwego kodu lub rollback do wersji 1.82.6.

Mechanizm kompromitacji przez potoki CI/CD

Analiza techniczna incydentu wskazuje, że TeamPCP nie włamało się bezpośrednio na konta deweloperów LiteLLM poprzez phishing, lecz wykorzystało słabości w infrastrukturze budowania oprogramowania. Istnieją silne przesłanki, że atak jest bezpośrednim następstwem wcześniejszego przejęcia narzędzia Trivy. Jeśli deweloperzy LiteLLM używali zainfekowanej wersji Trivy do skanowania swojego kodu w procesie CI/CD, mogło dojść do tzw. "zatrucia studni". Złośliwe narzędzie skanujące, zamiast chronić kod, wstrzyknęło do niego backdoora podczas automatycznego procesu budowania paczki PyPI.

To zjawisko pokazuje nową, przerażającą erę cyberataków, w której narzędzia bezpieczeństwa stają się końmi trojańskimi. Wykorzystanie Trivy – standardu branżowego w skanowaniu kontenerów i zależności – do zainfekowania biblioteki LiteLLM demonstruje, jak głęboka i skomplikowana jest sieć powiązań w nowoczesnym rozwoju oprogramowania. Atakujący nie muszą już szukać dziur w finalnym produkcie; wystarczy, że przejmą kontrolę nad jednym z ogniw łańcucha automatyzacji, aby ich kod trafił do tysięcy serwerów na całym świecie pod szyldem zaufanego wydawcy.

Odpowiedź na zagrożenie i ochrona infrastruktury AI

Dla organizacji korzystających z LiteLLM sytuacja wymaga natychmiastowej reakcji. Standardowe procedury bezpieczeństwa powinny obejmować nie tylko audyt wersji pakietów w plikach requirements.txt czy pyproject.toml, ale również głęboką inspekcję środowisk uruchomieniowych. Jeśli Twoja infrastruktura korzystała z wersji 1.82.7 lub 1.82.8, samo podbicie wersji do bezpiecznej może nie wystarczyć, biorąc pod uwagę obecność backdoora umożliwiającego trwałą obecność napastnika. Konieczna jest rotacja wszystkich kluczy API (OpenAI, Anthropic, AWS, Azure) oraz audyt uprawnień wewnątrz klastrów Kubernetes pod kątem nieautoryzowanych kont serwisowych.

W szerszym kontekście, incydent z LiteLLM wymusza redefinicję podejścia do zaufania w ekosystemie open-source. Tradycyjne VPN-y i proste zapory ogniowe nie chronią przed złośliwym kodem, który sami pobieramy do wnętrza naszej sieci. Rozwiązaniem, które zyskuje na znaczeniu, jest przejście w stronę modelu Zero Trust Network Access (ZTNA). Zamiast ufać aplikacjom na podstawie ich pochodzenia, model ten zakłada, że każda interakcja – nawet ta wewnątrz klastra między mikroserwisami – musi być weryfikowana i izolowana. Wyeliminowanie możliwości lateralnego poruszania się (lateral movement) poprzez bezpośrednie łączenie użytkowników i procesów z konkretnymi aplikacjami, zamiast dawania im dostępu do całych segmentów sieci, jest kluczowe w dobie ataków takich jak ten przeprowadzony przez TeamPCP.

"Bezpieczeństwo łańcucha dostaw oprogramowania nie jest już opcjonalnym dodatkiem, lecz fundamentem przetrwania każdej firmy technologicznej. Atak na LiteLLM pokazuje, że nawet najbardziej zaufane biblioteki mogą stać się wektorem ataku w ciągu jednej nocy."

Ewolucja metod TeamPCP wskazuje na to, że grupa ta doskonale rozumie architekturę nowoczesnych systemów AI. Skupienie się na kradzieży poświadczeń i manipulacji klastrami Kubernetes sugeruje, że ich celem nie jest jedynie wandalizm, lecz systematyczne szpiegostwo przemysłowe lub przygotowanie gruntu pod masowe ataki ransomware na infrastrukturę chmurową. W dobie wyścigu zbrojeń w dziedzinie AI, gdzie dane treningowe i modele stanowią najcenniejszy kapitał firmy, ochrona narzędzi takich jak LiteLLM staje się priorytetem najwyższego rzędu dla działów Cybersecurity na całym świecie.

Agresywne tempo publikowania nowych wersji w projektach open-source, choć sprzyja innowacji, tworzy luki, które TeamPCP potrafi bezlitośnie wykorzystać. Organizacje muszą zacząć stosować narzędzia do analizy składu oprogramowania (SCA), które działają w czasie rzeczywistym i potrafią wykryć anomalie w zachowaniu pakietów, a nie tylko polegać na bazach znanych podatności (CVE). Tylko poprzez rygorystyczne podejście do weryfikacji każdej linii kodu wchodzącej do środowiska produkcyjnego, można zminimalizować ryzyko powtórki scenariusza, w którym narzędzie mające ułatwiać pracę z AI staje się kluczem do firmowego sejfu.