Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych zagrożeń dla firm rozwijających aplikacje i utrzymujących środowiska CI/CD. W opisywanym incydencie początkowo zakładano, że głównym źródłem kompromitacji był pakiet LiteLLM, jednak późniejsze ustalenia wskazały na wcześniejszy etap kampanii powiązany z ekosystemem Trivy.
Ta zmiana atrybucji ma duże znaczenie praktyczne. Wpływa nie tylko na ocenę skali naruszenia, ale też na sposób prowadzenia analizy powłamaniowej, rotacji poświadczeń oraz zabezpieczania procesów publikacji pakietów i budowania oprogramowania.
W skrócie
Z dostępnych analiz wynika, że ponad 95% ekspozycji nastąpiło jeszcze przed pojawieniem się skażonych wersji LiteLLM. Oznacza to, że widoczny publicznie incydent związany z tym pakietem był jedynie późniejszym etapem większej kampanii.
Złośliwy kod działał jak robak, którego celem była kradzież sekretów deweloperskich. Atakujący pozyskiwali między innymi tokeny, klucze API, poświadczenia CI/CD, klucze chmurowe oraz inne dane uwierzytelniające, a następnie wykorzystywali je do dalszego rozprzestrzeniania ataku.
- skala ekspozycji objęła ponad 2,5 tys. organizacji,
- główny wektor wejścia był powiązany z Trivy, a nie LiteLLM,
- celem operacji była kradzież sekretów i dalsza propagacja w pipeline’ach,
- zagrożenie dotyczyło wielu platform CI/CD i repozytoriów pakietów.
Kontekst / historia
W pierwszej fazie incydentu szczególne zainteresowanie wzbudził LiteLLM, ponieważ do rejestru opublikowano dwie złośliwe wersje pakietu. Ponieważ skażone wydania były publicznie dostępne przez krótki czas, to właśnie one stały się najbardziej widocznym elementem całej kampanii.
Z czasem analiza osi czasu wykazała jednak, że masowe zbieranie danych i kompromitacja środowisk rozpoczęły się wcześniej. Kluczowe ślady prowadziły do aktywności związanej z Trivy, a LiteLLM okazał się raczej kolejnym etapem eskalacji i propagacji niż pierwotnym źródłem naruszenia.
Incydent powiązano z aktywnością aktora określanego jako TeamPCP, który był już wcześniej kojarzony z operacjami supply chain wykorzystującymi mechanizmy samoistnego rozprzestrzeniania. To dodatkowo wzmacnia ocenę, że mieliśmy do czynienia z kampanią zaprojektowaną pod kątem efektu domina w ekosystemie open source.
Analiza techniczna
Od strony technicznej kampania wpisuje się w model wieloetapowego ataku na proces dostarczania oprogramowania. Po uruchomieniu zainfekowanego komponentu złośliwy kod wyszukiwał sekrety obecne w środowiskach build i deployment, a następnie eksportował je do infrastruktury kontrolowanej przez atakujących.
W przypadku LiteLLM istotną rolę odgrywał plik typu .pth. W ekosystemie Pythona taki mechanizm może doprowadzić do automatycznego wykonania kodu przy uruchomieniu interpretera, nawet jeśli sam pakiet nie został jawnie zaimportowany przez aplikację. Z perspektywy obrony jest to szczególnie niebezpieczne, ponieważ pozwala ominąć część standardowych założeń bezpieczeństwa dotyczących instalacji zależności.
Najważniejszym elementem kampanii była jednak zdolność do dalszej propagacji. Po przejęciu tokenów i kluczy deweloperskich napastnicy mogli uzyskiwać dostęp do kolejnych repozytoriów, workflow, kont publikujących pakiety i artefaktów release. W rezultacie pojedyncze przejęcie zaufanego komponentu mogło prowadzić do kompromitacji następnych organizacji oraz zależnych projektów.
Według analiz aktywność obejmowała wiele popularnych platform automatyzacji, takich jak GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI czy Buildkite. To pokazuje, że problem nie był ograniczony do jednego dostawcy, lecz dotyczył całego ekosystemu nowoczesnego wytwarzania oprogramowania.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem incydentu jest utrata sekretów, które mogą umożliwić kolejne włamania długo po usunięciu pierwotnego źródła infekcji. Skradzione tokeny CI/CD, klucze dostępu do chmury, webhooki i klucze prywatne dają atakującym możliwość działania z uprawnieniami organizacji.
Ryzyko nie ogranicza się do jednorazowej ekspozycji. Jeśli złośliwy komponent działał w środowisku przez dłuższy czas, mógł stale pobierać nowe dane, modyfikować procesy build lub przygotowywać grunt pod kolejne etapy ataku, w tym publikację złośliwych pakietów i przejęcie kont usługowych.
Dodatkowym zagrożeniem jest wtórne wykorzystanie wykradzionych poświadczeń. Nawet po zakończeniu medialnej fazy incydentu organizacje muszą zakładać możliwość późniejszych prób logowania, sabotażu pipeline’ów, ataków ransomware albo nieautoryzowanej publikacji nowych artefaktów.
Rekomendacje
Organizacje korzystające z Trivy, LiteLLM lub zbliżonych pipeline’ów powinny potraktować sprawę jako potencjalne naruszenie integralności środowiska deweloperskiego. Kluczowym krokiem jest pełna rotacja wszystkich sekretów wykorzystywanych w procesach budowania, testowania i publikacji.
- unieważnienie i ponowne wydanie tokenów repozytoryjnych, kluczy API oraz poświadczeń kont usługowych,
- przegląd logów pobrań pakietów, historii buildów i uruchomień workflow,
- weryfikacja zmian w plikach zależności, tagach, release’ach i konfiguracji pipeline’ów,
- skanowanie środowisk pod kątem nieautoryzowanych plików inicjalizacyjnych, w tym
.pth, - wdrożenie krótkiego czasu życia tokenów i poświadczeń tymczasowych,
- ograniczenie uprawnień publikacji pakietów do silnie chronionych, dedykowanych kont,
- podpisywanie artefaktów i kontrola ich pochodzenia,
- przygotowanie procedur incident response dla incydentów supply chain.
Z operacyjnego punktu widzenia równie ważne jest monitorowanie wycieku sekretów oraz nietypowej aktywności w systemach SCM i CI/CD. W praktyce samo usunięcie złośliwego pakietu nie wystarczy, jeśli wcześniej doszło do przejęcia zaufanych procesów publikacji lub kompromitacji tożsamości technicznych.
Podsumowanie
Najważniejszy wniosek z tej sprawy jest prosty: publicznie nagłośniony epizod z LiteLLM nie był główną przyczyną masowej ekspozycji. Rzeczywiste źródło kompromitacji było związane z wcześniejszym etapem kampanii w ekosystemie Trivy, a sam atak miał charakter robaka ukierunkowanego na kradzież sekretów i dalsze rozprzestrzenianie.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że incydenty supply chain trzeba analizować szerzej niż przez pryzmat pojedynczego złośliwego pakietu. Kluczowe pozostają integralność pipeline’ów, pełna inwentaryzacja poświadczeń, szybka rotacja dostępu i weryfikacja pochodzenia wszystkich krytycznych artefaktów.