Technologia

Megalodon zamienił GitHub Actions w backdoor w 5561 repozytoriach

Susan Hill

Zautomatyzowana kampania wypchnęła 5718 commitów do 5561 repozytoriów GitHub w sześć godzin w jeden poniedziałek maja. Commity wyglądały jak rutynowa obsługa CI („ci: add build optimization step”, „build: improve ci performance”, „chore: optimize pipeline runtime”) i pochodziły od autorów o banalnych nazwach: build-bot, auto-ci, pipeline-bot. Gdy poranek 18 maja dobiegł końca, w każdym z tych repozytoriów leżał plik workflow z payloadem bash zakodowanym w base64 w środku.

Kampania nazywa się Megalodon. Zespół badawczy SafeDep ujawnił ją 21 maja, po rozłożeniu commitów na czynniki pierwsze i prześledzeniu artefaktów do jednego serwera dowodzenia pod adresem 216.126.225.129:8443. Ciekawe nie jest to, że GitHub został zaatakowany. Ciekawe jest to, że atakujący wcale nie musiał kompromitować GitHuba. Użył GitHub Actions, systemu CI/CD zaprojektowanego właśnie po to, by gwarantować integralność kodu, jako wehikułu dostarczającego backdoora.

Dwa workflow, jeden masowy i jeden uśpiony

Megalodon działał w dwóch trybach. Wariant masowy dodawał nowy plik workflow o nazwie SysDiag, który uruchamiał się przy każdym pushu i każdym pull requeście, łapiąc wszystko, co przez niego przechodziło. Wariant celowany, Optimize-Build, robił coś bardziej cierpliwego: zastępował istniejący workflow wyzwalaczem workflow_dispatch, który śpi, dopóki ktoś nie wywoła go ręcznie. Uśpiony backdoor w katalogu CI projektu jest znacznie trudniejszy do wychwycenia niż nowy workflow o nazwie SysDiag, ponieważ większość maintainerów nie audytuje pliku, który sami kiedyś napisali.

Gdy workflow ruszy, payload czyta wszystko, do czego dosięgnie w środowisku CI. Zmienne środowiskowe CI. Klucze dostępu, klucze tajne i tokeny sesji AWS. Tokeny dostępu GCP. Prywatne klucze SSH. Poświadczenia .npmrc. Konfiguracje Dockera. Konfiguracje Kubernetesa. Tokeny OIDC GitHub Actions, które pozwalają atakującemu podszyć się pod sam workflow wobec dowolnego konta chmurowego, do którego był autoryzowany. Zanim wyjdzie, payload greppuje kod źródłowy repozytorium za ponad trzydziestoma różnymi wzorcami sekretów (kluczami API, hasłami, fragmentami certyfikatów) na wypadek, gdyby ktoś wkleił któryś. Endpointy metadanych AWS IMDSv2, GCP i Azure też są odpytywane, aby uzyskać tożsamość maszyny w chmurze.

Pipeline, który wysyła własnego backdoora

Najpoważniejszą ofiarą jak dotąd jest Tiledesk, otwartoźródłowa platforma do obsługi klienta, której dziewięć repozytoriów na GitHubie zostało trafionych. Między 19 a 21 maja Tiledesk opublikował pakiet tiledesk-server na npm z wkompilowanym backdoorem. Wersje od 2.18.6 do 2.18.12 @tiledesk/tiledesk-server niosą teraz kod payloadu, zainstalowany przez każdego dewelopera, który uruchomił npm install w tym oknie. To jest dźwignia, dla której Megalodon został zbudowany: zaszczepić backdoor w jednym projekcie open source, żeby jego pipeline release’owy zaszczepił backdoory w setkach projektów zależnych.

Black-Iron-Project stracił osiem repozytoriów. Setki mniejszych projektów (konta indywidualnych deweloperów, klastry uniwersyteckie, porzucone sandboxy) dostały po jednym lub dwa. Atakujący najwyraźniej nie wybierał. Wzorcem było pokrycie kosztem precyzji: jednorazowe konta z losowymi ośmioznakowymi nazwami wypychające identyczne wiadomości commitów minuta po minucie. Serwer C2 cicho rejestrował, co wraca.

Dlaczego pliki CI przeżyły audyt

Ten atak zadziałał z tego samego powodu, dla którego będzie się powtarzał przez resztę 2026 roku. Pipeline’y CI/CD opierają się na zaufaniu z założenia. Deweloper, który nie ufa dziwnemu binarium z pobrania, bez wahania uruchomi plik workflow, który pojawił się w jego repozytorium w zeszłym tygodniu, ponieważ pliki workflow są dokładnie tym: kodem, który platforma ma uruchamiać. Logi audytowe istnieją, ale prawie żaden zespół ich nie czyta. Nowe commity przychodzą podpisane nazwami w rodzaju build-bot i ci-bot. Diffy są małe. Łańcuch base64 na końcu workflow jest celowo nieczytelny.

Defensywny scenariusz jest prosty i mało satysfakcjonujący. Wymień każdy sekret, który dotknął repozytorium między 18 maja a dziś. Skontroluj katalog .github/workflows każdego projektu pod zarządem. Sprawdź commity, których adres email autora nie pasuje do żadnego znanego członka zespołu. Każdy blob base64 wewnątrz pliku Actions traktuj jako winny, dopóki nie zostanie odkodowany. Organizacje używające Tiledesk powinny wrócić do 2.18.5 lub poczekać na czysty release. Każdy, kto ma zaufanie OIDC między Actions a dostawcą chmury, powinien je unieważnić i wystawić od nowa.

Megalodon to pierwsza kampania na tę skalę, która traktuje sam workflow CI jako miękki cel. Nie będzie ostatnia. Lekcja, którą zostawia atak, to lekcja, którą deweloperzy słyszeli już ciszej: ta część pipeline’u, której nie czytasz, to ta część, którą atakujący pisze za ciebie.

Dyskusja

Jest 0 komentarzy.