„Tak, zhakowali mnie, przepraszam” – czyli „największy” atak na łańcuch dostaw (z phishingiem w tle) – straty wyceniono na $20.05

Ataki na łańcuchy dostaw są skuteczną metodą przejmowania nawet złożonego i względnie bezpiecznego oprogramowania, o czym przekonują się nie tylko programiści niewielkich projektów, ale też duże organizacje (w tym rządowe) – niektórym z nich do dzisiaj czkawką odbija się atak wykorzystujący oprogramowanie SolarWinds (zdarzenie miało miejsce w 2020 roku). Tym razem chodzi jednak o listę otwartych bibliotek npm. Nieznani atakujący przesłali phishingowe maile do developerów utrzymujących kilkanaście popularnych projektów w celu przejęcia ich kont i wprowadzenia złosliwych zmian.

TLDR:

• Konta w serwisie npmjs.com przynajmniej dwóch developerów zostały przejęte w kampanii kierowanego ataku phishingowego. 
• Cyberzbóje wykorzystali dostęp do rejestru npm aby dodać złośliwy kod do popularnych paczek, które sumarycznie miały ponad dwa miliardy pobrań.
• Złośliwa aktualizacja zawierała kod stealera, który miał za zadanie wykradać środki z portfeli kryptowalutowych.
• Atak przyniósł straty rzędu 20 USD i 5 centów.

Wczoraj – 08.09.2025, pojawiły się bardzo niepokojące informacje o możliwym ataku na łańcuch dostaw w ekosystemie Node.js (paczki obsługiwane przez manager npm). Według listy przedstawionej przez akidio.dev, zaatakowanych zostało 18 projektów (lista może nie być pełna), które sumarycznie są pobierane ponad dwa miliardy razy w tygodniu. Namierzone, zainfekowane projekty to:

• backslash 
• chalk-template 
• supports-hyperlinks 
• has-ansi 
• simple-swizzle 
• color-string 
• error-ex 
• color-name 
• is-arrayish 
• slice-ansi
• color-convert
• wrap-ansi
• ansi-regex
• supports-color
• strip-ansi
• chalk
• debug
• ansi-styles

Brzmi przerażająco, prawda? Całe szczęście, to tylko burza w szklance wody, ale też kolejna szansa na poprawienie kluczowych elementów bezpieczeństwa oprogramowania. Można zadać pytanie, dlaczego? Czyżbyśmy zbyt bagatelizowali zagrożenie płynące z tego ataku? 

Otóż nie do końca, żeby to zrozumieć, należy przyjrzeć się faktom dotyczącym tego incydentu. 

Atakujący rozesłali do osób utrzymujących paczki wiadomość e-mail z domeny npmjs[.]help – zarejestrowanej 05.09.2025 i wskazującej na host 185[.]7[.]81[.]108 (w chwili pisania tego artykułu strona nie jest już dostępna, ale wbudowane zabezpieczenia przeglądarek ostrzegają przed odwiedzeniem niebezpiecznego adresu). Informacje przesłane w wiadomości wskazywały na konieczność aktualizacji dwustopniowego uwierzytelnienia. Badacze z aikido.dev poinformowali Josha Junona posługującego się pseudonimem qix o tym, że wykryli zmiany przeprowadzone w repozytoriach projektów, za które odpowiadał na portalu bluesky. 

Rysunek 1. Screenshot phishingowej wiadomości wysłanej do programisty paczek npm (źródło)

Wiadomość została przesłana na adres email powiązany z kontem w npm, który można uzyskać między innymi z zawartości pliku package.json. 

Rysunek 2. Potencjalne źródło adresu email

Qix zareagował bardzo sprawnie i odniósł się do sprawy, informując o tym, że atak był wycelowany w jego konto na npm.

Rysunek 3. Informacja od autora projektów, w którym informuje o tym, że jest świadomy ataku (źródło)

Większość złośliwych zmian została usunięta przez Josha jeszcze zanim jego konto zostało zablokowane. 

