Pakiety npm Red Hat zaatakowane: ponad 30 repozytoriów rozsyła złodzieja poświadczeń chmurowych

Skoordynowana kampania kradzieży poświadczeń w łańcuchu dostaw npm uderzyła w jedną z najbardziej rozpoznawalnych marek oprogramowania dla przedsiębiorstw. Nieznani atakujący przejęli ponad 30 pakietów npm Red Hat Cloud Services, najpierw przechwytując konto GitHub pracownika Red Hat, a następnie wykorzystując ten dostęp do dostarczenia złośliwych commitów. Złośliwe oprogramowanie osadzone w tych pakietach, zidentyfikowane jako wariant szczepu „Mini Shai-Hulud”, uruchamia się automatycznie podczas instalacji i natychmiast rozpoczyna eksfiltrację poświadczeń chmurowych, w tym kluczy dostępu AWS, GCP i Azure, a także kluczy SSH i plików konfiguracyjnych Kubernetes.

Ten incydent wyróżnia się nie z powodu słabości samego npm, lecz ze względu na sposób, w jaki atakujący weszli: poprzez legalną, zaufaną tożsamość dewelopera.

W jaki sposób pakiety npm Red Hat zostały przejęte

Łańcuch ataku rozpoczął się od przejęcia jednego konta GitHub należącego do pracownika Red Hat. Po dostaniu się na to konto atakujący uzyskali dostęp niezbędny do bezpośredniego wypychania kodu do repozytoriów powiązanych z pakietami npm Red Hat Cloud Services. Ponieważ commity pochodziły z rozpoznawanego konta współtwórcy, zautomatyzowane potoki i recenzenci mieli znacznie większą trudność w wykryciu czegoś podejrzanego.

To jest definiująca cecha ataku na łańcuch dostaw oprogramowania: złośliwy ładunek przemieszcza się wewnątrz legalnego oprogramowania, podpisanego i dystrybuowanego za pośrednictwem zaufanych kanałów. Deweloperzy, którzy zainstalowali lub zaktualizowali którykolwiek z dotkniętych pakietów w oknie przejęcia, nieświadomie uruchomili złośliwe oprogramowanie na własnych systemach bez żadnego oczywistego ostrzeżenia. Same pakiety nadal działały normalnie, co dodatkowo utrudniało wykrycie.

Wariant złośliwego oprogramowania „Mini Shai-Hulud” został specjalnie zaprojektowany, aby uruchamiać się w momencie instalacji, w chwili, gdy deweloper wpisze npm install. Nie czeka na uruchomienie aplikacji ani na interakcję użytkownika. Takie podejście dramatycznie skraca czas między infekcją a eksfiltracją.

Jakie poświadczenia zostały skradzione i dlaczego są ważne

Lista celów złośliwego oprogramowania przypomina listę kontrolną najbardziej szkodliwych rzeczy, jakie atakujący mógłby wydobyć ze stacji roboczej dewelopera lub uruchamiacza potoku CI/CD. Pliki poświadczeń AWS, Google Cloud Platform i Azure są głównymi celami, ponieważ klucze te często mają szerokie uprawnienia w całej infrastrukturze produkcyjnej. Prywatne klucze SSH i pliki konfiguracyjne Kubernetes dopełniają zdobyczy, dając atakującym potencjalne ścieżki ruchu bocznego do sieci wewnętrznych i klastrów orkiestracji kontenerów.

Dla organizacji korzystających z zautomatyzowanych potoków budowania ryzyko ekspozycji jest większe. Systemy CI/CD często przechowują długoterminowe poświadczenia chmurowe jako zmienne środowiskowe lub zamontowane sekrety. Pojedynczy zainfekowany uruchamiacz budowania może po cichu przekazać klucze kontrolujące całe środowiska chmurowe, potencjalnie otwierając drzwi do eksfiltracji danych, wdrożenia ransomware lub trwałego dostępu typu backdoor.

To również dlatego zespoły bezpieczeństwa powinny pamiętać, że punkty wejścia w łańcuch dostaw często łączą się z głębszym przejęciem systemu. Niedawne ostrzeżenie CISA dotyczące CVE-2026-31431, luki w eskalacji uprawnień lokalnych w systemie Linux jest bezpośrednim przypomnieniem: atakujący, którzy dostają się na system ze skradzionymi poświadczeniami lub początkowym dostępem, rzadko na tym poprzestają. Szukają kolejnego ogniwa w łańcuchu.

Dlaczego ataki na łańcuch dostaw są martwym punktem dla standardowych zabezpieczeń

