Jak atak na LiteLLM ujawnia zagrożenia dla stacji roboczych programistów

W firmach kluczowym elementem infrastruktury przedsiębiorstw jest stacja robocza programisty. To właśnie na tym laptopie tworzone są dane uwierzytelniające, które są testowane, przechowywane, kopiowane i używane w różnych usługach, botach oraz narzędziach do budowy, a obecnie także lokalnych agentach AI.

W marcu 2026 roku grupa przestępcza TeamPCP udowodniła, jak cenne są maszyny deweloperów. Ich atak na LiteLLM, popularną bibliotekę do rozwoju AI, która jest pobierana miliony razy dziennie, przekształcił urządzenia deweloperskie w systematyczne operacje pozyskiwania danych uwierzytelniających. Złośliwe oprogramowanie wymagało jedynie dostępu do niezaszyfrowanych sekretów już znajdujących się na dysku.

Atak był dość prosty w wykonaniu, ale jego zasięg był znaczny. Grupa TeamPCP skompromitowała wersje 1.82.7 i 1.82.8 pakietów LiteLLM na PyPI, wstrzykując złośliwe oprogramowanie typu infostealer, które aktywowało się, gdy deweloperzy instalowali lub aktualizowali pakiet. Złośliwe oprogramowanie systematycznie zbierało klucze SSH, dane uwierzytelniające do chmury AWS, Azure i GCP, konfiguracje Dockera oraz inne wrażliwe dane z maszyn deweloperskich.

PyPI usunęło złośliwe pakiety kilka godzin po ich wykryciu, ale okno na szkody było znaczne. Analiza GitGuardian wykazała, że 1 705 pakietów PyPI było skonfigurowanych do automatycznego pobierania skompromitowanych wersji LiteLLM jako zależności. Popularne pakiety takie jak dspy (5 milionów pobrań miesięcznie), opik (3 miliony) i crawl4ai (1,4 miliona) mogły aktywować złośliwe oprogramowanie w trakcie instalacji. Efekt kaskadowy oznaczał, że organizacje, które nigdy bezpośrednio nie używały LiteLLM, mogły również zostać skompromitowane poprzez zależności transitive.

Ten wzór ataku nie jest nowy, jest po prostu bardziej widoczny. Kampanie Shai-Hulud wykazały podobne taktyki w dużej skali. Gdy GitGuardian przeanalizował 6 943 skompromitowane maszyny deweloperskie z tego incydentu, naukowcy odkryli 33 185 unikalnych sekretów, z czego co najmniej 3 760 było nadal ważnych. Co więcej, każdy aktywny sekret znajdował się w około ośmiu różnych lokalizacjach na tej samej maszynie, a 59% skompromitowanych systemów to były CI/CD runners zamiast osobistych laptopów.

Współczesni przeciwnicy wkradają się do łańcucha narzędziowego poprzez skompromitowane zależności, złośliwe wtyczki lub zainfekowane aktualizacje. Gdy już się tam znajdą, zbierają dane z lokalnego środowiska w taki sam sposób, w jaki zespoły bezpieczeństwa skanują luki, ale w ich przypadku chodzi o dane uwierzytelniające przechowywane w plikach .env, profilach powłoki, historii terminala, ustawieniach IDE oraz we wspomnieniach agentów AI.

Złośliwe oprogramowanie LiteLLM odniosło sukces, ponieważ maszyny deweloperów są gęsto skoncentrowanymi punktami dla niezaszyfrowanych danych uwierzytelniających. Sekrety lądują w drzewach źródłowych, lokalnych plikach konfiguracyjnych, wynikach debugowania, skopiowanych poleceniach terminala, zmiennych środowiskowych i tymczasowych skryptach. Akumulują się w plikach .env, które miały być lokalne, ale stały się trwającą częścią bazy kodu. Wygoda zamienia się w resztki, które stają się okazją.

Deweloperzy uruchamiają agenty, lokalne serwery MCP, narzędzia CLI, rozszerzenia IDE, procesy budowania i przepływy robocze do pobierania, które wymagają danych uwierzytelniających. Te dane uwierzytelniające rozprzestrzeniają się w przewidywalnych miejscach, w których złośliwe oprogramowanie wie, gdzie szukać: ~/.aws/credentials, ~/.config/gh/config.yml, pliki .env projektów, historia powłoki i katalogi konfiguracji agentów.

Ważne jest, aby wprowadzić ciągłą ochronę na każdej stacji roboczej dewelopera, gdzie gromadzą się dane uwierzytelniające. GitGuardian podchodzi do tego, rozszerzając zabezpieczenia sekretów wykraczające poza repozytoria kodu na same maszyny deweloperskie.

Atak na LiteLLM wykazał, co się dzieje, gdy dane uwierzytelniające gromadzą się w formie niezaszyfrowanej na stacjach roboczych deweloperów. Oto, co można zrobić, aby ograniczyć tę ekspozycję.

