Wariant osławionego robaka Shai-Hulud zakłócił działanie repozytoriów Microsoftu w GitHubie, psując przepływy CI/CD i budząc nowe obawy o szybkość i zasięg współczesnych ataków na łańcuch dostaw oprogramowania.
Incydent rozegrał się 5 czerwca, kiedy GitHub w niecałe dwie minuty automatycznie wyłączył 73 repozytoria Microsoftu po wykryciu potencjalnych naruszeń warunków korzystania z usługi. Większość dotkniętych repozytoriów należała do organizacji Azure Microsoftu.
Zakłócenie miało natychmiastowy wpływ na dalszych użytkowników. Organizacje na całym świecie, które polegały na dotkniętych akcjach GitHub Actions, nagle zobaczyły, że ich potoki budowania i wdrażania przestały działać.
Jednym z najbardziej widocznych przykładów była akcja Azure/functions-action, używana w GitHub Actions do wdrażania Azure Functions. Gdy akcja przestała być rozwiązywana, każdy przepływ pracy odwołujący się do Azure/functions-action@v1 mógł przestać działać.
Incydent pokazuje, jak kruche mogą być współczesne ekosystemy CI/CD, gdy zaufana infrastruktura deweloperska zostaje przejęta lub tymczasowo wyłączona.
Od Shai-Hulud do Miasma
Aktywność powiązano z Miasma, wariantem robaka Mini Shai-Hulud.
Ataki w stylu Shai-Hulud są niebezpieczne, ponieważ rozprzestrzeniają się zaufanymi kanałami tworzenia oprogramowania, takimi jak rejestry pakietów, repozytoria, GitHub Actions i narzędzia deweloperskie.
Wcześniejsze kampanie Shai-Hulud i Mini Shai-Hulud koncentrowały się głównie na kradzieży sekretów deweloperów i danych uwierzytelniających do chmury. Miasma wydaje się podążać tą samą logiką, ale ze zmianą techniki dostarczania.
Zamiast polegać wyłącznie na zatrutych pakietach, aktywność z 5 czerwca nadużywała plików konfiguracyjnych repozytoriów, które wykonują się, gdy deweloperzy otwierają przejęte repozytoria w niektórych narzędziach do kodowania z AI lub zintegrowanych środowiskach programistycznych.
To ważna ewolucja.
Atakujący przesuwają się w stronę najmniej monitorowanych zaufanych obszarów w przepływie pracy dewelopera.
Repozytoria Microsoftu wyłączone
Open Source Malware jako pierwszy poinformował o incydencie z 5 czerwca, zauważając, że GitHub wyłączył 73 repozytoria Microsoftu w ramach automatycznego przeglądu.
Repozytoria zostały później przywrócone po weryfikacji, ale ich tymczasowe usunięcie nadal spowodowało realne problemy operacyjne dla dalszych użytkowników.
GitHub Actions to nie zwykłe biblioteki. Działają wewnątrz potoków CI/CD innych organizacji.
Oznacza to, że gdy powszechnie używana akcja znika, przepływy pracy, które od niej zależą, mogą natychmiast przestać działać.
W przypadku organizacji wdrażających Azure Functions usunięcie Azure/functions-action i powiązanych akcji spowodowało awarie potoków wyłącznie dlatego, że wskazanej akcji nie można było już rozwiązać.
Uwydatnia to poważny problem zależności w łańcuchu dostaw: wiele organizacji polega na zewnętrznych akcjach CI/CD, nad którymi nie ma kontroli.
Związek z przejęciem pakietu Microsoftu w PyPI
StepSecurity powiązała przejęcie repozytoriów z 5 czerwca z wcześniejszym incydentem dotyczącym oficjalnego pakietu Microsoftu, Python SDK durabletask, w PyPI.
19 maja do PyPI opublikowano trzy zatrute wersje tego pakietu. Pakiet zwykle ma około 400 000 pobrań miesięcznie.
Złośliwe wersje były dostępne online przez około 35 minut, zanim Microsoft je usunął.
Według StepSecurity zatrute wersje zawierały modułowy framework do włamań do chmury o nazwie rope.pyz. Framework ten został zaprojektowany do kradzieży sekretów i danych uwierzytelniających, a w niektórych regionach mógł też wdrażać destrukcyjnego wipera.
Atakujący miał rzekomo przejąć prawdziwe dane uwierzytelniające do publikowania oficjalnego pakietu Microsoftu i całkowicie ominąć potok budowania repozytorium.
Ten wcześniejszy incydent jest obecnie uznawany za część szerszej aktywności TeamPCP i Mini Shai-Hulud w łańcuchu dostaw oprogramowania.
Ponowne użycie lub ponowne przejęcie dostępu współtwórcy
StepSecurity zauważyła, że złośliwy commit w atakach z 5 czerwca pochodził z tego samego konta współtwórcy, które powiązano z wcześniejszym przejęciem pakietu Microsoftu w PyPI.
Nasunęło to kilka możliwości.
Jedna z nich zakłada, że po incydencie z 19 maja dane uwierzytelniające nie zostały w pełni zmienione ani unieważnione.
Inna, że konto zostało przejęte ponownie za pośrednictwem własnej pętli propagacji robaka.
Trzecia możliwość jest taka, że atakujący użyli tokena innego współtwórcy i sfałszowali metadane autora commita za pomocą interfejsu Git Data API GitHuba.
Główna ocena StepSecurity zakładała, że mogło dojść do ponownego przejęcia przez pętlę propagacji robaka, być może w połączeniu z niepełną rotacją danych uwierzytelniających.
To kluczowa lekcja dla reagowania na incydenty: po ataku na łańcuch dostaw częściowa rotacja danych uwierzytelniających nie wystarczy. Trzeba przejrzeć każdy powiązany token, sesję, klucz i uprawnienie do publikowania.
Narzędzia do kodowania z AI jako nowa powierzchnia ataku
Jednym z najważniejszych szczegółów tego incydentu jest skupienie się złośliwego oprogramowania na narzędziach do kodowania z AI.
StepSecurity poinformowała, że złośliwe oprogramowanie kradnące dane uwierzytelniające atakowało:
- Anthropic Claude Code
- Google Gemini CLI
- Cursor
- Visual Studio Code
Zamiast zatruwać wyłącznie haki instalacyjne menedżerów pakietów, atakujący podrzucali pliki konfiguracyjne dla tych narzędzi i środowisk IDE.
Pliki te mogły wykonywać kod, gdy deweloper otwierał przejęte repozytorium.
Oznacza to, że deweloper niekoniecznie musiał instalować pakiet ani uruchamiać kompilacji. Samo otwarcie sklonowanego repozytorium w niewłaściwym środowisku mogło uaktywnić złośliwy ładunek.
To poważna zmiana w atakach na łańcuch dostaw.
Obrońcy przez lata monitorowali rejestry pakietów, manifesty zależności, skrypty instalacyjne i wykonywanie potoków CI/CD. Jednak agenci kodowania z AI i pliki konfiguracyjne IDE są nowsze i często mniej monitorowane.
Atakujący dostrzegli tę lukę.
Dlaczego tę technikę trudno wykryć
Atak z 5 czerwca ominął niektóre tradycyjne ścieżki wykrywania.
Pobranie lub sklonowanie repozytorium może nie wywołać alertu, ponieważ repozytoria są zwykle uznawane za zaufane zasoby deweloperskie.
Otwarcie repozytorium w IDE lub agencie kodowania z AI również jest normalnym zachowaniem dewelopera.
Ale jeśli repozytorium zawiera złośliwe pliki konfiguracyjne dla narzędzi takich jak Claude Code, Gemini CLI, Cursor czy VS Code, atakujący może wykonać kod za pośrednictwem zaufanego przepływu pracy, którego wiele skanerów nie analizuje jeszcze dogłębnie.
Przenosi to punkt ataku z instalacji pakietów na aktywację środowiska dewelopera.
Zagrożenie to już nie tylko pytanie „jaką zależność zainstalowałeś?”. To także pytanie „jakiej konfiguracji twój edytor lub narzędzie do kodowania z AI automatycznie zaufało?”.
Dlaczego okno ekspozycji ma znaczenie
Automatyczne zabezpieczenia GitHuba podobno oznaczyły i usunęły dotknięte repozytoria w ciągu kilku godzin.
To może brzmieć szybko, ale w przypadku samorozprzestrzeniającego się robaka nawet krótkie okno ekspozycji może wystarczyć.
Jeśli deweloper sklonował dotknięte repozytorium i otworzył je w jednym z atakowanych narzędzi, dane uwierzytelniające mogły zostać przechwycone niemal natychmiast.
Skradzione dane uwierzytelniające mogły następnie posłużyć do wypychania kolejnych złośliwych commitów, publikowania zatrutych pakietów lub przejmowania kolejnych kont.
Tworzy to narastający promień rażenia.
W atakach na łańcuch dostaw typu robak pytanie nie dotyczy wyłącznie tego, jak długo złośliwe oprogramowanie było obecne. Chodzi o to, kto miał z nim styczność w tym oknie i jaki dostęp dawały jego dane uwierzytelniające.
Jedno cenne konto dewelopera może wystarczyć, by zapoczątkować kolejną falę.
Potoki CI/CD jako wyjątkowo wrażliwe zależności
Incydent pokazuje także, jak bardzo organizacje polegają na zewnętrznych elementach składowych CI/CD.
GitHub Actions są często wskazywane bezpośrednio w przepływach pracy, czasem za pomocą tagów takich jak @v1.
Jeśli akcja zostanie przejęta, wyłączona, usunięta lub zastąpiona, potoki zależne od niej mogą przestać działać lub stać się niebezpieczne.
Organizacje powinny traktować zależności CI/CD jak zależności produkcyjne.
Dotyczy to między innymi:
- GitHub Actions
- wielokrotnego użytku przepływów pracy
- narzędzi do budowania innych dostawców
- akcji wdrożeniowych
- automatyzacji publikowania pakietów
- agentów kodowania z AI
- narzędzi do generowania kodu
- rozszerzeń IDE
- plików konfiguracyjnych repozytoriów
Przejęcie którejkolwiek z tych warstw może wpłynąć na integralność kompilacji.
Co powinny zrobić organizacje, które sklonowały dotknięte repozytoria
StepSecurity wezwała organizacje, które sklonowały dotknięte repozytoria Microsoftu po 2 czerwca i otworzyły je w atakowanych narzędziach do kodowania z AI lub środowiskach IDE, aby przyjęły założenie, że doszło do kompromitacji.
Zalecane kroki reagowania obejmują:
- zmianę wszystkich danych uwierzytelniających deweloperów
- zmianę tokenów GitHub
- zmianę tokenów do publikowania w npm i PyPI
- zmianę danych uwierzytelniających do chmury
- przegląd sekretów CI/CD
- audyt przepływów pracy GitHub Actions
- kontrolę lokalnych maszyn deweloperów
- przegląd pakietów opublikowanych po ekspozycji
- sprawdzenie podejrzanych commitów
- kontrolę logów pod kątem ruchu wychodzącego do infrastruktury atakujących
- audyt użycia plików konfiguracyjnych Claude Code, Gemini CLI, Cursor i VS Code
- sprawdzenie nieoczekiwanych zmian w konfiguracji narzędzi
Jeśli system dewelopera miał styczność ze złośliwą konfiguracją, należy zakładać kradzież danych uwierzytelniających, dopóki nie zostanie to obalone.
Zapobieganie podobnym atakom
Organizacje powinny rozszerzyć zabezpieczenia łańcucha dostaw o narzędzia do kodowania z AI i konfigurację na poziomie repozytorium.
Zalecane mechanizmy kontroli obejmują:
- sprawdzanie sklonowanych repozytoriów pod kątem podejrzanych plików konfiguracyjnych agentów AI
- przegląd ustawień przestrzeni roboczej VS Code przed otwarciem nieznanych repozytoriów
- wyłączanie funkcji automatycznego wykonywania tam, gdzie to możliwe
- blokowanie narzędziom do kodowania z AI automatycznego uruchamiania dowolnych poleceń
- monitorowanie wychodzącego dostępu sieciowego ze stacji roboczych deweloperów
- ograniczanie wychodzącego dostępu z runnerów CI/CD
- wymaganie reguł ochrony gałęzi dla wszystkich commitów
- wymaganie przeglądu zmian w plikach przepływów pracy i konfiguracji
- przypinanie GitHub Actions do zaufanych skrótów SHA commitów tam, gdzie to możliwe
- ograniczanie uprawnień zapisu w repozytoriach
- stosowanie krótkotrwałych danych uwierzytelniających o ograniczonym zakresie
- zmianę tokenów po każdym podejrzeniu kompromitacji
- monitorowanie nieoczekiwanego publikowania pakietów
- regularny audyt współtwórców i aktywnych tokenów
Kluczem jest traktowanie środowisk kodowania z AI jako części powierzchni ataku.
Dlaczego ochrona gałęzi ma znaczenie
Reguły ochrony gałęzi mogą zmniejszyć szansę, że złośliwe commity trafią do repozytorium niezauważone.
Organizacje powinny wymagać:
- przeglądów pull requestów
- kontroli statusu
- podpisanych commitów tam, gdzie to właściwe
- ograniczonych zmian w plikach przepływów pracy
- zatwierdzania zmian w GitHub Actions
- chronionych gałęzi wydań
- ograniczonego dostępu do bezpośredniego wypychania zmian
- obowiązkowego przeglądu plików konfiguracyjnych
Szczególną uwagę należy zwrócić na pliki sterujące procesem budowania, zachowaniem IDE, agentami kodowania z AI lub publikowaniem pakietów.
Atakujący coraz częściej celują w pliki, które wyglądają na konfigurację, a nie na oczywisty kod źródłowy.
Kontrole ruchu wychodzącego są kluczowe
Wiele ataków na łańcuch dostaw opiera się na eksfiltracji skradzionych danych uwierzytelniających do infrastruktury dowodzenia i kontroli.
Organizacje powinny ograniczać wychodzący dostęp z runnerów CI/CD i środowisk deweloperskich tam, gdzie to możliwe.
Przydatne mechanizmy kontroli obejmują:
- listy dozwolonych adresów ruchu wychodzącego (egress allowlisting) dla runnerów CI/CD
- blokowanie znanych złośliwych domen C2
- monitorowanie nietypowych zapytań DNS
- alertowanie o nieoczekiwanych wychodzących żądaniach HTTP
- ograniczanie dostępu do serwisów typu paste i anonimowych hostingów plików
- kontrolę ruchu ze środowisk budowania
- oddzielenie systemów budowania od środowisk, w których deweloperzy przeglądają internet
Runnery CI/CD często przechowują wrażliwe sekrety. Nie powinny mieć nieograniczonego dostępu wychodzącego do internetu, chyba że istnieje wyraźna potrzeba.
Wnioski z incydentu
Incydent z Miasmą uwydatnia kilka wniosków.
Po pierwsze, robaki w łańcuchu dostaw oprogramowania mogą szybko rozprzestrzeniać się przez zaufaną infrastrukturę deweloperską.
Po drugie, powszechnie używane GitHub Actions mogą stać się pojedynczymi punktami awarii dla globalnych potoków CI/CD.
Po trzecie, rotacja danych uwierzytelniających po kompromitacji musi być pełna i zweryfikowana.
Po czwarte, narzędzia do kodowania z AI i pliki konfiguracyjne IDE są dziś aktywnymi powierzchniami ataku.
Po piąte, krótkie okna ekspozycji mogą nadal stwarzać poważne ryzyko, gdy w grę wchodzi samorozprzestrzeniające się złośliwe oprogramowanie.
Obrońcy muszą rozszerzyć spojrzenie na bezpieczeństwo łańcucha dostaw oprogramowania poza rejestry pakietów.
Podsumowanie
Wpływ robaka Miasma na repozytoria Microsoftu w GitHubie to ostrzeżenie przed kolejną fazą ataków na łańcuch dostaw oprogramowania.
Zakłócenie działania 73 repozytoriów Microsoftu było samo w sobie poważne, ale głębszy problem tkwi w technice: atakujący przechodzą od zatrutych instalacji pakietów do zaufanych środowisk deweloperskich i konfiguracji narzędzi do kodowania z AI.
Utrudnia to wykrywanie i poszerza powierzchnię ataku.
Organizacje powinny przejrzeć wszystkie repozytoria sklonowane w oknie ekspozycji, w razie potrzeby zmienić dane uwierzytelniające, sprawdzić pliki konfiguracyjne agentów AI i wzmocnić przepływy pracy CI/CD.
Wniosek jest jasny: we współczesnych łańcuchach dostaw oprogramowania zaufanie trzeba weryfikować na każdej warstwie — także w narzędziach, których deweloperzy używają do pisania kodu.
