Wprowadzenie do problemu / definicja
Incydenty typu supply chain w środowiskach DevSecOps pozostają jednym z najpoważniejszych zagrożeń dla organizacji rozwijających oprogramowanie. Najnowszy przypadek związany z ponowną aktywacją dwóch zewnętrznych GitHub Actions powiązanych z ładunkiem Mini Shai-Hulud pokazuje, że nawet po wcześniejszym wykryciu kampanii malware zagrożenie może powrócić, jeśli skażone komponenty nadal są osiągalne przez workflow CI/CD.
Problem dotyczy przede wszystkim sposobu referencjonowania zależności. Jeżeli zespoły korzystają z akcji wskazywanych przez tagi wersji zamiast przez jednoznacznie przypięte identyfikatory commitów, złośliwy kod może zostać ponownie pobrany i uruchomiony bez świadomej ingerencji administratorów czy programistów.
W skrócie
Dwie zewnętrzne GitHub Actions, wcześniej powiązane z kampanią Mini Shai-Hulud, zostały ponownie udostępnione i przez ponad tydzień pozostawały aktywne mimo dalszego wskazywania na złośliwy kod. Oznaczało to, że workflow korzystające z tych komponentów mogły ponownie wykonywać szkodliwy payload w środowisku CI/CD.
Incydent wpisuje się w szerszy problem bezpieczeństwa łańcucha dostaw oprogramowania. Dotknięte komponenty były wcześniej częścią większej kampanii obejmującej pakiety npm i działania ukierunkowane na przejmowanie tokenów programistów, poświadczeń oraz sekretów wykorzystywanych w automatyzacji.
Kontekst / historia
Kampania Mini Shai-Hulud została wcześniej powiązana z naruszeniem łańcucha dostaw, w którym złośliwy kod przedostał się do elementów wykorzystywanych przez programistów oraz procesy automatycznego budowania i utrzymania projektów. W maju skompromitowano dwa repozytoria zawierające popularne GitHub Actions używane do obsługi komentarzy i zgłoszeń.
Po wykryciu incydentu dostęp do tych komponentów został ograniczony, co miało uniemożliwić dalsze pobieranie szkodliwego ładunku przez zależne pipeline’y. Sytuacja zmieniła się jednak we wrześniu, gdy wspomniane repozytoria ponownie stały się dostępne. Kluczowy problem polegał na tym, że znaczniki wydań nadal prowadziły do niebezpiecznych rewizji, przez co organizacje korzystające z tych akcji przez tagi mogły nieświadomie wznowić wykonywanie złośliwego kodu.
Analiza techniczna
Technicznie jest to klasyczny przykład ryzyka wynikającego z używania zewnętrznych GitHub Actions referencjonowanych przez tag wersji zamiast przez konkretny commit SHA. Tagi są mutowalne, co oznacza, że mogą zostać przesunięte lub pozostać powiązane z niebezpiecznym stanem repozytorium. W efekcie workflow może pobrać inny kod niż ten, który był wcześniej zweryfikowany przez zespół.
W analizowanym przypadku payload znajdował się w pliku index.js i pozostawał osiągalny przez znaczniki wydań przypisane do skompromitowanych repozytoriów. Każde uruchomienie workflow odwołującego się do tych znaczników mogło więc pobrać i wykonać złośliwy kod w środowisku CI/CD.
Jest to szczególnie groźne, ponieważ pipeline’y często działają z szerokimi uprawnieniami. Mają dostęp do tokenów repozytorium, sekretów wdrożeniowych, poświadczeń chmurowych, kluczy publikacyjnych oraz artefaktów budowania. Kompromitacja jednej zewnętrznej akcji może więc stanowić punkt wejścia do dalszej eskalacji ataku.
Skala potencjalnego wpływu zależy od popularności danej akcji. Jeżeli komponent jest wykorzystywany do rutynowych zadań administracyjnych i automatyzacyjnych w wielu projektach, promień rażenia takiego incydentu może być bardzo szeroki, nawet jeśli nie wszystkie zależne workflow zostały faktycznie wykorzystane przez napastników.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podobnych incydentów jest utrata zaufania do procesu budowania oprogramowania. Gdy złośliwa akcja działa w pipeline CI/CD, atakujący może próbować przejąć sekrety, modyfikować artefakty, uzyskać dostęp do infrastruktury lub rozszerzyć kompromitację na kolejne repozytoria i systemy.
Dodatkowym problemem pozostaje trudność wykrycia. Workflow uruchamiane automatycznie nie zawsze są poddawane ręcznej kontroli przy każdym wykonaniu, a użycie znanej akcji może nie wzbudzić podejrzeń. Jeżeli organizacja nie prowadzi pełnej inwentaryzacji zależności oraz nie monitoruje zmian mapowania tagów na commity, incydent może przez dłuższy czas pozostać niezauważony.
Z operacyjnego punktu widzenia ponowne uruchomienie niebezpiecznego komponentu może wymusić szeroko zakrojone działania naprawcze, w tym rotację sekretów, analizę historycznych uruchomień pipeline’ów, przegląd integralności artefaktów oraz weryfikację, czy nie doszło do ruchu bocznego w środowisku developerskim lub produkcyjnym.
Rekomendacje
Organizacje korzystające z GitHub Actions powinny jak najszybciej zidentyfikować wszystkie workflow odwołujące się do zewnętrznych akcji, które mogły zostać dotknięte kompromitacją. Należy usunąć nieużywane komponenty, a wszystkie pozostałe przypinać wyłącznie do zweryfikowanych commitów SHA zamiast do tagów lub gałęzi.
- przeprowadzić pełny przegląd workflow pod kątem użycia zewnętrznych akcji,
- zastąpić mutowalne referencje niezmiennymi commitami,
- ograniczyć uprawnienia tokenów wykorzystywanych przez pipeline do minimum,
- rozdzielić sekrety pomiędzy środowiska build, test i deployment,
- monitorować logi uruchomień pod kątem anomalii i nieautoryzowanych połączeń wychodzących,
- rotować wszystkie sekrety dostępne dla workflow, które mogły uruchomić podatną akcję,
- zweryfikować integralność artefaktów utworzonych w okresie ekspozycji,
- stosować listy dozwolonych akcji oraz polityki zatwierdzania komponentów trzecich,
- rozważyć lokalne mirrorowanie lub forki krytycznych akcji używanych produkcyjnie.
Dobrą praktyką jest również wdrożenie mechanizmów attestation, kontroli pochodzenia artefaktów oraz regularnych przeglądów zależności w pipeline’ach CI/CD. Automatyzacja buildów powinna być traktowana jako obszar uprzywilejowany, wymagający równie ścisłej kontroli jak infrastruktura administracyjna.
Podsumowanie
Ponowna aktywacja skompromitowanych GitHub Actions pokazała, że samo ograniczenie widocznych skutków incydentu nie zawsze oznacza usunięcie źródła zagrożenia. Jeśli znaczniki wydań nadal prowadzą do złośliwego kodu, każdy zależny workflow może stać się nośnikiem wtórnej kompromitacji.
Przypadek Mini Shai-Hulud stanowi kolejny argument za rygorystycznym pinowaniem zależności, minimalizacją uprawnień w CI/CD oraz ciągłą walidacją komponentów trzecich. Dla zespołów bezpieczeństwa i DevOps oznacza to konieczność traktowania GitHub Actions jako krytycznego elementu łańcucha dostaw oprogramowania.