Cześć, dzisiaj chcę poruszyć temat odnośnie techniki zwanej typosquatting, czyli można tak nazwać sposób ataku opierający się na możliwości pomyłki podczas wpisywaniu tesktu z klawiatury i może to być na przykłaad część komendy czyli nazwa paczki NPM czy Pip. Nie mylić z cybersquatting, czyli szkoliwej możliwości wykupienia nie przedłużonej domeny na czas znanej firmy, instytucji itp.
Typosquatting a Cybersquatting
No właśnie, więc też czy ten pierwszy atak może być związany z domenami? Jak najbardziej, historia pisze różne scenariusze a jednym z nich jest przypadek google'a kiedy nie zarezerwował zbliżonych domen w granicach ludzkiego błędu wpisywania adresu URL własnoręcznie. Mowa tu choćby o g o g g le . c o m ale i y o t u b e . c o m i nie bez przypadku odzieliłem spacjami te nazwy, gdyż wejście na te strony może być bardziej niebezpiecznie i to nawet w przypadku VM.
Możliwość pobrania nieodpowiedniej paczki przez pomyłkę
Błędy chodzą po ludziach a czasem wpisanie nieprawidłowego wyrazu może na przykład: doprowadzić do wycieku wrażliwych danych firm(y), zainfekować maszynę lub chociaż spowodować awarię. Jednak każda z tych rzeczy przyczyni się do sporych strat firmy. Dobrą praktyką jest kopiowanie komendy do instalacji z oficjalnej strony np: npm autora pakietu lub zastosowanie kilku narzędz, które mogą nam pomóc już po wykonaniu komendy. Tu chociażby przykładem jest: NPQ , które oczywiście nie daje pewnych szans na uniknięcie zagrożenia natomiast w pewnym stopniu może pomóc, jednak najlepiej wdrożyć w swojej firmie lub ekosystemie pracy prywatny menadżer paczek, który będzie miał scachowane wersje stabilnych i przeskanowanych paczek przez np: snyka. Na ostudzenie powiem też, że czasem niektóre paczki zostają jako tak zwane security-placeholder. Jeśli zainstalowałeś paczkę o podobnej nazwie co oficjalna i wejdziesz na stronę np: npm'a i zobaczysz odpowiedni opis lub/i nawet ostrzeżenie w konsoli to znaczy że tym razem miałeś szczęście.
Ale co jak oficjalna paczka nadal może nieść zagrożenie?
Jak wiadomo paczki typu open source mogą być z różnego źródła i także nie każdej można ufać, gdyż może mieć ukryte celowe bądź nieświadome zmaiary w zależności od tego czy ktoś faktycznie zaktualizował paczkę z dobrym zamiarem. Tutaj przydatne może być wykorzystanie wszelkiego rodzajów skanerów jak snyk, sonar. Należy zadbać także o sprawdzenie hash'a skryptu jak w przypadku choćby composer'a podczas instalacji o ile producent go podał, można wtedy zweryfikować czy paczka nie została zamieniona w trakcie publikacji. Możesz jeszcze:
- Użyć --ignore-scripts w npm czy czegoś pododbnego w innym narzędziu cli do pobierania paczek, ta opacja zapewni że żadne skrypty podczas instalacji nie zostaną odpalane a co za tym idzie będziemy mieli większą kontrolę podczas instalacji bo czasem twócy dołączają skrypty by ułatwić generaowanie assetów czy innych rzeczy, natomiast to nie jest takie częste i lepiej zrobić to manualnie lub zweryfikować skrypt przed odpaleniem.
- Zawsze wylogowywuj się z menadżera paczek, z którego obecnie korzystasz choćby poprzez komendę: npm logout lub inną zależnie od twojego klienta do menadżera paczek. To zapewni Ci, że atakujący po przejęciu kontroli w jakimś stopniu nie będzie publikował podmienionych paczek.
- Jeśli w twoim repo jest biblioteka, staraj się używać npm shrinkwrap .
- Opcjonalną metodą może być także cachowanie paczek w repo, o ile twój menadżer paczek na to pozwala.
- Staraj się odpalać komendę instalacji z możliwością zachowania logów np do audytu, może to być choćby parametr: –loglevel , który zapewni ci najwięcej informacji, jakie połączenia do zewnętrznych sererów były ustanawiane podczas instalacji.
- Jest wiele baz danych publicznych, gdzie można sprawdzić jakie paczki zostały zanotowane jakie niebezpieczne m.in checkmarx lub snyk db, także autorzy tych wspaniałych wymienionych narzędzi piszą czasem interesujące raporty i organizują fajne konferencje.
- Możesz także skanować paczki w swoim środowisku wieloma narzędziami na raz i zbierać dane na ich temat za pomocą różnych platform m.in: Infobyte/Faraday .
- Oczywiście niektóre narzędzia, możesz wpiąć do pipeline CI/CD co gorąco polecam i nawet czasem warto posłuchać prostej komendy npm audit by uodpornić naszą apkę na potencjalne podatności.
Dobra a jak już wspomniałeś o tym cybersquattingu i typesquattingu, da się coś jeszcze zrobić?
Pewnie, jeszcze możesz podiąć kilka kroków, jedna rzecz może zabezpieczyć cię przed wejściem w podobną domenę do twojej firmy i jednocześnie możesz kupić podobne domeny aby nie narazić użytkowników. Aby tego dokonać możesz użyć tak zwany DNS Buzzer do wygegenrowania podobnych domen przy użyciu permutacji czy choćby bardziej konkretnie tego narzędzia: Dnstwist . Także jest interesujące narzędzie, które pozwoli nam sprawdzić czy biblioteki odwiedzane przez nas na stronach mogą być niebezpieczne. Mowa tu o retire.js .
Mam nadzieję że zaciekawiłem i temat security nie musi być nudny. Pewnie jeszcze postaram się napisać coś w tej tematyce. Dzięki za uwagę i miłego dzionka :) .