Konwencjonalne narzędzia bezpieczeństwa są zbudowane wokół założenia, że zagrożeniem jest zewnętrzny, niepodpisany lub nieznany kod. Zapory sieciowe, agenci wykrywania punktów końcowych i skanery oparte na sygnaturach są skalibrowane, aby oznaczać anomalie. Ataki na łańcuch dostaw obalają ten model, ukrywając się w oprogramowaniu, które ma legalny podpis i dociera oczekiwanym kanałem.

W tym przypadku marka Red Hat i powiązana historia konta GitHub nadały przejętym pakietom wysoki stopień dorozumianego zaufania. Deweloperzy pracujący nad infrastrukturą powiązaną z Red Hat mogli instalować te pakiety właśnie dlatego, że oczekiwali, iż będą one dobrze utrzymywane i bezpieczne.

Standardowe narzędzia do skanowania zależności, które sprawdzają znane podatne wersje, nie wykryłyby złodziei poświadczeń uruchamianych podczas instalacji, chyba że złośliwa wersja została już oznaczona w bazie danych luk. Atak wykorzystuje lukę między wykrywaniem „znanego zła” a analizą behawioralną.

Warstwowe zabezpieczenia: zarządzanie sekretami, segmentacja sieci i sieci VPN

Żadna pojedyncza kontrola nie powstrzyma wyrafinowanego ataku na łańcuch dostaw, ale warstwowe zabezpieczenia mogą znacznie zmniejszyć promień rażenia.

Zarządzanie sekretami zamiast lokalnych plików poświadczeń. Najskuteczniejszym środkiem zaradczym jest całkowite wyeliminowanie statycznych plików poświadczeń z komputerów deweloperskich i uruchamiaczy CI/CD. Narzędzia wydające krótkoterminowe poświadczenia just-in-time oznaczają, że nawet jeśli poświadczenie zostanie skradzione, wygasa, zanim atakujący zdąży z niego w znaczący sposób skorzystać.

Przypinanie zależności i weryfikacja integralności. Blokowanie pakietów do konkretnych, zweryfikowanych skrótów commitów zamiast zakresów wersji zmiennoprzecinkowych ogranicza narażenie na nieoczekiwane zmiany kodu. Połączenie tego z automatycznymi kontrolami integralności zawartości pakietów dodaje kolejną warstwę wykrywania.

Segmentacja sieci i filtrowanie ruchu wychodzącego. Złośliwe oprogramowanie Mini Shai-Hulud musi gdzieś wysłać skradzione dane. Ograniczenie połączeń wychodzących ze środowisk budowania i komputerów deweloperskich do znanych punktów końcowych może zapobiec eksfiltracji, nawet gdy złośliwe oprogramowanie zostanie pomyślnie uruchomione. Sieci VPN i architektury sieciowe zero-trust mogą egzekwować te zasady ruchu wychodzącego w sposób spójny w rozproszonych zespołach.

Uwierzytelnianie wieloskładnikowe na każdym koncie dewelopera. Początkowe przejęcie tutaj polegało na przejęciu konta GitHub. Silne wymagania MFA, w szczególności sprzętowe klucze bezpieczeństwa lub uwierzytelnianie oparte na kluczach dostępu, znacznie utrudniają przechwycenie konta.

Monitorowanie behawioralne w potokach CI/CD. Alarmowanie o nieoczekiwanych zapytaniach DNS lub połączeniach sieciowych wychodzących podczas fazy budowania może ujawnić złośliwe oprogramowanie działające podczas instalacji, zanim skradzione poświadczenia zostaną wykorzystane.

Co to oznacza dla Ciebie

Jeśli Twoje środowisko programistyczne lub operacyjne zależy od jakichkolwiek pakietów npm Red Hat Cloud Services, natychmiastowym priorytetem jest sprawdzenie, które wersje pakietów są używane, poszukanie wskaźników przejęcia w logach sieciowych wokół zdarzeń instalacji oraz rotacja wszelkich poświadczeń chmurowych, które mogły znajdować się na dotkniętych systemach.

Szerzej rzecz ujmując, ten incydent jest impulsem do kompleksowego przeglądu higieny poświadczeń chmurowych. Czy poświadczenia są przechowywane jako pliki na komputerach deweloperskich? Czy zmienne środowiskowe CI/CD są ograniczone do minimalnych uprawnień? Czy MFA jest egzekwowane na każdym koncie z uprawnieniami do publikowania pakietów?

Ataki na łańcuch dostaw odnoszą sukces, wykorzystując zaufanie. Środkiem zaradczym jest budowanie systemów, które nie polegają wyłącznie na dorozumianym zaufaniu – zweryfikowane tożsamości, ograniczone czasowo sekrety i monitorowanie behawioralne stanowią fundament. Zacznij od audytu poświadczeń już dziś i traktuj każdą zależność jako potencjalną powierzchnię ataku, która zasługuje na kontrolę.