Pakiet NPM węzła-sieci, który ma około 3 miliony pobrań tygodniowo i jest używany jako zależność w ponad 270 tysiącach projektów na GitHubie, ma lukę (CVE-2021-28918), która pozwala mu ominąć kontrole wykorzystujące maskę sieci w celu określenia wystąpienia w celu adresowania zakresów lub w celu filtrowania. Problem został rozwiązany w wersji Node-Netmask 2.0.0.
Podatność umożliwia traktowanie zewnętrznego adresu IP jako adresu z sieci wewnętrznej i odwrotnie oraz przy pewnej logice wykorzystania modułu maski sieciowej w aplikacji do realizacji SSRF (ang. Server-side request forgery), RFI (ataki Remote File Inclusion) i LFI (Local File Inclusion) w celu uzyskania dostępu do zasobów w sieci wewnętrznej i włączenia plików zewnętrznych lub lokalnych do łańcucha wykonawczego. Problem w tym, że zgodnie ze specyfikacją wartości ciągów adresowych rozpoczynające się od zera należy interpretować jako liczby ósemkowe, natomiast moduł node-netmask nie bierze tego pod uwagę i traktuje je jako liczby dziesiętne.
Na przykład osoba atakująca może zażądać zasobu lokalnego, podając wartość „0177.0.0.1”, która odpowiada „127.0.0.1”, ale moduł „maska-węzła” odrzuci wartość null i potraktuje 0177.0.0.1″ jako „ 177.0.0.1”, który w aplikacji przy ocenie reguł dostępu nie będzie możliwy do określenia tożsamości z „127.0.0.1”. Podobnie atakujący może podać adres „0127.0.0.1”, który powinien być identyczny z „87.0.0.1”, ale będzie traktowany jako „127.0.0.1” w module „node-netmask”. Podobnie możesz oszukać sprawdzanie dostępu do adresów intranetowych, podając wartości takie jak „012.0.0.1” (odpowiednik „10.0.0.1”, ale podczas sprawdzania będzie przetwarzany jako 12.0.0.1).
Badacze, którzy zidentyfikowali problem, nazywają go katastrofalnym i podają kilka scenariuszy ataków, ale większość z nich ma charakter spekulacyjny. Na przykład mówi o możliwości zaatakowania aplikacji opartej na Node.js, która ustanawia połączenia zewnętrzne w celu zażądania zasobu w oparciu o parametry lub dane żądania wejściowego, ale aplikacja nie jest konkretnie nazwana ani szczegółowa. Nawet jeśli znajdziesz aplikacje, które ładują zasoby na podstawie wprowadzonych adresów IP, nie jest do końca jasne, w jaki sposób lukę można wykorzystać w praktyce bez łączenia się z siecią lokalną lub bez przejmowania kontroli nad „lustrzanymi” adresami IP.
Badacze zakładają jedynie, że właściciele adresów 87.0.0.1 (Telecom Italia) i 0177.0.0.1 (Brasil Telecom) są w stanie ominąć ograniczenie dostępu do 127.0.0.1. Bardziej realistyczny scenariusz polega na wykorzystaniu luki w celu ominięcia różnych list blokowania po stronie aplikacji. Zagadnienie to można również zastosować do udostępnienia definicji zakresów intranetowych w module NPM „private-ip”.
Źródło: opennet.ru