W paczce NPM node-netmask, która ma około 3 miliony pobrań tygodniowo i jest używana jako zależność w ponad 270 tysiącach projektów na GitHubie, wykryto lukę (CVE-2021-28918), umożliwiającą ominięcie weryfikacji, w których maska sieciowa jest używana do określenia należności do zakresów adresów lub do filtrowania. Problem został rozwiązany w wydaniu node-netmask 2.0.0.
Wrażliwość pozwala na traktowanie zewnętrznego adresu IP jako adresu wewnętrznej sieci i odwrotnie, a przy pewnej logice używania modułu node-netmask w aplikacji można przeprowadzić ataki SSRF (Server-side request forgery), RFI (Remote File Inclusion) oraz LFI (Local File Inclusion) w celu uzyskania dostępu do zasobów wewnętrznej sieci oraz włączenia zewnętrznych lub lokalnych plików do łańcucha wykonania. Problem polega na tym, że zgodnie z specyfikacją wartości adresów, które zaczynają się od zera, powinny być interpretowane jako liczby ósemkowe, ale moduł „node-netmask” nie uwzględnia tej szczególności i przetwarza je jako liczby dziesiętne.
Na przykład, atakujący może zażądać lokalnego zasobu, podając wartość „0177.0.0.1”, która odpowiada „127.0.0.1”, ale moduł „node-netmask” odrzuci zero i przetworzy 0177.0.0.1″ jako „177.0.0.1”, co w aplikacji, przy ocenie zasad dostępu, nie pozwoli określić tożsamości z „127.0.0.1”. Podobnie atakujący może podać adres „0127.0.0.1”, który powinien być równy „87.0.0.1”, ale w module „node-netmask” zostanie przetworzony jako „127.0.0.1”. Można również oszukać weryfikację dostępu do adresów intranetowych, podając wartości podobne do „012.0.0.1” (równoważnik „10.0.0.1”, ale przy weryfikacji będzie przetworzony jako 12.0.0.1).
Badacze, którzy wykryli problem, nazywają go katastrofalnym i przedstawiają kilka scenariuszy ataków, ale większość z nich wydaje się być tylko teoretyczna. Na przykład mówi się o możliwości atakowania aplikacji opartej na Node.js, która nawiązuje zewnętrzne połączenia w celu żądania zasobu na podstawie parametrów lub danych wejściowych, ale konkretna aplikacja nie jest wymieniana ani szczegółowo opisywana. Nawet jeśli uda się znaleźć aplikacje, które pobierają zasoby na podstawie wprowadzonych adresów IP, nie do końca jasne jest, jak można zastosować tę lukę w praktyce bez podłączenia do lokalnej sieci lub bez uzyskania kontroli nad „lustrzanymi” adresami IP.
Badacze jedynie przypuszczają, że właściciele 87.0.0.1 (Telecom Italia) i 0177.0.0.1 (Brasil Telecom) mają możliwość obejścia ograniczenia dostępu do 127.0.0.1. Bardziej realistycznym scenariuszem jest wykorzystanie luki do obejścia różnych list blokad wdrożonych po stronie aplikacji. Problem może być również wykorzystywany do wymiany definicji zakresów intranetowych w module NPM „private-ip”.
Źródło: opennet.ru
