GemStuffer: jak RubyGems stał się kanałem exfiltracji danych z publicznych serwisów - Security Bez Tabu

GemStuffer: jak RubyGems stał się kanałem exfiltracji danych z publicznych serwisów

Cybersecurity news

Wprowadzenie do problemu / definicja

Ekosystemy pakietów open source od lat stanowią fundament nowoczesnego tworzenia oprogramowania, ale jednocześnie pozostają jednym z najważniejszych obszarów ryzyka w łańcuchu dostaw. Kampania określana jako GemStuffer pokazuje mniej oczywisty sposób nadużycia rejestru pakietów: RubyGems nie został wykorzystany wyłącznie do dystrybucji kodu, lecz jako magazyn i pośredni kanał transportowy dla zebranych danych.

To istotna zmiana perspektywy dla zespołów bezpieczeństwa. W praktyce oznacza bowiem, że zagrożenie nie ogranicza się do instalacji podejrzanych bibliotek, lecz obejmuje również sam proces publikowania pakietów do publicznych rejestrów.

W skrócie

Badacze opisali kampanię obejmującą ponad 100 pakietów w RubyGems, których celem nie była klasyczna infekcja systemu ofiary. Zamiast tego pakiety pobierały publicznie dostępne dane z wybranych brytyjskich portali samorządowych, a następnie osadzały je w archiwach .gem publikowanych do rejestru.

Mechanizm opierał się na automatycznym budowaniu i wysyłaniu pakietów z użyciem osadzonych kluczy API RubyGems. Dzięki temu operator nie musiał utrzymywać tradycyjnej infrastruktury C2 — wystarczyło późniejsze pobranie własnych pakietów z rejestru i odzyskanie zapisanych w nich danych.

  • ponad 100 pakietów powiązanych z kampanią,
  • wykorzystanie RubyGems jako „dead dropu” dla danych,
  • brak potrzeby utrzymywania klasycznego serwera dowodzenia,
  • użycie legalnych funkcji publikacji pakietów w sposób niezgodny z przeznaczeniem.

Kontekst / historia

Ataki na łańcuch dostaw oprogramowania najczęściej kojarzą się z typosquattingiem, przejęciem kont maintainerów, kompromitacją bibliotek lub publikacją pakietów wykradających sekrety środowiskowe. Rejestry takie jak npm, PyPI czy RubyGems od kilku lat pozostają więc pod szczególną obserwacją zespołów AppSec i DevSecOps.

GemStuffer wyróżnia się jednak celem operacyjnym. Zamiast maksymalizować liczbę instalacji złośliwego pakietu, operator publikował liczne pakiety o minimalnej wartości użytkowej. Według analiz zawarte w nich skrypty pobierały treści z publicznych portali londyńskich dzielnic, takich jak Lambeth, Wandsworth i Southwark, obejmujące m.in. kalendarze rad, agendy i odnośniki do komisji.

Sam charakter pobieranych danych nie wskazuje na klasyczną kradzież informacji wrażliwych. To utrudnia jednoznaczną ocenę motywacji aktora zagrożenia, ale nie zmniejsza znaczenia samej techniki.

Analiza techniczna

Z technicznego punktu widzenia kampania jest interesująca, ponieważ traktuje RubyGems jako warstwę składowania i transportu danych. W analizowanych próbkach pakiety zawierały skrypty realizujące pełny łańcuch operacji — od pobrania treści z publicznych stron po publikację nowego artefaktu do rejestru.

  • pobranie stron z publicznych serwisów samorządowych,
  • wyodrębnienie wybranych danych z HTML,
  • osadzenie zebranych informacji w nowo tworzonym archiwum .gem,
  • opublikowanie pakietu z użyciem zakodowanych poświadczeń API,
  • późniejsze pobranie pakietu przez operatora i ekstrakcja danych.

W części wariantów malware tworzył tymczasowe środowisko poświadczeń w katalogu /tmp, nadpisywał zmienną HOME, budował pakiet lokalnie, a następnie wykonywał publikację do rejestru. Inne próbki korzystały bezpośrednio z API RubyGems, pomijając standardowe użycie klienta gem.

