Największa zautomatyzowana kampania infekująca GitHub: Atak „Megalodon”

Operacja trwała między około 11:36 a 17:48 UTC, co sugeruje wysoce zautomatyzowany system zaprojektowany do szybkiego kompromitowania dużej liczby repozytoriów, zanim opiekunowie projektu zauważyli zmiany.

Jak atakujący wstrzyknęli tysiące commitów tak szybko

Kampania opierała się na automatyzacji i kamuflażu społecznym, aby złośliwe commity wyglądały jak normalne czynności konserwacyjne CI.

Fałszywe boty CI i konta jednorazowe

Atakujący tworzyli jednorazowe konta GitHub z losowymi nazwami użytkowników i podszywali się pod tożsamości automatyzacji, takie jak:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Te tożsamości sprawiały, że commity wyglądały jak rutynowe działanie systemów automatyzacji, a nie ludzkiego atakującego.

Sfałszowane metadane commitów

Dane autorów i wiadomości commitów zostały sfałszowane, aby wyglądać wiarygodnie – często przypominały rutynowe aktualizacje workflowu lub poprawki konfiguracji CI. Pomogło to wtopić commity w normalną aktywność programistyczną i opóźniło podejrzenia.

Atak na słabe zabezpieczenia gałęzi

Kampania skupiła się na repozytoriach, w których reguły ochrony gałęzi były słabe lub nieobecne. Bez obowiązkowych przeglądów pull requestów lub ograniczeń dotyczących modyfikowania workflowów atakujący mogli wypychać zmiany w workflowach bezpośrednio do domyślnej gałęzi repozytorium.

Zatrute workflowy GitHub Actions

Każdy złośliwy commit dodawał plik workflow GitHub Actions zawierający zakodowany w Base64 ładunek Bash. Gdy potok CI się wykonał, skrypt uruchamiał się w środowisku wykonawczym GitHub Actions i zaczynał kraść dane uwierzytelniające.

To oznaczało, że atak często pozostawał uśpiony do momentu następnego uruchomienia CI, które aktywowało workflow.

Co próbował ukraść ładunek

Zakodowany w Base64 skrypt osadzony w workflowach został zaprojektowany do zbierania wrażliwych danych ze środowiska CI i wysyłania ich do infrastruktury kontrolowanej przez atakujących.

Zgłaszane cele obejmowały:

• Zmienne środowiskowe CI/CD
• Dane uwierzytelniające dostawców chmurowych (AWS, Google Cloud, Azure)
• Prywatne klucze SSH
• Tokeny API i sekrety aplikacji
• Tokeny OIDC GitHub Actions
• Inne sekrety konfiguracyjne dostępne w środowisku wykonawczym

Złośliwe oprogramowanie zbierało zmienne środowiskowe, informacje o systemie i sekrety dostępne dla wykonawcy CI, a następnie wysyłało je do serwera dowodzenia i kontroli.

Ponieważ potoki CI często zawierają dane uwierzytelniające do wdrożeń, kompromitacja środowiska budowania może otworzyć drogę do infrastruktury chmurowej, rejestrów pakietów i wdrożeń produkcyjnych.

Dlaczego kradzież tokenów OIDC jest szczególnie niebezpieczna

Głównym celem ładunku Megalodon były tokeny OIDC GitHub Actions.

Nowoczesne potoki CI/CD często używają federacji OpenID Connect (OIDC), aby uwierzytelniać się u dostawców chmurowych bez przechowywania długoterminowych danych uwierzytelniających. Zamiast tego workflow żąda krótkotrwałego tokena tożsamości, który dostawcy chmury wymieniają na tymczasowe dane dostępu.

Takie podejście poprawia bezpieczeństwo, eliminując statyczne klucze API lub dane uwierzytelniające kont usługowych. Wprowadza jednak nowe ryzyko: jeśli atakujący ukradnie token podczas wykonywania potoku, może tymczasowo podszyć się pod tożsamość zadania CI.

Ponieważ te tokeny są zaufane przez systemy tożsamości w chmurze, skradziony token może potencjalnie zostać wymieniony na tymczasowy dostęp do chmury z tymi samymi uprawnieniami, jakie ma potok wdrożeniowy.

Oznacza to, że skompromitowany workflow CI może prowadzić do:

• dostępu do infrastruktury chmurowej
• przejęcia potoku wdrożeniowego
• odzyskiwania sekretów z usług chmurowych

Mimo że tokeny OIDC szybko wygasają, uprawnienia z nimi związane mogą sprawić, że krótkoterminowy dostęp będzie niezwykle wartościowy dla atakujących.

Dlaczego ten atak miał znaczenie

Kampania Megalodon ilustruje przesunięcie w atakach na łańcuch dostaw – od modyfikowania kodu aplikacji w kierunku kompromitowania infrastruktury automatyzacji.

Atakując workflowy CI zamiast kodu źródłowego, atakujący mogą:

• kraść dane uwierzytelniające automatycznie podczas uruchamiania potoków
• uzyskiwać dostęp do systemów wdrożeniowych i środowisk chmurowych
• pozostawać ukryci w rutynowych zmianach automatyzacji

Ponieważ tysiące repozytoriów polega na potokach CI z silnymi danymi uwierzytelniającymi, pojedyncza modyfikacja workflowu może ujawnić sekrety w wielu systemach downstream.

Czy Megalodon był powiązany z naruszeniem rozszerzenia VS Code GitHub?

Mniej więcej w tym samym czasie GitHub ujawnił osobny incydent bezpieczeństwa związany z zatrutym rozszerzeniem Visual Studio Code zainstalowanym na urządzeniu pracownika. Złośliwe rozszerzenie umożliwiło atakującym dostęp do około 3800 wewnętrznych repozytoriów GitHub, zanim kompromitacja została opanowana.

To naruszenie zostało prześledzone do skompromitowanego środowiska programisty i obejmowało kradzież danych uwierzytelniających za pośrednictwem trojanizowanego rozszerzenia dystrybuowanego za pośrednictwem rynku VS Code.

Niektóre raporty bezpieczeństwa zauważają podobieństwa w czasie i taktyce między tym incydentem a innymi atakami na łańcuch dostaw wymierzonymi w narzędzia deweloperskie. Jednak publiczne dowody nie potwierdziły, że wewnętrzne naruszenie GitHub bezpośrednio umożliwiło kampanię Megalodon.

Na razie oba incydenty najlepiej rozumieć jako osobne, ale współczesne zdarzenia w zakresie bezpieczeństwa łańcucha dostaw, które dotknęły ekosystem programistów.

Szersza lekcja dla bezpieczeństwa CI/CD

Megalodon pokazuje, jak szybko automatyzacja może rozprzestrzenić atak na łańcuch dostaw na tysiące repozytoriów. Łącząc podszywanie się pod boty, zautomatyzowane commity i zatrute workflowy CI, atakujący zamienili rutynową infrastrukturę budowania w system kradnący dane uwierzytelniające.

Incydent wzmocnił kilka priorytetów obronnych dla zespołów programistycznych:

• ścisłe reguły ochrony gałęzi
• obowiązkowe przeglądy zmian w workflowach
• minimalne uprawnienia dla zadań CI
• uważne monitorowanie kont automatyzacji i aktualizacji workflowów

Ponieważ potoki programistyczne coraz częściej kontrolują wdrożenia chmurowe i infrastrukturę produkcyjną, bezpieczeństwo workflowów CI/CD stało się kluczową częścią obrony łańcucha dostaw oprogramowania.