Błąd jednego znaku powodujący rozprzestrzenianie się złośliwego oprogramowania
Wszystko zaczęło się od literówki. Gdzieś w natłoku publikacji nowych funkcji i łączenia PR-ów ktoś wpisał @utils_core zamiast @utils-core do pakiet.json. Ten pojedynczy znak nie spowodował błędu. Zamiast tego, po cichu wciągnął złośliwy pakiet wyglądający jak następny CI/CD uruchom, wykorzystując zaufanie do przypiętych wersji i automatyzację. Witamy w świecie typosquattingu w środowisku open source.
Typosquatting: wektor ataku wykorzystujący błędy ludzkie
Typosquatting to dokładnie to, na co wygląda: złośliwi użytkownicy rejestrują pakiety o nazwach niemal identycznych z legalnymi. W dynamicznych środowiskach działa to, ponieważ programiści ufają, że ich pakiet.json oraz pakiet-lock.json odzwierciedlać to, czego oczekują. Jedna postać? To równie dobrze mogłoby pozostać niewidoczne w przypadku różnicy w PR.
NPM ma historię wykorzystywania poprzez typosquatting. Pakiety takie jak crossenv zamiast międzyśrodowiskowe or strumień zdarzeń Tylne furtki już pokazały, jak skuteczne mogą być takie podróbki. Te fałszywe pakiety często przechodzą testy po prostu dlatego, że wyglądają dobrze i nie generują natychmiastowych błędów w czasie wykonywania.
Do typowych pułapek zalicza się:
- Myślnik kontra podkreślenie: lodash-core vs lodash_core
- Liczba mnoga: zażądać vs wywołań
- Zamienione znaki: ekspres zamiast ekspresowy
Gdzie package-lock.json staje się ślepą plamą
Deweloper poprawia literówkę. A przynajmniej tak mu się wydaje. Ale teraz… pakiet-lock.json już zablokował pakiet atakującego. I tu właśnie kryje się prawdziwe ryzyko.
w odróżnieniu pakiet.json, który jest edytowany ręcznie i poddawany większej kontroli, pakiet-lock.json jest generowany automatycznie przez NPMW rezultacie często traktuje się to jak formalność, pomija lub pomija jedynie pobieżnie. pull request recenzje. Nierzadko zdarza się, że zespoły oceniają je jako „zbyt głośne” lub ufają im bezkrytycznie, bez głębszej analizy.
Atakujący o tym wiedzą. Polegają na tym. Kiedyś złośliwy pakiet jest cytowany, dzięki literówce w pakiet.json, pakiet-lock.json Rejestruje poprawioną wersję. Nawet jeśli literówka zostanie później poprawiona, złośliwy wpis może pozostać, chyba że plik blokady zostanie celowo ponownie wygenerowany.
Co gorsza, przypinanie wersji, które ma zapewniać spójność, może przynieść odwrotny skutek. Atakujący mogą wersjonować swój fałszywy pakiet identycznie jak legalny. Jeśli CI/CD system ślepo ufa przypiętym wersjom, nie wykryje, że instaluje pakiet o znanym, dobrym numerze wersji, ale pochodzący z innego, złośliwego źródła.
Ta cicha wytrwałość jest tym, co sprawia, że pakiet-lock.json To takie niebezpieczne. Gwarantuje deterministyczne kompilacje, owszem, ale gwarantuje również, że zły pakiet pozostanie, dopóki nie zostanie wykryty i ręcznie usunięty.
CI/CD:Gdzie atakuje złośliwe oprogramowanie – package.json
W typowy CI/CD pipelineSzkodliwy pakiet nie musi czekać do uruchomienia. Jest rozwiązywany i aktywowany znacznie wcześniej w procesie:
Rozwiązanie zależności
pipeline pobiera dokładne wersje zależności z package-lock.json, który obecnie obejmuje typosquatted pakiet z powodu literówki w pakiet.json.
Faza instalacji
Podczas npm ci instalowane są wszystkie zależności, łącznie z tą szkodliwą. Bez ostrzeżeń, bez monitów, po prostu cicha instalacja.
Wykonanie skryptu po instalacji
Pakiet sobowtóra zawiera skrypt poinstalacyjny, który uruchamia się automatycznie po zakończeniu instalacji. To właśnie tutaj dochodzi do naruszenia bezpieczeństwa.
Przykład pseudokodu:
if (installation_phase_active) {
runHiddenPayload()
}
Opis pseudokodu:
Podczas fazy instalacji, jeśli hak cyklu życia po instalacji jest obecny, fałszywy pakiet uruchamia swoją ukrytą logikę – często jeszcze przed uruchomieniem kompilacji lub testów. Może to obejmować wysyłanie żądań zewnętrznych, wstrzykiwanie luk w zabezpieczeniach lub inne nieautoryzowane działania.
⚠️ Ostrzeżenie: Ten pseudokod jest przeznaczony wyłącznie do celów demonstracyjnych i nie należy go używać w rzeczywistych środowiskach.
Nie uruchamiają się żadne alerty. Nic nie zawodzi. Środowisko jest już zagrożone, zanim… pipeline nawet dociera do etapu testowania.
Dostrzeganie różnic, zanim będzie za późno
Częsty błąd: zakładanie pakiet.json opowiada całą historię. Nie opowiada. Prawdziwa siła tkwi w połączeniu package.json + package-lock.json.
Oto, czego szukać:
- Czy pakiet-lock.json zawierać nieoczekiwane pakiety?
- Czy jakiekolwiek zależności pochodzą z nieznanych rejestrów lub mają dziwne zakresy?
- Czy numery wersji są zbyt szczegółowe lub niezgodne?
Użyj narzędzi CLI takich jak:
- audyt np aby oznaczyć znane problemy
- npm ls aby wyświetlić pełne drzewo zależności
- diff aby porównać wersje między pakiet.json oraz pakiet-lock.json
Utwardź swoje Pipeline:Obrony, które działają
Aby bronić się przed typosquattingiem:
- Wyegzekwuj ograniczenia zakresu w pakiet.json.
- Dodaj wstępne scalenie hooks do sprawdzania i walidacji zależności.
- Zastosowanie npm ci aby uniknąć niezamierzonego odchylenia wersji.
- Regularnie skanuj pakiet-lock.json w przypadku anomalii.
I co najważniejsze: traktuj niezweryfikowane wpisy w pakiet-lock.json jako potencjalne ryzyko. Każdy commit należy traktować jako punkt kontrolny łańcucha dostaw.
Automatyczne wykrywanie: jak pomagają narzędzia takie jak Xygeni
Choć nie jest to cudowne rozwiązanie, zautomatyzowane narzędzia, takie jak Xygeni odgrywają kluczową rolę w ograniczaniu czynnika błędu ludzkiego, który jest przyczyną typosquattingu. Xygeni integruje się bezpośrednio z Twoim procesem DevOps, dodając warstwę ochrony w czasie rzeczywistym przed przejęciem zależności, zanim jeszcze program zostanie uruchomiony.
Oto w jaki sposób pomaga Xygeni:
- Wykrywanie podejrzanych nazw pakietów:
Wykorzystuje inteligentną heurystykę do wykrywania wzorców typosquattingu w pakiet.json, szukając drobnych zmian w powszechnie znanych nazwach pakietów (takich jak dodane podkreślenia, transpozycje lub zamiany liter). - Weryfikacja nieznanego skrótu:
Porównuje skrót każdej zależności w pakiet-lock.json z bazą danych znanych, dobrych artefaktów z zaufanych rejestrów. Nawet jeśli nazwa i wersja pakietu wyglądają poprawnie, niezgodność hasza jest sygnałem ostrzegawczym. - Blokowanie przed kompilacją:
Przechwytuje i blokuje instalację wszelkich niezweryfikowanych lub podejrzanych pakietów przed dotarciem do fazy instalacji lub fazy poinstalacyjnej. CI/CD pipeline. - Analiza wykresu zależności:
Ciągle sprawdza całe drzewo zależności pod kątem prób pośredniego typosquattingu lub złośliwych zależności przechodnich. - Alerty i raportowanie:
Zapewnia szczegółowe, możliwe do podjęcia działania alerty, pokazujące, co zostało oznaczone, dlaczego i skąd pochodzi w łańcuchu zależności.
W miarę jak ekosystemy pakietów stają się coraz bardziej złożone, narzędzia takie jak Xygeni stają się niezbędne. Ręczny przegląd nie skaluje się wraz z rozrostem zależności ani szybką iteracją. Xygeni wkracza do akcji, aby zautomatyzować krytyczne kontrole, które są obecnie dostępne. pipelinepotrzeba, niwelując lukę między zaufaniem i weryfikacją.
Jedna postać. Prawdziwe konsekwencje.
To nie było coś egzotycznego zero-dzieńTo była literówka. Jeden źle postawiony znak w pakiet.json, po cichu wzmocnione przez pakiet-lock.jsoni złośliwe oprogramowanie zostało automatycznie wysłane podczas rutynowej czynności CI/CD uruchomić.
To właśnie jest prawdziwe zagrożenie związane z typosquattingiem: nie wymaga on złożoności. Wykorzystuje szybkość, zaufanie i automatyzację. Tego kompromisu można było uniknąć, wprowadzając odpowiednie środki kontroli:
- Automatyczne skanowanie aby wykryć podejrzane nazwy i wersje pakietów przed instalacją.
- Audyt plików blokady do wykrywania nieprzejrzanych lub nieoczekiwanych wpisów pakiet-lock.json.
- Heurystyka weryfikacji nazwy aby oznaczyć pakiety niemalże zgodne z zaufanymi.
Wystarczył jeden znak. Odpowiednie kontrole zatrzymałyby go, zanim dotknąłby twojego pipelineZaufanie to za mało. W nowoczesnym DevSecOps albo weryfikujesz wszystko, albo ryzykujesz wszystko.
