Atak na łańcuch dostaw uderza w dziesiątki tysięcy repozytoriów GitHub

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą do najpoważniejszych zagrożeń dla organizacji rozwijających i utrzymujących nowoczesne aplikacje. Zamiast przełamywać zabezpieczenia pojedynczej firmy, napastnicy kompromitują wspólny element ekosystemu, taki jak zależność open source, konto deweloperskie, pipeline CI/CD lub workflow automatyzacji. Dzięki temu jeden skuteczny incydent może szybko objąć wiele projektów, zespołów i środowisk.

Opisana kampania pokazuje, że platformy takie jak GitHub pozostają krytycznym punktem ryzyka. Przejęcie zaufanej tożsamości oraz wykorzystanie mechanizmów automatyzacji pozwala atakującym rozprzestrzeniać złośliwe zmiany na dużą skalę i pozyskiwać cenne sekrety wykorzystywane w procesach wytwarzania oprogramowania.

W skrócie

Badacze bezpieczeństwa opisali kampanię supply chain, która objęła dziesiątki tysięcy repozytoriów GitHub. Mechanizm ataku polegał na dodawaniu złośliwych workflow do projektów, do których przejęte konta miały uprawnienia zapisu.

Celem operacji była kradzież sekretów CI/CD, tokenów dostępowych, poświadczeń chmurowych oraz danych uwierzytelniających zapisanych w kodzie, historii Git i konfiguracjach automatyzacji. Skala incydentu potwierdza, że pojedyncza kompromitacja konta deweloperskiego może doprowadzić do efektu domina w całym łańcuchu dostaw oprogramowania.

Kontekst / historia

W ostatnich latach ataki na software supply chain stały się jednym z dominujących trendów w krajobrazie zagrożeń. Wcześniejsze incydenty obejmowały złośliwe pakiety publikowane do popularnych rejestrów, przejęcia kont maintainerów, nadużycia w GitHub Actions oraz kompromitacje środowisk build i release. Wspólnym mianownikiem tych zdarzeń jest nadużycie zaufania do procesów i komponentów uznawanych za wewnętrzne lub sprawdzone.

W analizowanej kampanii szczególnie istotny był jej propagacyjny charakter. Atak nie zatrzymywał się na jednym repozytorium, lecz wykorzystywał istniejące uprawnienia do wprowadzania zmian w kolejnych projektach. Takie podejście znacząco zwiększa tempo rozprzestrzeniania się zagrożenia i utrudnia wykrycie, ponieważ złośliwe działania mogą wyglądać jak rutynowe zmiany administracyjne lub standardowe aktualizacje workflow.

Analiza techniczna

Technicznie operacja koncentrowała się wokół GitHub Actions i workflow uruchamianych w kontekście repozytorium. Napastnicy dodawali pliki do katalogu .github/workflows/, nadając im nazwy sugerujące legalne zadania związane z bezpieczeństwem, audytem lub kontrolą jakości. W rzeczywistości workflow służyły do wyszukiwania i eksfiltracji sekretów.

Złośliwe mechanizmy wykorzystywały uprawnienia dostępne dla repozytorium oraz dla samego procesu CI/CD. To pozwalało na przeszukiwanie kodu źródłowego, historii commitów i konfiguracji pipeline’ów w poszukiwaniu tokenów, kluczy API i danych chmurowych. W niektórych scenariuszach workflow mogły także uzyskać dostęp do sekretów środowiskowych udostępnionych przez organizację.

dodawanie złośliwych plików workflow do repozytoriów,
uruchamianie kodu w kontekście istniejących uprawnień projektu,
przeszukiwanie kodu i historii Git pod kątem sekretów,
pozyskiwanie tokenów, kluczy API i poświadczeń cloud,
wykorzystanie zdobytych danych do ruchu bocznego między repozytoriami.

Szczególnie niebezpieczne jest to, że workflow CI/CD często działają z szerokimi uprawnieniami. Mogą uzyskać dostęp do tokenów publikacyjnych, rejestrów pakietów, kontenerów, sekretów organizacyjnych, a nawet kluczy używanych do podpisywania artefaktów. Jeżeli organizacja nie ogranicza uprawnień zgodnie z zasadą najmniejszych przywilejów, pojedynczy złośliwy workflow może otworzyć drogę do przejęcia znacznie większej części środowiska.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem takiej kampanii jest wyciek sekretów. W praktyce mogą to być tokeny GitHub, dane dostępowe do chmury publicznej, poświadczenia do rejestrów pakietów i kontenerów, klucze API do usług zewnętrznych oraz sekrety wykorzystywane przez procesy release i deployment.

Ryzyko nie kończy się jednak na samym ujawnieniu danych. Przejęte poświadczenia mogą zostać użyte do publikacji kolejnych złośliwych pakietów, podmiany obrazów kontenerowych, modyfikacji artefaktów build lub wdrożenia backdoora do legalnie dystrybuowanego oprogramowania. W efekcie incydent wewnętrzny może szybko przerodzić się w zagrożenie dla klientów końcowych i partnerów biznesowych.

wyciek tokenów GitHub i danych uwierzytelniających,
kompromitacja środowisk chmurowych i rejestrów pakietów,
skażenie procesu build, release i deployment,
ryzyko dystrybucji zmodyfikowanego oprogramowania do klientów,
efekt domina między repozytoriami i środowiskami organizacji.

Rekomendacje

Organizacje powinny potraktować ten typ incydentu jako sygnał do pilnego przeglądu bezpieczeństwa repozytoriów, tożsamości deweloperskich i sekretów wykorzystywanych w CI/CD. Kluczowe jest nie tylko usunięcie podejrzanych plików, ale również ocena, czy workflow zostały uruchomione i jakie dane mogły zostać wyprowadzone.

przeprowadzić audyt zmian w katalogu .github/workflows/,
zidentyfikować nieautoryzowane commity i podejrzane workflow,
dokonać rotacji wszystkich sekretów dostępnych dla potencjalnie naruszonych repozytoriów,
ograniczyć domyślne uprawnienia GITHUB_TOKEN,
wymusić zasadę najmniejszych uprawnień dla workflow i kont serwisowych,
włączyć ochronę branchy, obowiązkowe review oraz podpisywanie commitów,
monitorować tworzenie nowych workflow i nietypowe uruchomienia pipeline’ów,
stosować pinowanie akcji do konkretnych hashy commitów,
wdrożyć skanowanie sekretów w kodzie, historii Git i artefaktach CI.

Dobrą praktyką jest także segmentacja sekretów między repozytoria i środowiska, skracanie czasu życia tokenów oraz stosowanie mechanizmów federacji tożsamości zamiast długowiecznych kluczy statycznych. W przypadku podejrzenia kompromitacji konieczna jest pełna analiza ścieżki wykonania workflow oraz weryfikacja, czy zdobyte poświadczenia były używane poza GitHub.

Podsumowanie

Opisana kampania dobitnie pokazuje, że GitHub i systemy CI/CD pozostają atrakcyjnym celem dla napastników szukających szybkiej skali działania. Kompromitacja dużej liczby repozytoriów nie musi wynikać z klasycznego exploita podatności — wystarczy przejęcie zaufanej tożsamości i nadużycie automatyzacji obecnej w nowoczesnym procesie tworzenia oprogramowania.

Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia ochrony poza sam kod źródłowy. Równie ważne stają się dziś kontrola workflow, zarządzanie sekretami, ograniczanie uprawnień oraz ciągły nadzór nad relacjami zaufania w całym łańcuchu dostaw oprogramowania.