Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania coraz częściej wykorzystują zaufane mechanizmy automatyzacji, takie jak GitHub Actions. W opisywanym incydencie napastnicy użyli przejętych kont maintainerów do wstrzyknięcia złośliwych workflow do wielu repozytoriów, aby wykradać sekrety CI/CD, tokeny dostępowe oraz klucze API.
Tego typu kampanie są szczególnie niebezpieczne, ponieważ nadużywają legalnych procesów wykorzystywanych codziennie przez zespoły developerskie. W praktyce oznacza to, że złośliwe działania mogą przez pewien czas wyglądać jak zwykłe operacje administracyjne lub audytowe.
W skrócie
Kampania polegała na dodawaniu do repozytoriów plików workflow podszywających się pod audyt bezpieczeństwa. Po uruchomieniu zadania GitHub Actions przeszukiwały sekrety repozytorium, analizowały zawartość projektu oraz pełną historię Git w poszukiwaniu poświadczeń, a następnie przesyłały zebrane dane do infrastruktury kontrolowanej przez atakujących.
- Złośliwe workflow wyglądały jak legalne pliki związane z bezpieczeństwem.
- Atak obejmował zarówno bieżący kod, jak i historyczne dane w repozytorium.
- Celem były tokeny, klucze API i inne sekrety wykorzystywane przez pipeline’y CI/CD.
- Skala incydentu wskazuje na szeroko zakrojony atak typu supply chain.
Kontekst / historia
Incydent wpisuje się w szerszą aktywność określaną jako GhostAction, wcześniej wiązaną z nadużywaniem GitHub Actions do pozyskiwania poufnych danych z procesów budowania i wdrażania. W tej odsłonie ataku wykorzystano przejęte konta znanych maintainerów open source, co pozwoliło szybko propagować złośliwe workflow do dużej liczby repozytoriów.
Mechanizm był trudny do wykrycia, ponieważ zmiany pochodziły od zaufanych autorów i mogły zostać potraktowane jako uprawnione. Dodatkowym problemem były forki repozytoriów, które mogły odziedziczyć zainfekowane workflow i uruchamiać je przy kolejnych zdarzeniach.
Analiza techniczna
Atak najprawdopodobniej rozpoczynał się od przejęcia poświadczeń GitHub maintainerów, między innymi tokenów PAT lub danych wcześniej wykradzionych przez infostealery. Po uzyskaniu dostępu operatorzy kampanii dodawali do domyślnej gałęzi pliki workflow o nazwach sugerujących legalny audyt, takie jak security-audit.yml lub github_actions_security.yml.
Złośliwe workflow było zaprojektowane tak, aby zmaksymalizować ilość pozyskiwanych danych. Po uruchomieniu wykonywało pełny checkout repozytorium wraz z historią commitów, a następnie uruchamiało serię działań rozpoznawczych i eksfiltracyjnych.
- Odczyt sekretów dostępnych w kontekście GitHub Actions.
- Skanowanie plików repozytorium pod kątem wzorców odpowiadających poświadczeniom.
- Analizę pełnej historii Git w poszukiwaniu dawniej zapisanych sekretów.
- Korelację znalezionych danych w celu zwiększenia ich użyteczności.
- Eksfiltrację danych za pomocą prostych żądań sieciowych.
Szczególnie istotne było to, że workflow mogło uruchamiać się automatycznie w odpowiedzi na zdarzenia typu push bez istotnych ograniczeń zakresu. Taki model zwiększał prawdopodobieństwo skutecznej kradzieży sekretów i rozszerzał powierzchnię ataku na kolejne repozytoria oraz gałęzie rozwojowe.
Wśród wyszukiwanych artefaktów znajdowały się klucze AWS, tokeny GitHub i GitLab, dane dostępowe do rejestrów kontenerów, sekrety usług AI, poświadczenia SaaS oraz inne dane wykorzystywane przez środowiska CI/CD. To pokazuje, że kampania była nastawiona na szerokie wykorzystanie wykradzionych sekretów w kolejnych etapach kompromitacji.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem takiego incydentu jest utrata poufności sekretów i osłabienie zaufania do automatyzacji procesu wytwarzania oprogramowania. Kompromitacja workflow CI/CD może prowadzić nie tylko do kradzieży danych uwierzytelniających, ale również do modyfikacji artefaktów buildów, przejęcia kont publikacyjnych i wstrzyknięcia złośliwego kodu do dystrybuowanego oprogramowania.
Ryzyko jest szczególnie wysokie dla organizacji, które przechowują w GitHub Actions sekrety o szerokich uprawnieniach, nie rotują regularnie tokenów, utrzymują prywatne forki projektów open source, nie monitorują zmian w plikach workflow oraz dopuszczają uruchamianie zadań z pełnym dostępem do historii repozytorium.
Nawet jeśli kampania nie doprowadziła od razu do publikacji złośliwych pakietów, samo wykradzenie poświadczeń może umożliwić późniejsze przejęcie kont w chmurze, rejestrach pakietów, narzędziach developerskich i platformach współpracy. Dodatkowo analiza historii Git zwiększa skuteczność ataku, ponieważ usunięcie sekretu z aktualnego stanu repozytorium nie oznacza jego zniknięcia z historii commitów.
Rekomendacje
Organizacje korzystające z GitHub Actions powinny potraktować obecność wskazanych workflow jako potencjalny incydent bezpieczeństwa i przyjąć, że mogło dojść do naruszenia poufności sekretów. Reakcja powinna obejmować zarówno działania natychmiastowe, jak i długofalowe wzmocnienie procesów DevSecOps.
- Przeprowadzić przegląd repozytoriów pod kątem podejrzanych plików workflow.
- Usunąć złośliwe workflow ze wszystkich gałęzi, forków i kopii repozytoriów.
- Niezwłocznie zrotować sekrety, tokeny i klucze API dostępne podczas uruchomień.
- Unieważnić przejęte tokeny GitHub, zwłaszcza klasyczne PAT.
- Przeanalizować logi GitHub Actions, aby ustalić zakres uruchomień i potencjalny wpływ.
- Ograniczyć uprawnienia sekretów zgodnie z zasadą najmniejszych uprawnień.
- Wdrożyć monitorowanie zmian w katalogu
.github/workflows/. - Włączyć silne MFA i dodatkowe zabezpieczenia kont maintainerów.
- Przeprowadzić audyt historii Git z użyciem narzędzi do wykrywania sekretów.
- Rozważyć stosowanie krótkotrwałych poświadczeń zamiast statycznych kluczy.
Podsumowanie
Opisana kampania pokazuje, że GitHub Actions stał się atrakcyjnym celem dla grup prowadzących ataki na łańcuch dostaw. Połączenie przejętych kont maintainerów, złośliwych workflow podszywających się pod audyt oraz analizy pełnej historii Git tworzy bardzo skuteczny mechanizm masowej kradzieży sekretów.
Dla zespołów bezpieczeństwa i DevSecOps to wyraźny sygnał, że ochrona tożsamości deweloperów, monitoring pipeline’ów oraz rygorystyczne zarządzanie sekretami muszą być traktowane jako element krytyczny bezpieczeństwa oprogramowania.