Atakujący zmodyfikowali (linkujemy diffa dla zwiększonej czytelności) przejęte paczki poprzez dodanie złośliwego i zobfuskowanego (zacieminonego) kodu. Analiza zmian wskazywała, że dodana funkcjonalność odpowiedzialna jest za zmianę działania funkcji takich jak fetch czy XMLHttpRequest oraz celuje w interfejsy portfeli kryptowalut. Dzięki temu, oprogramowanie korzystające z przejętych paczek ma dostęp do treści zapytań HTTP generowanych przez przeglądarkę. Może nie tylko wykrywać informacje dotyczące zlecanych transferów kryptowalut, ale także dokonywać zmian w transakcjach. Stąd działanie jest już do przewidzenia – złośliwa paczka podmienia adres docelowy i maskuje swoje działanie przez modyfikację UI, w taki sposób aby nie wzbudzało podejrzeń. Atakujący wykorzystali kilka adresów portfeli docelowych, aby lekko ukryć działanie. Malware miało obsługiwać portfele BitCoin, Solany, Etherum. Co najważniejsze, analiza wskazuje, że stealer nie był zbudowany do pobierania innego malware czy próby zaatakowania hosta – jego celem były stricte portfele kryptowalut. Szczegółowe informacje o działaniu malware znajdują się tutaj.

Na koniec, jak słusznie zauważyli badacze na portalu X, wpływ tego incydentu na bezpieczeństwo środków użytkowników był znikomy, ponieważ pierwsze informacje o możliwym ataku pojawiły się godzinę po podmianie paczki (pierwszy atak został dostrzeżony w projekcie debug).

Złośliwe paczki zostały pobrane bardzo małą liczbę razy (Katie pisze o wartości 0, jednak malware wyrządził pewne straty, stąd zakładamy, że wartość ta była trochę wyższa, ale wciąż bliska zeru). A teraz najważniejsze – jakie fortuny stracili użytkownicy kryptowalut? Otóż… 5 centów USD w Ethereum oraz równowartość 20 USD w memowej kryptowalucie, której kapitalizacja rynku wynosi zabójcze 588 USD. Musimy przyznać, że to chyba najlepszy kapiszon, jeśli chodzi o ataki tego typu w ostatnim czasie (a w przeliczeniu na “zasięg” wykorzystywanego oprogramowania, to chyba będzie czempion). Pozostaje cieszyć się, że tak szeroko zakrojona kampania skończyła się tak widowiskową klapą. 

Co najważniejsze – cieszy zrozumienie i wyważona reakcja na wpis autora projektu o tym, że dał się zhakować i to przez “niego” doszło do tak szeroko zakrojonego incydentu. Chcielibyśmy zauważyć, że problemem nie jest jeden developer, który pod wpływem zmęczenia i prozy życia codziennego klika w link stosunkowo dobrze przygotowanego phishingu. Podłoże problemu leży w zupełnie innym – bezpieczeństwo managerów paczek takich jak npm czy pypi jest po prostu na memicznym poziomie, a wszystko trzyma się na zasadzie wzajemnego zaufania. 

Dla programistów jest to łagodna lekcja tego, że nie należy lekceważyć inżynierii społecznej jako wektora ataku na ludzi technicznych. Nawet jeśli stosują oni 2FA – w przypadku wykorzystania standardu FIDO2 atak byłby zdecydowanie trudniejszy do przeprowadzenia. Dla zespołu NPM jest to nauczka, aby lepiej przygotować użytkowników na mailing z systemu, zwłaszcza ten dotyczący funkcji bezpieczeństwa. A dla całego środowiska – cenna wiedza, o tym, że należy utrzymywać listę zależności w postaci SBOM (software bill of materials). Ciekawą koncepcją są niezmienne wydania – w której zasoby skojarzone z konkretnym tagiem nie mogą ulec zmianie. A to znaczy, że każda edycja plików źródłowych wymaga utworzenia kolejnego wydania – wtedy znacznie trudniej o przeprowadzenie ataku na łańcuch dostaw.  

Na blogu Security Alliance pojawiła się bogata lista IoC, serdecznie zachęcamy deweloperów do zapoznania się z nią i wykorzystania podlinkowanych skryptów (ten i ten) w celu przeskanowania swoich modułów pod kątem zainfekowanych paczek z tego ataku. Pojawiły się też konfiguracje semgrepa, które można wykorzystać do skanu. 

Black Hat Logan