Atak Megalodon uderza w 5 561 repozytoriów GitHub w ciągu sześciu godzin
Atak na łańcuch dostaw CI/CD GitHub o nazwie Megalodon ustanowił nowy punkt odniesienia dla zautomatyzowanego, wielkoskalowego kompromitowania repozytoriów. W ciągu zaledwie sześciu godzin atakujący wprowadzili 5 718 złośliwych aktualizacji kodu w 5 561 repozytoriach GitHub, używając fałszywych tożsamości do wstrzykiwania plików workflow zaprojektowanych do cichego wykradania danych uwierzytelniających chmury, kluczy SSH i sekretów kodu źródłowego. Sama szybkość i skala kampanii sygnalizuje przejście w kierunku zindustrializowanych ataków na potoki CI/CD, które przerastają możliwości większości zespołów w zakresie wykrywania incydentów i reagowania na nie w czasie rzeczywistym.
Jak działał atak Megalodon: fałszywe tożsamości i automatyczne wstrzykiwanie workflow
Atakujący stojący za Megalodonem nie polegali na exploitach zero-day ani na zaawansowanym złośliwym oprogramowaniu dostarczanym na maszyny użytkowników końcowych. Zamiast tego wykorzystali zaufany charakter samej infrastruktury CI/CD GitHub. Tworząc fałszywe tożsamości współpracowników, składali pull requesty lub bezpośrednio modyfikowali pliki konfiguracyjne workflow — konkretnie pliki YAML, których GitHub Actions używa do definiowania zautomatyzowanych potoków budowania i wdrażania.
Gdy złośliwy plik workflow trafia do repozytorium, wykonuje się automatycznie za każdym razem, gdy uruchamia się potok — zazwyczaj przy zdarzeniach push lub scaleniu pull requestów. Wykonanie to ma miejsce wewnątrz środowiska runner samego GitHub, które często ma dostęp do sekretów repozytorium, zmiennych środowiskowych i tokenów przypisanych do dostawców chmury. Workflow Megalodon wykorzystywały to okno dostępu do eksfiltracji danych na zewnątrz — prawdopodobnie do infrastruktury kontrolowanej przez atakujących — zanim jakikolwiek opiekun repozytorium miał powód, by przejrzeć zmianę.
Definiującą cechą kampanii jest jej automatyzacja. Wykonanie niemal 5 720 odrębnych wypchnięć kodu w ponad 5 500 repozytoriach w ciągu sześciu godzin to nie jest działanie manualne. Wymaga skryptowych narzędzi zdolnych do identyfikowania celów, uwierzytelniania za pomocą fałszywych tożsamości, tworzenia wiarygodnie wyglądających modyfikacji workflow i składania ich równolegle. Ten poziom automatyzacji oznacza, że powierzchnia ataku rozrastała się szybciej, niż jakikolwiek ludzki zespół monitorujący był w stanie śledzić.
Jakie dane uwierzytelniające zostały skradzione i dlaczego ma to znaczenie dla programistów
Ładunkiem każdego złośliwego workflow było zbieranie danych uwierzytelniających. Celem były dane uwierzytelniające dostawców chmury — najczęściej klucze dostępu AWS, GCP i Azure przechowywane jako GitHub Secrets lub odwoływane wewnątrz zmiennych środowiskowych workflow. W zakresie zainteresowania atakujących znajdowały się również prywatne klucze SSH używane do dostępu do serwerów lub uwierzytelniania między usługami, a także wszelkie sekrety w postaci zwykłego tekstu osadzone w kodzie źródłowym lub plikach konfiguracyjnych.
Tego rodzaju dane uwierzytelniające niosą ze sobą ryzyko kaskadowe. Skradziony klucz dostępu AWS powiązany z rolą IAM o szerokich uprawnieniach może pozwolić atakującemu na uruchomienie infrastruktury, eksfiltrację magazynów danych lub ruch boczny do powiązanych usług w ciągu kilku minut. Klucze SSH mogą zapewniać trwały dostęp do serwerów produkcyjnych długo po tym, jak pierwotne naruszenie zostało wykryte, a repozytorium GitHub wyczyszczone. Wartość tych danych daleko wykracza poza same repozytoria.
To nie jest hipotetyczny wzorzec ryzyka. Wcześniej w tym roku kontrahent CISA ujawnił klucze AWS i hasła w postaci zwykłego tekstu w publicznym repozytorium GitHub, co pokazuje, że błędne zarządzanie danymi uwierzytelniającymi w środowiskach programistycznych dotyka nawet organizacje posiadające dedykowane mandaty bezpieczeństwa. Megalodon po prostu zindustrializował tę samą ścieżkę exploitacji, którą indywidualne błędy ludzkie już wielokrotnie demonstrowały.
Warto też zauważyć, że narzędzia i potoki służące do kradzieży danych uwierzytelniających same są celami. Niedawny atak na łańcuch dostaw Bitwarden CLI pokazał, że nawet narzędzia, których programiści używają do zarządzania sekretami, mogą zostać skompromitowane na wyższym poziomie — co oznacza, że łańcuch zaufania sięga dalej niż jedno repozytorium czy konfiguracja potoku.
Obrona wielowarstwowa dla zespołów programistycznych: zarządzanie sekretami, szyfrowana komunikacja i kontrola dostępu
Megalodon wykorzystał kilka słabości powszechnych zarówno w repozytoriach open source, jak i prywatnych. Ich eliminacja wymaga podejścia warstwowego, a nie jednej pojedynczej kontroli.
Po pierwsze, sekrety nigdy nie powinny być przechowywane jako zwykły tekst wewnątrz plików workflow, plików konfiguracji środowiska ani kodu źródłowego. Funkcja szyfrowanych Secrets GitHub stanowi punkt wyjścia, ale te sekrety powinny też stosować zasadę najmniejszych uprawnień. Workflow wdrażający do środowiska staging nie potrzebuje danych uwierzytelniających do produkcyjnej bazy danych. Ścisłe ograniczenie zakresu sekretów minimalizuje zasięg skutków w przypadku kompromitacji workflow.
Po drugie, reguły ochrony gałęzi i wymagani recenzenci zmian plików workflow tworzą ludzki punkt kontrolny, który zautomatyzowane ataki muszą obejść. Wymaganie co najmniej jednej zatwierdzonej recenzji przed jakąkolwiek modyfikacją plików .github/workflows/ może spowolnić lub zablokować rodzaj szybkiego automatycznego wstrzykiwania, na którym opierał się Megalodon.
Po trzecie, przypinanie zewnętrznych GitHub Actions do konkretnych SHA commitów zamiast zmiennych tagów zapobiega oddzielnemu, ale powiązanemu wektorowi ataku, w którym skompromitowani wydawcy action cicho aktualizują tag, kierując go do złośliwego kodu. Był to mechanizm kilku niedawnych incydentów w łańcuchu dostaw GitHub Actions.
Na koniec, logowanie audytowe i wykrywanie anomalii w przebiegach workflow mogą ujawniać nieoczekiwane wychodzące połączenia sieciowe lub nietypowe wzorce dostępu do sekretów. Interfejs API dziennika audytu GitHub oraz zewnętrzne narzędzia bezpieczeństwa CI/CD mogą pomóc w wykrywaniu tych sygnałów.
Jak teraz przeprowadzić audyt repozytoriów GitHub i potoków CI/CD
Jeśli Twoja organizacja utrzymuje repozytoria GitHub z aktywnymi potokami CI/CD, kilka natychmiastowych kroków zasługuje na priorytetowe potraktowanie.
Przejrzyj wszystkie pliki w katalogu .github/workflows/ pod kątem niedawno dodanych lub zmodyfikowanych wpisów — szczególnie tych dodanych przez współpracowników, których nie rozpoznajesz. Sprawdź historię commitów specjalnie dla plików workflow, a nie tylko widok domyślnej gałęzi.
Rotuj wszelkie sekrety, które były aktywne w okresie ataku lub co do których nie możesz z pewnością potwierdzić, że nie zostały ujawnione. W przypadku danych uwierzytelniających chmury przejrzyj logi dostępu po stronie dostawcy pod kątem nietypowych wywołań API w tym samym oknie czasowym.
Przeprowadź audyt tego, którzy współpracownicy i aplikacje mają dostęp do zapisu w repozytorium. Ataki oparte na fałszywych tożsamościach zależą od możliwości wypychania kodu, więc zaostrzenie uprawnień współpracowników i włączenie wymaganych recenzji dla zmian workflow eliminuje kluczowy punkt wejścia.
Na koniec rozważ wdrożenie dedykowanego narzędzia do skanowania sekretów, które uruchamia się przy każdym commicie, wychwytując dane uwierzytelniające zanim zostaną kiedykolwiek zatwierdzone do repozytorium. Kilka opcji open source i komercyjnych integruje się bezpośrednio z GitHub.
Co to oznacza dla Ciebie
Kampania Megalodon jest praktycznym przykładem tego, dlaczego potoki CI/CD stały się główną powierzchnią ataku. Programiści i zespoły ds. bezpieczeństwa, które traktują bezpieczeństwo potoków jako drugorzędne wobec bezpieczeństwa aplikacji, zostawiają szeroko otwartą ścieżkę do swoich najbardziej wrażliwych danych uwierzytelniających.
Zacznij od audytu sekretów w tym tygodniu. Przejrzyj, kto może modyfikować Twoje pliki workflow, rotuj dane uwierzytelniające, których nie możesz zweryfikować jako czyste, i włącz ochronę gałęzi na domyślnej gałęzi, jeśli jeszcze tego nie zrobiłeś. Szybkość ataku Megalodon oznacza, że w momencie wysłania alertu eksfiltracja może już być zakończona. Prewencja i ograniczenie zakresu dostępu to jedyne niezawodne środki obrony.
