Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo łańcucha dostaw oprogramowania pozostaje jednym z najważniejszych wyzwań dla organizacji rozwijających aplikacje w modelu DevOps. Najnowszy incydent pokazuje, że napastnicy coraz skuteczniej łączą klasyczne techniki kompromitacji zależności open source z atakami na pipeline’y CI/CD oraz narzędzia deweloperskie wspierane przez AI. Celem nie jest już wyłącznie infekcja stacji roboczej, ale przede wszystkim przejęcie sekretów, tokenów i danych uwierzytelniających obecnych w środowiskach budowania i wdrożeń.
W opisanym przypadku zagrożenie przyjęło dwie formy. Pierwsza dotyczyła złośliwych crate’ów Rust opublikowanych w repozytorium crates.io, które podszywały się pod narzędzia związane z synchronizacją czasu. Druga obejmowała zautomatyzowaną kampanię wymierzoną w błędnie skonfigurowane workflow GitHub Actions, gdzie atakujący wykorzystywał pull requesty do uruchamiania złośliwego kodu w kontekście CI.
W skrócie
Badacze zidentyfikowali pięć złośliwych pakietów Rust, które wyszukiwały pliki .env i eksfiltrowały ich zawartość do infrastruktury kontrolowanej przez operatora kampanii. Pakiety udawały nieszkodliwe biblioteki pomocnicze i mogły zostać pobrane zarówno przez deweloperów, jak i przez zautomatyzowane procesy budowania.
Równolegle ujawniono kampanię wykorzystującą bota określanego jako hackerbot-claw, który automatycznie wyszukiwał repozytoria z podatnymi workflow CI/CD. W praktyce oznaczało to możliwość przejęcia tokenów, dalszej kompromitacji repozytoriów oraz wykorzystania legalnych narzędzi użytkownika, w tym agentów AI, do rekonesansu i eksfiltracji danych.
- Pięć złośliwych crate’ów Rust podszywało się pod narzędzia czasu.
- Głównym celem były pliki
.envzawierające sekrety i poświadczenia. - Bot AI atakował publiczne repozytoria z błędnie skonfigurowanymi GitHub Actions.
- W jednym z incydentów doszło do przejęcia tokenu i kompromitacji łańcucha publikacji rozszerzenia.
- Atak pokazał rosnącą rolę narzędzi AI jako pośrednika w operacjach ofensywnych.
Kontekst / historia
Złośliwe crate’y zostały opublikowane pod nazwami, które nie wzbudzały natychmiastowych podejrzeń. Wśród nich wskazywano między innymi chrono_anchor, dnp3times, time_calibrator, time_calibrators oraz time-sync. Tego rodzaju nazewnictwo wpisuje się w typowy schemat niewielkich bibliotek pomocniczych, przez co łatwo mogło zostać uznane za wiarygodne.
Atak ten dobrze wpisuje się w utrwalony trend nadużyć w ekosystemie open source, gdzie przestępcy publikują pakiety o pozornie użytecznych nazwach, licząc na ich automatyczne pobranie przez programistów, systemy budujące lub mechanizmy zależności pośrednich. Szczególnie niebezpieczny okazał się wybór plików .env jako celu, ponieważ to właśnie tam bardzo często przechowywane są klucze API, dane dostępowe do chmury, poświadczenia baz danych i tokeny używane przez pipeline’y wdrożeniowe.
Drugi element kampanii dotyczył publicznych repozytoriów korzystających z GitHub Actions. W tym scenariuszu napastnik nie musiał infekować maszyny ofiary tradycyjnym malware. Wystarczało znalezienie podatnego workflow, przygotowanie pozornie niewinnego pull requestu i doprowadzenie do wykonania złośliwego ładunku w kontekście uprzywilejowanego procesu CI/CD.
Analiza techniczna
Mechanizm działania złośliwych pakietów Rust był relatywnie prosty, ale bardzo skuteczny. Po uruchomieniu biblioteki przeszukiwały środowisko pod kątem plików .env, a następnie wysyłały ich zawartość do zewnętrznej infrastruktury kontrolowanej przez atakującego. Cztery z pięciu crate’ów realizowały ten schemat w sposób bezpośredni, natomiast jeden z nich stosował dodatkową obfuskację, aby utrudnić wykrycie prawdziwej funkcji kodu.
W przypadku pakietu chrono_anchor logika odpowiedzialna za eksfiltrację została ukryta w module pomocniczym i wywoływana z funkcji opisanej jako opcjonalna synchronizacja. Taki zabieg znacząco utrudniał szybką ocenę ryzyka podczas pobieżnego przeglądu zależności. Istotne jest też to, że pakiety nie skupiały się na trwałym osadzeniu w systemie. Zamiast tego wykorzystywały naturalny cykl uruchamiania aplikacji deweloperskich i procesów CI, co pozwalało na ponowne pozyskiwanie sekretów przy kolejnych wykonaniach.
Scenariusz ataku na GitHub Actions był bardziej zaawansowany. Bot automatycznie wyszukiwał publiczne repozytoria z workflow uruchamianymi dla pull requestów, następnie tworzył fork, przygotowywał złośliwy payload i otwierał pull request wyglądający na drobną, nieszkodliwą poprawkę. Właściwy ładunek mógł zostać ukryty w nazwie gałęzi, nazwie pliku lub w logice wykonywanej przez skrypt CI. Jeśli workflow było błędnie skonfigurowane, pipeline uruchamiał się z uprawnieniami umożliwiającymi dostęp do sekretów.
Szczególnie ważny był incydent związany z repozytorium aquasecurity/trivy. Według ujawnionych analiz atakujący wykorzystał workflow typu pull_request_target do przejęcia Personal Access Token, a następnie użył go do rozszerzenia kompromitacji. Kolejnym etapem była publikacja złośliwych wersji rozszerzenia Trivy dla Visual Studio Code w rejestrze Open VSX.
Zmodyfikowane wydania rozszerzenia zawierały logikę pozwalającą uruchamiać lokalne narzędzia i agentów AI do kodowania, takich jak Claude, Codex, Gemini czy GitHub Copilot CLI, w trybach o wysokich uprawnieniach. Umożliwiało to przeprowadzenie szerokiego rekonesansu lokalnego środowiska, zebranie informacji o plikach, konfiguracji i poświadczeniach, a następnie zapisanie wyników z użyciem legalnie uwierzytelnionego kontekstu użytkownika. To istotna zmiana jakościowa, ponieważ eksfiltracja nie musi już polegać na bezpośrednim wysyłaniu danych do serwera C2. Może zostać przeprowadzona za pośrednictwem narzędzi już zaufanych przez ofiarę.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tej kampanii jest wyciek sekretów deweloperskich. Przejęcie plików .env może oznaczać utratę kontroli nad kontami chmurowymi, bazami danych, repozytoriami kodu, rejestrami pakietów i środowiskami wdrożeniowymi. W praktyce pojedynczy incydent w projekcie deweloperskim może szybko przekształcić się w pełnoskalowy atak na łańcuch dostaw.
Ryzyko rośnie szczególnie tam, gdzie organizacje wciąż przechowują długoterminowe poświadczenia w zmiennych środowiskowych lub przyznają tokenom CI/CD zbyt szerokie uprawnienia. Jeśli taki token umożliwia publikację pakietów, obrazów kontenerowych lub release’ów, atakujący może przejść od kradzieży sekretu do dystrybucji złośliwych artefaktów sygnowanych przez zaufanego dostawcę.
Drugim wymiarem zagrożenia jest wykorzystanie agentów AI jako pośredników w rekonesansie i eksfiltracji. Narzędzia tego typu często mają dostęp do repozytorium, terminala, systemu plików i kontekstu uwierzytelnienia użytkownika. Oznacza to, że z perspektywy obrony nie mogą być już traktowane wyłącznie jako dodatki zwiększające produktywność, lecz jako element powierzchni ataku wymagający kontroli, monitorowania i segmentacji uprawnień.
Rekomendacje
Organizacje powinny w pierwszej kolejności przeprowadzić przegląd używanych zależności Rust i ustalić, czy wskazane crate’y były pobierane, kompilowane lub cache’owane w środowiskach deweloperskich i runnerach CI. W przypadku wykrycia użycia należy założyć możliwość eksfiltracji danych i niezwłocznie rozpocząć rotację wszystkich kluczy, tokenów i sekretów dostępnych w zagrożonym środowisku.
W obszarze CI/CD kluczowe jest ograniczenie wykonywania workflow dla pull requestów pochodzących z zewnętrznych forków, zwłaszcza jeśli uruchamiane zadania mają dostęp do sekretów. Należy także dokładnie zweryfikować wykorzystanie mechanizmu pull_request_target, rozdzielić workflow testowe od publikacyjnych i stosować zasadę najmniejszych uprawnień dla tokenów automatyzacji.
- Przeskanować projekty i cache pod kątem wskazanych złośliwych crate’ów.
- Rotować wszystkie sekrety, które mogły znajdować się w plikach
.env. - Ograniczyć lub przebudować workflow uruchamiane dla pull requestów z forków.
- Blokować nieautoryzowany ruch wychodzący z runnerów CI/CD.
- Stosować krótkotrwałe poświadczenia zamiast statycznych sekretów.
- Oddzielić środowiska build, testów, publikacji i wdrożeń.
- Monitorować nietypowe pull requesty, nazwy gałęzi i zmiany w workflow.
- Przeprowadzić audyt rozszerzeń IDE oraz źródeł ich instalacji.
- Ograniczyć uprawnienia lokalnych agentów AI do systemu plików i poświadczeń.
Jeżeli w organizacji mogły zostać zainstalowane złośliwe wersje rozszerzeń, warto sprawdzić historię działań w kontach GitHub, użycie GitHub CLI oraz obecność nieoczekiwanych repozytoriów, commitów lub publikacji artefaktów. Reakcja powinna obejmować również analizę logów CI/CD i rejestrów pakietów pod kątem działań wykonywanych przez skompromitowane tokeny.
Podsumowanie
Opisany incydent pokazuje, że współczesne ataki na łańcuch dostaw nie muszą opierać się na zaawansowanym malware działającym rezydentnie w systemie. Wystarczy pozornie użyteczna biblioteka open source, błędnie skonfigurowany workflow CI/CD lub rozszerzenie IDE działające w zaufanym kontekście użytkownika. Szczególnie niepokojące jest to, że narzędzia AI zaczynają pełnić rolę operacyjnego komponentu ataku, wspierając rekonesans, analizę środowiska i pośrednią eksfiltrację danych.
Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia modelu ochrony. Nie wystarczy już monitorowanie kodu źródłowego i infrastruktury pipeline’ów. Obrona musi obejmować także zależności open source, środowiska deweloperskie, rozszerzenia IDE, tokeny automatyzacji oraz sposób, w jaki organizacja dopuszcza i nadzoruje lokalne narzędzia AI.