To podejście ogranicza potrzebę używania własnej infrastruktury. Legalna platforma publiczna przejmuje rolę pośrednika, co może utrudniać wykrywanie oparte wyłącznie na reputacji domen, analizie ruchu do znanych serwerów C2 czy prostych regułach sieciowych.

Szczególnie ważny jest aspekt uwierzytelniania. RubyGems wspiera publikowanie pakietów z użyciem kluczy API i automatyzację procesu gem push, co jest powszechne w pipeline’ach CI/CD. GemStuffer pokazał, że dokładnie te legalne funkcje mogą zostać wykorzystane do działań wykraczających poza typowy model dystrybucji oprogramowania.

Konsekwencje / ryzyko

Najważniejsze ryzyko nie wynika obecnie z wartości samych danych osadzonych w pakietach, lecz z potwierdzenia, że publiczny rejestr pakietów może zostać użyty do innych działań niż dystrybucja kodu. To rozszerza model zagrożeń dla organizacji tworzących i publikujących oprogramowanie.

W praktyce oznacza to, że wiele zespołów monitoruje zależności pobierane do środowisk, ale znacznie rzadziej analizuje operacje publikacji wychodzącej. Jeśli stacja deweloperska lub pipeline CI posiada możliwość wypychania pakietów do publicznego rejestru, kanał ten może zostać nadużyty do przesyłania danych, artefaktów, wyników skanów, sekretów lub fragmentów kodu źródłowego.

Dodatkowe ryzyko dotyczy rozwoju tej techniki. Dzisiejszy scenariusz oparty na danych publicznych może jutro zostać przeniesiony na informacje znacznie bardziej wrażliwe, w tym tokeny dostępowe, konfiguracje środowisk, dane klientów czy własność intelektualną organizacji.

Rekomendacje

Organizacje korzystające z Ruby, RubyGems i zautomatyzowanych pipeline’ów publikacji powinny potraktować ten przypadek jako sygnał do przeglądu własnych mechanizmów kontroli. Kluczowe znaczenie ma nie tylko bezpieczeństwo instalowanych pakietów, ale również bezpieczeństwo procesu ich publikowania.

  • zinwentaryzować wszystkie stacje deweloperskie, joby CI/CD i konta serwisowe z uprawnieniami do publikacji pakietów,
  • ograniczyć możliwość gem push wyłącznie do zatwierdzonych systemów i zaufanych pipeline’ów,
  • stosować klucze API o minimalnym zakresie uprawnień oraz regularną rotację sekretów,
  • włączyć silne mechanizmy uwierzytelniania tam, gdzie jest to operacyjnie możliwe,
  • monitorować nietypowe publikacje, częste inkrementacje wersji i masowe tworzenie nowych pakietów,
  • przeglądać katalogi tymczasowe, w tym /tmp, pod kątem artefaktów budowania pakietów,
  • blokować publikacje wychodzące do publicznych rejestrów w pipeline’ach, które nie pełnią funkcji wydawniczej,
  • wdrożyć polityki DLP i kontrolę egress dla środowisk deweloperskich,
  • rozszerzyć procesy AppSec o monitoring aktywności publisherskiej, a nie tylko zależności pobieranych przez programistów.

Z operacyjnego punktu widzenia warto również rozdzielić tożsamości używane do budowania, testowania i publikacji pakietów. Ogranicza to skutki kompromitacji pojedynczego tokenu lub jednego elementu pipeline’u.

Podsumowanie

GemStuffer nie wygląda dziś na kampanię o wysokiej skuteczności operacyjnej, ale ma duże znaczenie strategiczne. Pokazuje, że rejestry pakietów open source mogą zostać wykorzystane nie tylko jako kanał dostarczania złośliwego kodu, lecz także jako infrastruktura pośrednicząca w exfiltracji i składowaniu danych.

Dla zespołów bezpieczeństwa oznacza to konieczność poszerzenia modelu obrony. Monitorować należy nie tylko to, co organizacja pobiera z rejestrów, ale również to, co i w jaki sposób do nich publikuje. W realiach nowoczesnego DevSecOps kontrola procesu wydawniczego staje się pełnoprawnym elementem ochrony łańcucha dostaw oprogramowania.

Źródła