Kilka dni temu GitHub ujawnił dwa incydenty w infrastrukturze repozytorium pakietów NPM, w tym szczegółowo, że 2 listopada zewnętrzni analitycy bezpieczeństwa w ramach programu Bug Bounty znaleźli lukę w repozytorium NPM co pozwala opublikować nową wersję dowolnego pakietu, nawet jeśli nie jest autoryzowany do przeprowadzenia takich aktualizacji.
Luka została spowodowana nieprawidłowym sprawdzeniem autoryzacji w kodzie mikroserwisów które przetwarzają żądania do NPM. Usługa autoryzacyjna przeprowadziła kontrolę uprawnień do pakietów na podstawie danych przekazanych w żądaniu, ale inna usługa, która przesyłała aktualizację do repozytorium, określiła pakiet do opublikowania na podstawie zawartości metadanych w przesłanym pakiecie.
W ten sposób atakujący może zażądać publikacji aktualizacji swojego pakietu, do którego ma dostęp, ale wskazać w samym pakiecie informacje o innym pakiecie, który ostatecznie zostanie zaktualizowany.
Od kilku miesięcy zespół npm inwestuje w ulepszenia infrastruktury i bezpieczeństwa, aby zautomatyzować monitorowanie i analizę ostatnio wydanych wersji pakietów w celu identyfikacji złośliwego oprogramowania i innego złośliwego kodu w czasie rzeczywistym.
Istnieją dwie główne kategorie zdarzeń publikowania złośliwego oprogramowania, które występują w ekosystemie npm: złośliwe oprogramowanie publikowane w wyniku przejęcia konta oraz złośliwe oprogramowanie, które atakujący publikuje za pośrednictwem własnych kont. Chociaż przejęcia kont o dużym wpływie są stosunkowo rzadkie, w porównaniu do bezpośredniego złośliwego oprogramowania publikowanego przez osoby atakujące przy użyciu własnych kont, przejęcia kont mogą być daleko idące, gdy są atakowane przez popularnych opiekunów pakietów. Chociaż w ostatnich incydentach nasz czas wykrywania i reakcji na przejęcie popularnych pakietów wynosił zaledwie 10 minut, nadal rozwijamy nasze możliwości wykrywania złośliwego oprogramowania i strategie powiadamiania w kierunku bardziej proaktywnego modelu reagowania.
Problem została naprawiona 6 godzin po zgłoszeniu luki, ale luka była obecna w NPM dłużej niż to, co obejmują dzienniki telemetryczne. GitHub twierdzi, że nie ma śladów ataków z wykorzystaniem tej luki od września 2020, ale nie ma gwarancji, że problem nie został wcześniej wykorzystany.
Drugi incydent miał miejsce 26 października. W trakcie prac technicznych z bazą danych serwisu replikant.npmjs.com, ujawniono, że w bazie danych dostępnej do konsultacji zewnętrznych były poufne dane, ujawniając informacje o nazwach wewnętrznych pakietów, które zostały wymienione w changelogu.
Informacje o tych nazwiskach może służyć do przeprowadzania ataków zależności na projekty wewnętrzne (W lutym taki atak umożliwił uruchomienie kodu na serwerach PayPal, Microsoft, Apple, Netflix, Uber i 30 innych firm).
Ponadto, w związku z rosnącą częstością przejmowania repozytoriów dużych projektów oraz promowanie złośliwego kodu poprzez włamanie na konta programistów, GitHub zdecydował się na wprowadzenie obowiązkowego uwierzytelniania dwuskładnikowego. Zmiana wejdzie w życie w pierwszym kwartale 2022 roku i będzie dotyczyć opiekunów i administratorów pakietów znajdujących się na liście najpopularniejszych. Dodatkowo informuje o modernizacji infrastruktury, która wprowadzi automatyczne monitorowanie i analizę nowych wersji pakietów w celu wczesnego wykrywania złośliwych zmian.
Przypomnijmy, że według badania przeprowadzonego w 2020 r. tylko 9.27% menedżerów pakietów korzysta z uwierzytelniania dwuskładnikowego w celu ochrony dostępu, a w 13.37% przypadków podczas rejestracji nowych kont programiści próbowali ponownie wykorzystać złamane hasła, które pojawiają się w znanych hasłach .
Podczas sprawdzania siły użytych haseł dostęp do 12% kont w NPM (13% pakietów) uzyskano dzięki użyciu przewidywalnych i trywialnych haseł, takich jak „123456”. Wśród problemów znalazły się 4 konta użytkowników z 20 najpopularniejszych pakietów, 13 kont, których pakiety były pobierane ponad 50 milionów razy w miesiącu, 40 - ponad 10 milionów pobrań miesięcznie i 282 z ponad 1 milionem pobrań miesięcznie. Biorąc pod uwagę obciążenie modułów w łańcuchu zależności, naruszenie niezaufanych kont może wpłynąć na łącznie do 52% wszystkich modułów w NPM.
Wreszcie, jeśli chcesz dowiedzieć się więcej na ten temat możesz sprawdzić szczegóły W poniższym linku.