• Zacznij od widoczności. Traktuj stację roboczą jako główne środowisko skanowania sekretów, a nie myśl o tym na końcu. Użyj narzędzia ggshield, aby przeskanować lokalne repozytoria w poszukiwaniu danych uwierzytelniających, które gdzieś się zaplątały w kodzie lub pozostały w historii Git.
• Przeskanuj ścieżki systemowe, gdzie gromadzą się sekrety poza Gitem: przestrzenie robocze projektów, pliki dotfiles, wyniki budowy i foldery agentów, gdzie lokalne narzędzia AI generują logi, cache i „pamięć”.
• Nie zakładaj, że zmienne środowiskowe są bezpieczne tylko dlatego, że nie znajdują się w plikach. Profile powłoki, ustawienia IDE i generowane artefakty często utrzymują wartości środowiskowe na dysku nieograniczenie. Przeskanuj te miejsca tak samo, jak skanowałbyś repozytoria.

Dodaj pre-commit hooks ggshield, aby zapobiec tworzeniu nowych wycieków w commitach, jednocześnie sprzątając stare. To zamienia wykrywanie sekretów w domyślną barierę, która wychwytuje błędy, zanim staną się incydentami.

Wykrywanie bez naprawy to tylko hałas. Gdy dochodzi do wycieku danych uwierzytelniających, usunięcie problemu zazwyczaj wiąże się z koordynacją wielu zespołów: bezpieczeństwo identyfikuje zagrożenie, infrastruktura odpowiada za usługę, pierwotny deweloper mógł opuścić firmę, a zespoły produktowe obawiają się o przerwy w produkcji. Bez jasnego podziału odpowiedzialności i automatyzacji procesów, usunięcie problemu staje się ręcznym procesem, który jest zaniedbywany.

Rozwiązanie polega na traktowaniu sekretów jako zarządzanych tożsamości z określoną odpowiedzialnością, politykami cyklu życia i zautomatyzowanymi ścieżkami naprawy. Przenieś dane uwierzytelniające do scentralizowanej infrastruktury skarbca, gdzie zespoły bezpieczeństwa mogą egzekwować harmonogram obrotu, polityki dostępu i monitorowanie użytkowania. Zintegruj zarządzanie incydentami z istniejącymi systemami biletowymi, aby naprawa następowała w kontekście, a nie wymagała ciągłej zmiany narzędzi.

Narzędzia agentowe mogą czytać pliki, uruchamiać polecenia i przenosić dane. W przypadku agentów w stylu OpenClaw, „pamięć” to po prostu pliki na dysku (SOUL.md, MEMORY.md) przechowywane w przewidywalnych lokalizacjach. Nigdy nie wklejaj danych uwierzytelniających do czatów agentów, nie ucz agenta sekretów „na później”, a także regularnie skanuj pliki pamięci agentów jako zbiory wrażliwych danych.

Najszybszym sposobem na ograniczenie rozprzestrzenienia sekretów jest usunięcie potrzeby posługiwania się całymi kategoriami udostępnianych danych uwierzytelniających. Po stronie ludzkiej przyjmij WebAuthn (klucze dostępu) jako zamiennik haseł. Po stronie obciążeń, migracja do federacji OIDC sprawi, że pipeline’y przestaną polegać na przechowywanych kluczach chmurowych i sekretach kont usług.

Zacznij od najwyżej ryzykownych ścieżek, gdzie wyciek danych uwierzytelniających przynosi największe straty, a następnie rozszerzaj działania. Przenieś dostęp deweloperów do kluczy dostępu oraz migruj przepływy pracy CI/CD do autoryzacji opartej na OIDC.

Jeśli nie możesz jeszcze wyeliminować sekretów, spraw, aby były one krótkotrwałe i automatycznie wymieniane. Użyj SPIFFE do wydawania dokumentów tożsamości kryptograficznych (SVID), które rotują automatycznie, zamiast polegać na statycznych kluczach API.

Rozpocznij od kluczy chmurowych o długim okresie ważności, tokenów wdrożeniowych i danych uwierzytelniających usług, które deweloperzy przechowują lokalnie dla wygody. Przejdź do tokenów o krótkim okresie ważności, automatycznych rotacji i wzorców tożsamości obciążenia. Każda migracja to jeden mniej trwały sekret, który może zostać skradziony i wykorzystany przeciwko tobie.

Celem jest ograniczenie wartości, którą napastnik może wydobyć z udanego dostępu do maszyny dewelopera.

Honeytokens zapewniają tymczasową ochronę. Umieść atrapowe dane uwierzytelniające w lokalizacjach, które napastnicy systematycznie celują: katalogi domowe deweloperów, popularne ścieżki konfiguracyjne oraz pamięci agenta. Gdy zostaną zebrane i zweryfikowane, te tokeny generują natychmiastowe powiadomienia, skracając czas wykrywania z „odkrycia uszkodzeń po tygodniach” na „złapanie ataków podczas ich rozwoju.” To nie jest stan końcowy, ale zmienia okno reakcji, podczas gdy systematyczne sprzątanie trwa.

Stacje robocze deweloperów stanowią teraz część krytycznej infrastruktury. Znajdują się na przecięciu uprawnień, zaufania i wykonania. Incydent z LiteLLM udowodnił, że przeciwnicy rozumieją to lepiej niż większość programów zabezpieczających. Organizacje, które będą traktować maszyny deweloperów z taką samą dyscypliną zarządzania, jaką już zastosowano do systemów produkcyjnych, będą tymi, które przetrwają kolejną kompromitację łańcucha dostaw.