Nowa kampania ataków na łańcuch dostaw oprogramowania, znana jako Megalodon, zatruła tysiące repozytoriów GitHub złośliwymi workflowami GitHub Actions, których zadaniem jest kradzież sekretów ze środowisk CI/CD.
Jak wynika z badań firmy SafeDep, zautomatyzowana kampania rozegrała się 18 maja w ciągu sześciu godzin. W tak krótkim czasie cyberprzestępca wypchnął 5718 złośliwych commitów do 5561 repozytoriów GitHub.
Kampania uderzyła w jeden z najbardziej wrażliwych obszarów współczesnego dostarczania oprogramowania: potok CI/CD. Modyfikując workflowy GitHub Actions, atakujący próbowali wykraść poświadczenia, sekrety chmurowe, klucze SSH, tokeny OpenID Connect oraz sekrety zawarte w kodzie źródłowym z zainfekowanych repozytoriów.
To kolejne wyraźne przypomnienie, że łańcuch dostaw oprogramowania jest dziś jednym z najcenniejszych celów dla cyberprzestępców.
Co się stało?
Kampania Megalodon wykorzystywała fikcyjne konta i sfałszowane tożsamości autorów, aby wstrzykiwać do repozytoriów złośliwe workflowy GitHub Actions.
Workflowy te zaprojektowano tak, aby uruchamiały się w środowiskach GitHub Actions i wykradały wrażliwe dane na serwer dowodzenia i kontroli (C2) należący do atakującego.
Wykradzione dane mogły obejmować:
- sekrety CI/CD
- poświadczenia chmurowe
- klucze SSH
- tokeny OpenID Connect
- sekrety repozytoriów
- sekrety zawarte w kodzie źródłowym
- poświadczenia wdrożeniowe
Ten rodzaj ataku jest szczególnie niebezpieczny, ponieważ środowiska CI/CD często mają uprzywilejowany dostęp do infrastruktury chmurowej, rejestrów pakietów, wdrożeń produkcyjnych i systemów wewnętrznych.
Jeśli atakujący wykradną te sekrety, mogą wyjść daleko poza pierwotne repozytorium.
Dwa ładunki: głośna infekcja i ukryty backdoor
SafeDep opisała Megalodon jako kampanię wykorzystującą dwa różne style ładunków.
Pierwszy ładunek dodawał złośliwy plik workflow YAML o nazwie SysDiag. Workflow ten uruchamiał się przy każdym pushu lub pull requeście, dzięki czemu złośliwy kod działał w ramach zwykłej aktywności w repozytorium.
Drugi ładunek był bardziej ukierunkowany i trudniejszy do wykrycia. Zamiast dodawać oczywisty nowy workflow, podmieniał istniejące workflowy na wyzwalane przez workflow_dispatch.
Ma to znaczenie, ponieważ workflowy workflow_dispatch nie uruchamiają się automatycznie. Pozostają uśpione, dopóki ktoś nie wyzwoli ich ręcznie, także za pośrednictwem API GitHub.
To sprawia, że backdoor jest trudniejszy do zauważenia.
Może nie być żadnego nieudanego builda, widocznego błędu CI ani podejrzanego uruchomienia workflowu na karcie Actions, dopóki atakujący nie zdecyduje się go aktywować.
Dlaczego GitHub Actions to cenny cel
GitHub Actions są głęboko zintegrowane z procesem tworzenia oprogramowania. Budują kod, uruchamiają testy, publikują pakiety, wdrażają aplikacje, rotują elementy infrastruktury i współpracują z platformami chmurowymi.
Oznacza to, że workflowy często mają dostęp do potężnych sekretów.
Skompromitowany workflow może stać się bezpośrednią drogą do:
- kont chmurowych
- systemów wdrożeń produkcyjnych
- tokenów do publikowania pakietów
- prywatnych repozytoriów
- rejestrów kontenerów
- potoków infrastructure-as-code
- wewnętrznych API
- poświadczeń deweloperów
Dla atakujących przejęcie GitHub Actions może być cenniejsze niż skompromitowanie pojedynczego urządzenia końcowego. Daje im dostęp do automatyzacji, której organizacja ufa.
Repozytoria Tiledesk z backdoorem
SafeDep wykryła Megalodon po raz pierwszy, gdy jej silnik Malysis zidentyfikował podejrzaną aktywność w dołączonym pliku workflow GitHub Actions w pakiecie npm @tiledesk/tiledesk-server@2.18.12, będącym częścią platformy chatbotowej open source Tiledesk.
Dalsze śledztwo wykazało, że backdoor trafił do dziewięciu repozytoriów Tiledesk.
Opiekunowie projektu nieświadomie opublikowali zatruty kod dla użytkowników końcowych, co przyczyniło się do rozprzestrzenienia infekcji.
To jedno z podstawowych zagrożeń związanych z atakami na łańcuch dostaw oprogramowania. Zaufany projekt open source może przypadkowo stać się kanałem dystrybucji złośliwego kodu.
Opiekunowie mogą nie mieć złych zamiarów. Użytkownicy mogą nie być nieostrożni. Ale gdy repozytorium zostanie zatrute, odbiorcy w dalszej części łańcucha nadal mogą być narażeni.
Dlaczego kampania była tak szybka
Kampania trwała zaledwie około sześciu godzin, ale w tym czasie rozprzestrzeniła się szeroko.
Badacze nie potwierdzili, dlaczego dokładnie kampania się zakończyła. Jedna z hipotez zakłada, że atakujący korzystali ze stałej listy ważnych poświadczeń zdobytych we wcześniejszych atakach na łańcuch dostaw wymierzonych w deweloperów.
Jeśli to prawda, atakujący mogli po prostu wyczerpać swoją listę dostępnych poświadczeń w trakcie ataku.
Pasowałoby to do szerszego trendu: atakujący łączą incydenty w łańcuchu dostaw w sekwencje. Poświadczenia skradzione w jednej kampanii mogą stać się paliwem dla kolejnej.
Wiele repozytoriów pozostało zainfekowanych
Dodatkowe badania firmy OX Security wykazały, że tysiące repozytoriów nadal zawierało złośliwy plik YAML po zakończeniu okna ataku.
Nawet jeśli początkowa aktywność atakującego ustała, zatrute repozytoria mogą pozostać niebezpieczne, dopóki nie zostaną oczyszczone.
To ważna uwaga dla obrońców.
Atak na łańcuch dostaw nie kończy się wraz z zakończeniem kampanii. Kończy się dopiero wtedy, gdy zainfekowane repozytoria zostaną zidentyfikowane i oczyszczone, sekrety zrotowane, a użytkownicy końcowi poinformowani.
Jeśli złośliwe workflowy pozostaną w repozytoriach, nadal mogą zostać uruchomione w późniejszym czasie.
Możliwy związek z TeamPCP pozostaje niepotwierdzony
Megalodon pojawił się mniej więcej w tym samym okresie co inne duże ataki na łańcuch dostaw powiązane z wyłaniającą się grupą zagrożeń TeamPCP.
Zauważono pewne podobieństwa, w tym fałszywe tożsamości botów i nietypowe, zakodowane na stałe daty commitów. Badacze nie potwierdzili jednak bezpośredniego związku między Megalodon a TeamPCP.
Obecnie brakuje mocnych wskaźników technicznych, publicznych deklaracji lub wspólnej infrastruktury łączących obie te grupy.
Ostrożniejsza ocena jest taka, że Megalodon może być częścią tego samego szerszego ekosystemu cyberprzestępczości nastawionej na łańcuch dostaw, ale przypisanie autorstwa pozostaje niepotwierdzone.
Możliwe jest też, że różne grupy dzielą się dostępem, poświadczeniami lub taktykami.
Dlaczego to ma znaczenie dla łańcucha dostaw oprogramowania
Megalodon pokazuje, jak szybko atakujący mogą skompromitować systemy dostarczania oprogramowania, gdy uzyskają dostęp do repozytorium.
Kampania nie wymagała wykorzystania skomplikowanej luki zero-day w samym GitHubie. Wygląda na to, że wykorzystała dostęp do repozytoriów, modyfikację workflowów i zaufaną automatyzację.
To czyni atak praktycznym i skalowalnym.
Nowoczesne bezpieczeństwo łańcucha dostaw oprogramowania musi uwzględniać:
- skradzione poświadczenia deweloperów
- zatrute workflowy
- złośliwe commity
- sfałszowane tożsamości autorów
- skompromitowanych opiekunów projektów
- zainfekowane wydania pakietów
- rozprzestrzenianie się infekcji na zależności w dalszej części łańcucha
- uśpione backdoory w CI/CD
- eksfiltrację sekretów ze środowisk automatyzacji
Repozytorium nie jest już tylko miejscem, w którym znajduje się kod. To miejsce, w którym zbiegają się automatyzacja, poświadczenia, infrastruktura i zaufanie wdrożeniowe.
Co organizacje powinny zrobić teraz
Organizacje powinny przeprowadzić audyt repozytoriów GitHub pod kątem oznak kompromitacji w stylu Megalodon.
Zalecane działania obejmują:
- przeszukanie wszystkich repozytoriów pod kątem nieoczekiwanych plików YAML GitHub Actions
- wyszukanie plików workflow o nazwie SysDiag
- przejrzenie ostatnich commitów od nieznanych lub podejrzanych tożsamości
- sprawdzenie, czy nie występują sfałszowane nazwy autorów i nietypowe metadane commitów
- skontrolowanie workflowów, które nieoczekiwanie używają
workflow_dispatch - przejrzenie workflowów zmodyfikowanych ostatnio bez wyraźnej akceptacji
- zablokowanie połączeń wychodzących do znanej infrastruktury dowodzenia i kontroli (C2) Megalodon
- przeanalizowanie ostatnich logów GitHub Actions pod kątem dostępu do sekretów lub zachowań wskazujących na eksfiltrację
- unieważnienie i zrotowanie wszystkich potencjalnie ujawnionych sekretów CI/CD
- zrotowanie kluczy SSH, kluczy API, kluczy chmurowych i tokenów wdrożeniowych
- przegląd relacji zaufania OpenID Connect
- sprawdzenie historii publikowania pakietów pod kątem nieautoryzowanych wydań
- powiadomienie użytkowników końcowych, jeśli mogły zostać opublikowane zatrute pakiety
Jeśli zostanie wykryta podejrzana aktywność workflowu, należy założyć, że sekrety dostępne dla tego workflowu mogły zostać ujawnione.
Zalecenia dotyczące utwardzania GitHub Actions
Aby ograniczyć ryzyko podobnych ataków, zespoły ds. bezpieczeństwa powinny wzmocnić zarządzanie GitHub Actions.
1. Ogranicz uprawnienia workflowów
Stosuj zasadę najmniejszych uprawnień dla uprawnień GITHUB_TOKEN. Nie zezwalaj na szeroki dostęp do zapisu, jeśli nie jest to konieczne.
2. Wymagaj przeglądu zmian w workflowach
Zmiany w .github/workflows/ powinny wymagać przeglądu przez właściciela kodu (code owner) i silniejszych mechanizmów zatwierdzania.
3. Monitoruj nowe i zmodyfikowane workflowy
Włącz alerty, gdy dodawane są nowe pliki workflow lub zmieniane są istniejące workflowy.
4. Ogranicz ekspozycję
Udostępniaj sekrety tylko tym workflowom, które naprawdę ich potrzebują. Unikaj udostępniania wrażliwych sekretów workflowom uruchamianym przez pull requesty.
5. Stosuj reguły ochrony środowisk
Wymagaj zatwierdzeń, zanim workflowy będą mogły uzyskać dostęp do sekretów wdrożeń produkcyjnych.
6. Przeglądaj polityki zaufania OIDC
Upewnij się, że role chmurowe korzystające z GitHub OIDC są precyzyjnie ograniczone do konkretnych repozytoriów, gałęzi i workflowów.
7. Audytuj uśpione workflowy
Przejrzyj workflowy workflow_dispatch i potwierdź, że są oczekiwane, udokumentowane i zatwierdzone.
8. Wykrywaj podejrzaną aktywność wychodzącą
Runnery CI/CD należy monitorować pod kątem nieoczekiwanych połączeń wychodzących, zwłaszcza do nieznanych domen lub adresów IP.
Szerszy wzorzec: CI/CD to nowa powierzchnia ataku
Megalodon jest częścią większej fali ataków wymierzonych w infrastrukturę deweloperską, ekosystemy pakietów i potoki automatyzacji.
Cyberprzestępcy coraz częściej atakują:
- repozytoria GitHub
- GitHub Actions
- pakiety npm
- poświadczenia deweloperów
- opiekunów projektów open source
- workflowy publikowania pakietów
- sekrety CI/CD
- potoki wdrożeń w chmurze
Powód jest prosty: systemy CI/CD często przechowują klucze do królestwa.
Jeśli atakujący skompromitują potok budowania, mogą wykraść sekrety, opublikować złośliwe pakiety, wdrożyć backdoory lub uzyskać dostęp do systemów produkcyjnych.
Podsumowanie
Kampania Megalodon pokazuje, jak szybko może rozprzestrzenić się atak na łańcuch dostaw oprogramowania, gdy atakujący uzyskają dostęp do repozytoriów i workflowów CI/CD.
W zaledwie sześć godzin tysiące repozytoriów zostało zatrutych złośliwymi commitami. Niektóre workflowy zaprojektowano tak, aby uruchamiały się natychmiast, a inne działały jako uśpione backdoory czekające na aktywację.
Workflowy GitHub Actions trzeba traktować jak wrażliwą infrastrukturę, a nie proste skrypty automatyzujące.
Organizacje powinny przeprowadzać audyt repozytoriów, monitorować zmiany w workflowach, ograniczać uprawnienia, rotować ujawnione sekrety i wdrażać silne mechanizmy kontroli wokół automatyzacji CI/CD.
Nowoczesny łańcuch dostaw oprogramowania jest tak bezpieczny, jak workflowy, które go budują i wdrażają.
