W ostatnim czasie Group-IB opublikował bardzo ciekawy wpis o tym, jak atakujący wykorzystali phishing, żeby doprowadzić do kompromitacji ekosystemu npm. To nie był klasyczny bug – to atak łańcucha dostaw, który zaczął się od skrzynki mailowej.
Co dokładnie się stało
- Atak zaczął się od wiadomości phishingowej. Atakujący posłużyli się domeną
npmjs.help, która wygląda bardzo podobnie do prawdziwej strony npm, co pomogło w oszustwie. - Dzięki temu przejęli konto dewelopera npm. To kluczowy moment, mając kontrolę nad kontem, można publikować nowe wersje paczek.
- Następnie opublikowano zainfekowane wersje popularnych paczek npm. To nie były niszowe biblioteki, mówimy o kodzie, z którego korzystają tysiące projektów.
To klasyczny scenariusz supply-chain: nie atakujesz firmę bezpośrednio, tylko uderzasz tam, gdzie ufa się najbardziej a więc do serwera pakietów, który służy deweloperom.
Jak Group-IB to wykrył
Tutaj robi się naprawdę interesująco, bo Group-IB twierdzi, że ich system Business Email Protection (BEP) mógł wykryć atak na samym starcie.
Mechanizmy, które mogą zaalarmować system BEP, to m.in.:
- Inteligencja domenowa: BEP analizuje dane WHOIS / RDAP domen i mógł wykryć
npmjs.helpjako potencjalnie podejrzaną, bo nowo zarejestrowaną. - Analiza podszywania się pod markę: system ocenia, czy nadawca próbuje naśladować oficjalne domeny npm.
- Treść wiadomości: BEP ma modele, które rozpoznają “język phishingowy” – m.in. komunikaty o aktualizacji 2FA, które są typowe w phishingu.
- Analiza linków i URL-i: system bada, do jakich stron linkują maile, czy strony te są autentyczne, czy podszyte, oraz czy linki prowadzą do stron wyłudzających dane.
- Zachowanie strony docelowej: BEP uruchamia renderowanie strony i sprawdza, czy interfejs przypomina tę prawdziwą stronę npm, czy raczej są to elementy podszywające.
Dzięki tym warstwom BEP mógłby odrzucić phishing już zanim dotarł do konta dewelopera.
Dlaczego to jest poważne
Kilka rzeczy, które mnie uderzyły, gdy czytałem analizę:
- Zaufanie do open-source
Korzystamy z bibliotek npm niemal bezkrytycznie. Deweloperzy ufają, że paczki są “czyste”. Ten atak pokazuje, że zaufanie może zostać wykorzystane jeśli konto zostanie przejęte. - Łańcuch dostaw to nie tylko hardware
Mówi się często o atakach na fizyczny łańcuch dostaw, ale tutaj widzimy, że software’owy łańcuch (czyli zależności w kodzie) jest równie podatny. - Phishing nadal działa
To nie był techniczny exploit w npm, tylko klasyczny phishing. Czasami najprostsze metody okazują się najbardziej skuteczne. - Detekcja musi być wielowarstwowa
Group-IB pokazuje, że samo sprawdzanie reputacji domen czy filtrowanie spamu to za mało. Potrzebna jest analiza zachowania, podszywania pod markę i złożona korelacja sygnałów.
Co można zrobić
Na podstawie tego ataku można wyciągnąć kilka lekcji:
- Warto rozważyć wdrożenie systemów ochrony poczty (jak BEP) ze zdolnością do wykrywania phishingu na zaawansowanym poziomie.
- Warto używać silnego uwierzytelniania (2FA, klucze sprzętowe FIDO).
- Rozważenie mechanizmów bezpieczeństwa typu SBOM (Software Bill of Materials) czyli inwentaryzacja zależności projektu, może to pomóc szybciej reagować, gdy pojawią się alerty o zainfekowanych wersjach.
Wnioski
Nie ma jednej łatwej recepty na zabezpieczenie łańcucha dostaw, ale zaufanie samo w sobie to nie zabezpieczenie. Trzeba zakładać, że coś może pójść źle i mieć narzędzia, które są w stanie wykryć atak zanim spowoduje on szkody.
To nie tylko kwestia techniczna ale problem ludzki. Jeśli ktoś kliknie phishingowy mail, to reszta ataku może iść jak po maśle. Dlatego edukacja pracowników i wdrożenie ochrony poczty może zrobić realną różnicę.
Źródło: https://www.group-ib.com/blog/detect-npm-supply-chain-attack/
