Kolejny atak na łańcuch dostaw oprogramowania uderzył w ekosystem deweloperski, tym razem w popularny workflow GitHub Actions: actions-cool/issues-helper.
Jak wynika z badań firmy StepSecurity, cyberprzestępcy przejęli tę akcję w taki sposób, że istniejące tagi wersji zaczęły wskazywać na złośliwy commit-impostor. W rezultacie workflowy odwołujące się do akcji za pomocą tagu mogły automatycznie wykonać kontrolowany przez atakującego kod podczas swojego kolejnego uruchomienia CI/CD.
Incydent jest szczególnie poważny, ponieważ GitHub Actions często działają w środowiskach, które mają dostęp do wrażliwych tokenów, sekretów repozytoriów, poświadczeń chmurowych, kluczy do publikowania pakietów i uprawnień do wdrożeń.
Co się stało?
Przejęta akcja GitHub Action, actions-cool/issues-helper, została zmodyfikowana w taki sposób, że każdy istniejący tag w repozytorium wskazywał na commit-impostor.
Oznacza to, że nawet workflowy używające pozornie zaufanych tagów wersji mogły nieświadomie pobrać złośliwy kod.
Zazwyczaj programiści polegają na tagach takich jak v1, v2 lub innych etykietach wydań, aby odwoływać się do stabilnych wersji akcji GitHub Action. Tagi są jednak zmienne, o ile nie zostaną zabezpieczone i zweryfikowane. Jeśli atakujący potrafi przesunąć te tagi na złośliwe commity, użytkownicy końcowi mogą uruchomić przejęty kod, nie zmieniając niczego we własnych repozytoriach.
Właśnie to czyni ten atak niebezpiecznym: workflow ofiary nie musi być w ogóle edytowany. Punktem wykonania kodu może stać się kolejne uruchomienie potoku.
Czym jest commit-impostor?
Commit-impostor (imposter commit) to podstępna technika ataku na łańcuch dostaw, w której złośliwy kod trafia do projektu przez commit lub tag, który wygląda na należący do zaufanego projektu, ale w rzeczywistości znajduje się poza normalną, zaufaną historią commitów.
Zamiast przechodzić standardowy proces pull requesta, przeglądu i scalenia, atakujący kieruje tag na złośliwy commit. Taki commit może pochodzić z forka kontrolowanego przez przeciwnika lub z innego źródła, które nie jest częścią legalnej historii repozytorium.
Pozwala to atakującym obejść standardowe zabezpieczenia w postaci przeglądu kodu.
W praktyce workflow nadal odwołuje się do tej samej nazwy akcji i tego samego tagu wersji, ale tag wskazuje teraz na kod kontrolowany przez atakującego.
Jak działała złośliwa akcja
StepSecurity poinformowała, że złośliwy commit uruchamiał kod wewnątrz runnera GitHub Actions, aby wykradać poświadczenia z potoków CI/CD.
Złośliwa logika wykonywała, jak ustalono, kilka kroków:
- pobierała na runner środowisko uruchomieniowe JavaScript Bun
- odczytywała pamięć procesu
Runner.Worker - próbowała wyodrębnić poświadczenia z działającego środowiska CI/CD
- wysyłała wykradzione dane do domeny kontrolowanej przez atakującego:
t.m-kosche[.]com
Takie podejście jest szczególnie niepokojące, ponieważ celuje w poświadczenia dostępne podczas wykonywania potoku. Systemy CI/CD często zawierają cenne sekrety używane do automatyzacji, wdrożeń, publikowania, dostępu do infrastruktury i uwierzytelniania usług.
Po wykradzeniu takie poświadczenia mogą posłużyć do przejęcia repozytoriów, środowisk chmurowych, rejestrów pakietów lub systemów produkcyjnych.
Dotknięta została także druga akcja GitHub Action
Przejęcie nie ograniczało się do actions-cool/issues-helper.
StepSecurity ustaliła również, że 15 tagów powiązanych z inną akcją GitHub Action, actions-cool/maintain-one-comment, zostało przejętych i wyposażonych w podobną złośliwą funkcjonalność.
Sugeruje to, że kampania miała szerszy zasięg niż pojedyncze repozytorium i mogła obejmować wiele akcji utrzymywanych w ramach tego samego ekosystemu lub według tego samego wzorca własności.
GitHub zablokował później dostęp do dotkniętego repozytorium z powodu naruszenia regulaminu usługi.
Możliwy związek z aktywnością Mini Shai-Hulud
Domena eksfiltracji użyta w przejęciu GitHub Actions, t.m-kosche[.]com, pojawiła się podobno także w najnowszej fali kampanii Mini Shai-Hulud, wymierzonej w pakiety npm z ekosystemu @antv.
Badacze bezpieczeństwa sugerują, że to pokrywanie się może wskazywać na powiązaną aktywność, a nie na dwa odrębne incydenty.
Ma to znaczenie, ponieważ atakujący coraz częściej uderzają w wiele elementów łańcucha dostaw oprogramowania jednocześnie. Pojedyncza kampania może przejąć GitHub Actions, pakiety npm, narzędzia deweloperskie i środowiska CI/CD, aby zmaksymalizować kradzież poświadczeń i dalszy zasięg ataku.
Celem nie jest wyłącznie przejęcie kodu. Chodzi o podważenie relacji zaufania, od których zależy nowoczesne dostarczanie oprogramowania.
Dlaczego GitHub Actions są cennym celem
GitHub Actions są głęboko zintegrowane z nowoczesnymi procesami wytwarzania oprogramowania. Potrafią testować kod, budować aplikacje, publikować pakiety, wdrażać infrastrukturę, zarządzać zgłoszeniami, aktualizować zależności i automatyzować wydania.
Z tego powodu GitHub Actions często działają z dostępem do:
GITHUB_TOKEN- sekretów repozytorium
- tokenów rejestrów pakietów
- poświadczeń npm, PyPI, RubyGems lub rejestrów kontenerów
- kluczy dostawców chmury
- tokenów wdrożeniowych
- kluczy SSH
- kluczy API
- poświadczeń do podpisywania
- uprawnień infrastruktury jako kodu
Przejęta akcja może stać się bezpośrednią drogą do środowiska CI/CD.
To czyni GitHub Actions atrakcyjnym celem ataku na łańcuch dostaw. Zamiast atakować bezpośrednio jedną organizację, cyberprzestępcy mogą przejąć zaufaną akcję i potencjalnie dotrzeć do wielu użytkowników końcowych.
Problem tagów: dlaczego przypinanie wersji ma znaczenie
Jedną z najważniejszych lekcji z tego incydentu jest to, że odwoływanie się do akcji za pomocą tagów nie zawsze jest bezpieczne.
Na przykład:
uses: actions-cool/issues-helper@v3Wygląda to na stabilne rozwiązanie, ale jeśli tag v3 zostanie przesunięty na złośliwy commit, workflow pobierze nowy, złośliwy kod.
Bezpieczniejszym podejściem jest przypięcie akcji do znanego, zaufanego pełnego skrótu SHA commita:
uses: actions-cool/issues-helper@<full-commit-sha>Przypięcie do skrótu SHA commita uniemożliwia cichemu przesunięciu tagu zmianę kodu wykonywanego przez Twój workflow.
Przypinanie SHA wymaga jednak utrzymania. Zespoły potrzebują procesu, który pozwala świadomie przeglądać i aktualizować przypięte akcje po wydaniu nowych wersji.
Co organizacje powinny zrobić teraz
Zespoły korzystające z actions-cool/issues-helper, actions-cool/maintain-one-comment lub jakiejkolwiek innej powiązanej, dotkniętej atakiem akcji powinny działać szybko.
Zalecane kroki obejmują:
- przeszukaj wszystkie repozytoria pod kątem odwołań do dotkniętych akcji
- wyłącz lub usuń dotknięte workflowy do czasu ich przeglądu
- sprawdź, czy workflowy odwoływały się do akcji za pomocą tagu zamiast pełnego skrótu SHA commita
- przejrzyj ostatnie uruchomienia workflowów pod kątem podejrzanych połączeń wychodzących
- sprawdź logi pod kątem pobrań nieoczekiwanych środowisk uruchomieniowych lub narzędzi, takich jak Bun
- zrotuj tokeny GitHub i sekrety repozytoriów udostępnione dotkniętym workflowom
- zrotuj poświadczenia chmurowe, rejestrów i wdrożeniowe używane w tych potokach
- przejrzyj dzienniki audytu organizacji GitHub
- sprawdź, czy nie doszło do nieautoryzowanych zmian w repozytoriach, wydaniach, tagach lub pakietach
- zweryfikuj, czy tokeny do publikowania pakietów nie zostały ujawnione
- ogranicz domyślne uprawnienia
GITHUB_TOKEN - egzekwuj zasadę najmniejszych uprawnień dla sekretów CI/CD
- przypinaj akcje GitHub Actions do pełnych skrótów SHA commitów wszędzie, gdzie to możliwe
Jeśli przejęty workflow miał dostęp do poświadczeń wdrożeniowych środowiska produkcyjnego, incydent należy traktować jako potencjalne przejęcie środowiska, a nie wyłącznie problem repozytorium.
Najlepsze praktyki bezpieczeństwa CI/CD
Ten incydent potwierdza kilka ważnych zasad bezpieczeństwa CI/CD.
1. Przypinaj akcje firm trzecich do pełnych skrótów SHA commitów
Tagi i gałęzie mogą się zmieniać. Pełne skróty SHA commitów zapewniają silniejszą ochronę integralności.
2. Stosuj zasadę najmniejszych uprawnień dla tokenów workflowów
Ustaw jawne uprawnienia dla GITHUB_TOKEN, zamiast polegać na szerokich ustawieniach domyślnych.
Przykład:
permissions:
contents: readUprawnienia do zapisu przyznawaj tylko tam, gdzie są naprawdę potrzebne.
3. Ogranicz dostęp do sekretów
Unikaj udostępniania wrażliwych sekretów workflowom, które ich nie potrzebują. Zachowaj szczególną ostrożność w przypadku workflowów pull requestów, automatyzacji zgłoszeń i akcji firm trzecich.
4. Monitoruj aktywność sieciową wychodzącą
Runnery CI/CD nie powinny swobodnie komunikować się z dowolnymi domenami. Tam, gdzie to możliwe, stosuj kontrolę ruchu wychodzącego, listy dozwolonych adresów lub monitoring, aby wykrywać nietypowy ruch wychodzący.
5. Przeglądaj zależności od akcji firm trzecich
Traktuj GitHub Actions jak zależności produkcyjne. Powinny być przeglądane, monitorowane i aktualizowane w ramach kontrolowanych procesów.
6. Korzystaj z narzędzi bezpieczeństwa do skanowania workflowów
Narzędzia wykrywające nieprzypięte akcje, nadmierne uprawnienia tokenów, podejrzane zachowanie workflowów i ryzykowne akcje firm trzecich mogą ograniczyć ekspozycję.
Dlaczego ten incydent ma znaczenie
Przejęcie actions-cool/issues-helper pokazuje, jak atakujący przesuwają się głębiej w proces dostarczania oprogramowania.
Współczesne ataki na łańcuch dostaw nie ograniczają się już do złośliwych pakietów. Cyberprzestępcy atakują:
- rejestry pakietów
- GitHub Actions
- sekrety CI/CD
- automatyzację wydań
- stacje robocze deweloperów
- opiekunów projektów open source
- potoki budowania
- procesy podpisywania i wdrażania
Dzieje się tak dlatego, że proces budowania i wdrażania często zawiera klucze do królestwa.
Jeśli atakujący zdołają wykraść poświadczenia CI/CD, mogą nie potrzebować bezpośrednio wykorzystywać luk w systemach produkcyjnych. Mogą nadużyć zaufanej automatyzacji, aby publikować złośliwy kod, uzyskać dostęp do infrastruktury lub wdrażać nieautoryzowane zmiany.
Podsumowanie
Przejęcie actions-cool/issues-helper to kolejne przypomnienie, że potoki CI/CD są częścią powierzchni ataku.
Zaufany workflow automatyzacji może stać się mechanizmem kradzieży poświadczeń, jeśli jego nadrzędna akcja zostanie przejęta. To, że istniejące tagi przesunięto na złośliwe commity, czyni ten atak szczególnie niebezpiecznym, ponieważ repozytoria użytkowników końcowych mogą zostać dotknięte bez żadnej zmiany w lokalnym kodzie.
Organizacje powinny przejrzeć dotknięte workflowy, zrotować ujawnione sekrety, zbadać ostatnią aktywność potoków i przejść do silniejszego utwardzania GitHub Actions.
Kluczowa lekcja jest prosta: zaufanie w łańcuchu dostaw oprogramowania trzeba weryfikować nieustannie. W CI/CD wygoda nigdy nie powinna odbywać się kosztem niekontrolowanego wykonywania kodu.
