Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla zespołów deweloperskich i organizacji opierających proces wytwarzania na otwartych ekosystemach pakietów. Kampania SleeperGem pokazuje, że rejestr RubyGems może zostać wykorzystany do dystrybucji złośliwego kodu podszywającego się pod legalne biblioteki i narzędzia używane w codziennej pracy programistów.
W tym przypadku celem nie były wyłącznie pipeline’y CI/CD, lecz przede wszystkim stacje robocze deweloperów. To istotna zmiana perspektywy, ponieważ właśnie na takich hostach często znajdują się klucze SSH, tokeny dostępowe, poświadczenia chmurowe oraz inne sekrety pozwalające napastnikom rozszerzyć zasięg kompromitacji.
W skrócie
- Badacze ujawnili kampanię SleeperGem wykorzystującą trzy złośliwe pakiety RubyGems.
- Jeden z pakietów podszywał się pod znane narzędzie związane z obsługą poświadczeń Git.
- Dwa kolejne dotyczyły starszych projektów, które po długim okresie bez aktywności otrzymały złośliwe aktualizacje.
- Loader sprawdzał, czy działa w środowisku CI, a po wykryciu stacji roboczej dewelopera pobierał dalsze komponenty infekcji.
- Malware próbował uzyskać trwałość, działać w tle i w wybranych przypadkach eskalować uprawnienia.
Kontekst / historia
Kampania SleeperGem wpisuje się w szerszy trend nadużyć w publicznych rejestrach pakietów open source. Atakujący coraz częściej wykorzystują zaufanie do popularnych ekosystemów, publikując pakiety o mylących nazwach, przejmując porzucone konta maintainerów lub modyfikując starsze projekty, które przestały być aktywnie nadzorowane.
W analizowanym przypadku szczególne znaczenie mają dwa elementy. Po pierwsze, jeden z pakietów został nazwany w sposób przypominający legalne narzędzie używane przez deweloperów, co zwiększało szansę na nieświadomą instalację. Po drugie, część zainfekowanych gemów była przez lata nieaktywna, a następnie otrzymała nowe, złośliwe wydania. To klasyczny przykład wykorzystania „uśpionych” projektów jako nośnika ataku supply chain.
Dodatkowo złośliwy pakiet został dodany jako zależność do innych bibliotek, co zwiększało zasięg kampanii. Oznacza to, że ryzyko nie ograniczało się wyłącznie do ręcznego pobrania podejrzanego gema, ale obejmowało również pośrednią instalację przez drzewo zależności.
Analiza techniczna
Od strony technicznej SleeperGem działał wieloetapowo. Złośliwe wydania pełniły funkcję loaderów, czyli pierwszego komponentu odpowiedzialnego za pobranie i uruchomienie kolejnego etapu infekcji. Po instalacji lub załadowaniu biblioteki kod inicjował kontrole środowiskowe, w tym analizę zmiennych środowiskowych powiązanych z popularnymi systemami CI/CD.
Jeżeli malware wykrywał środowisko buildowe, przerywał działanie. Taka logika zmniejsza ryzyko wykrycia w krótkotrwałych runnerach i jednocześnie kieruje atak na systemy, które najczęściej zawierają trwałe sekrety oraz poświadczenia użytkowników technicznych.
Po zakwalifikowaniu hosta jako maszyny deweloperskiej loader pobierał dwa kolejne artefakty: skrypt powłoki oraz natywny plik wykonywalny. W środowisku Windows wykorzystane miało być uruchomienie przez PowerShell, natomiast w systemach uniksowych skrypt uruchamiał binarkę jako proces działający w tle.
Kolejny etap obejmował ustanowienie trwałości. Złośliwe oprogramowanie konfigurowało mechanizmy ponownego uruchamiania przy użyciu cron oraz usług użytkownika systemd. Taki zestaw technik pozwala osadzić proces w środowisku użytkownika bez konieczności natychmiastowego uzyskania pełnych uprawnień administracyjnych.
Szczególnie niebezpieczny był mechanizm sprawdzania członkostwa w grupach uprzywilejowanych oraz testowania możliwości użycia sudo bez hasła. Jeśli taka konfiguracja była dostępna, skrypt mógł ponownie uruchomić się z prawami roota. W tej fazie malware mogło również pozostawić binarkę setuid podszywającą się pod legalne narzędzie systemowe, co dawało trwały kanał eskalacji uprawnień.
Ważnym sygnałem ostrzegawczym był też model publikacji pakietów. Złośliwe wydania pojawiły się w rejestrze bez odpowiadających im commitów lub tagów w repozytoriach źródłowych, co może wskazywać na kompromitację procesu wydawniczego albo przejęcie kont maintainerskich.
Konsekwencje / ryzyko
Ryzyko związane z kampanią należy ocenić jako wysokie, ponieważ atak był wymierzony w stacje robocze deweloperów. Takie systemy często przechowują dane dostępowe do repozytoriów, chmur publicznych, narzędzi CI/CD, sieci VPN oraz środowisk produkcyjnych. Ich przejęcie może prowadzić do dalszej lateralizacji, sabotażu pipeline’ów, podpisywania złośliwych artefaktów lub wstrzyknięcia backdoora do legalnego kodu.
Dodatkowym problemem jest selektywność malware. Unikanie działania w środowiskach CI zmniejsza prawdopodobieństwo wykrycia przez standardowe mechanizmy bezpieczeństwa skupione na buildach i automatycznym sandboxingu. W praktyce ciężar obrony przesuwa się więc na ochronę stacji roboczych użytkowników technicznych.
Jeżeli złośliwy komponent uzyskał dostęp do sudo bez hasła lub pozostawił plik setuid, incydent należy traktować jako pełną kompromitację hosta. W takiej sytuacji samo usunięcie pakietu RubyGems nie jest wystarczające i konieczna staje się szersza analiza powłamaniowa oraz rotacja wszystkich sekretów dostępnych na urządzeniu.
Rekomendacje
Organizacje korzystające z RubyGems powinny przeprowadzić pilny przegląd zależności pod kątem wskazanych pakietów i ich wersji. Należy sprawdzić zarówno pliki Gemfile oraz Gemfile.lock, jak i zależności pośrednie pobrane na stacje robocze oraz zapisane wewnętrznie w cache’ach artefaktów.
W środowiskach, w których wykryto instalację zainfekowanych gemów, host powinien zostać odizolowany i potraktowany jako potencjalnie naruszony. Działania reagowania powinny obejmować:
- usunięcie złośliwych pakietów i wszystkich pobranych przez nie komponentów,
- weryfikację katalogów użytkownika pod kątem pozostawionych skryptów i binarek,
- kontrolę wpisów cron oraz usług użytkownika systemd,
- sprawdzenie obecności nieautoryzowanych plików setuid,
- analizę logów shell, sudo, EDR i systemowych,
- rotację haseł, tokenów API, kluczy SSH i poświadczeń chmurowych.
Po stronie prewencji warto wdrożyć kilka stałych kontroli bezpieczeństwa. Kluczowe znaczenie ma pinning wersji, formalny proces zatwierdzania nowych zależności oraz skanowanie pakietów pod kątem typosquattingu, przejęć kont maintainerów i nietypowych zmian publikacyjnych. Należy również ograniczać lokalne przechowywanie sekretów na stacjach deweloperskich i stosować rozwiązania oferujące krótkotrwałe tokeny dostępu.
Z perspektywy hardeningu szczególnie ważne jest wyłączenie konfiguracji sudo bez hasła tam, gdzie nie jest to absolutnie konieczne, monitorowanie tworzenia plików setuid oraz alertowanie o nowych zadaniach cron i usługach systemd uruchamianych w przestrzeni użytkownika. Rozszerzenie telemetrii EDR o zdarzenia związane z menedżerami pakietów i narzędziami developerskimi może znacząco poprawić szanse na szybką detekcję podobnych kampanii.
Podsumowanie
SleeperGem to dojrzały przykład ataku supply chain skierowanego bezpośrednio w środowiska programistyczne. Złośliwe pakiety RubyGems łączyły podszywanie się pod legalne komponenty, wykorzystanie porzuconych projektów oraz rozprzestrzenianie przez zależności pośrednie, aby uzyskać dostęp do stacji roboczych deweloperów.
Techniki antyanalityczne, mechanizmy trwałości przez cron i systemd oraz próby eskalacji uprawnień pokazują, że celem kampanii nie było jedynie jednorazowe wykonanie kodu, ale trwała kompromitacja hosta. Dla zespołów bezpieczeństwa to kolejny sygnał, że ochrona łańcucha dostaw musi obejmować nie tylko pipeline’y CI/CD, lecz także integralność publikacji pakietów, konta maintainerów i bezpieczeństwo samych stacji roboczych deweloperów.