Is-localhost-ip 2.0.0 podatny na obejście ochrony SSRF przez alternatywne reprezentacje localhost

securitybeztabu.pl 1 dzień temu

Wprowadzenie do problemu / definicja

SSRF, czyli Server-Side Request Forgery, to podatność umożliwiająca wymuszenie na aplikacji serwerowej wykonania żądania do wskazanego przez atakującego zasobu. W praktyce może to prowadzić do dostępu do usług wewnętrznych, odczytu danych dostępnych wyłącznie lokalnie lub rozpoznania topologii sieci. Opisany przypadek związany z pakietem is-localhost-ip 2.0.0 pokazuje, iż uproszczone sprawdzanie, czy host odnosi się do localhost, może zostać ominięte przy użyciu alternatywnych reprezentacji adresu IP.

W skrócie

Analizowany problem dotyczy biblioteki is-localhost-ip w wersji 2.0.0, wykorzystywanej do określania, czy wskazany host jest adresem lokalnym. Udostępniony proof of concept pokazuje, iż aplikacja może blokować bezpośrednie odwołania do localhost, a jednocześnie dopuścić połączenie po użyciu równoważnej reprezentacji IPv6 mapującej adres IPv4 loopback. W efekcie mechanizm ochronny może błędnie uznać adres za bezpieczny i wykonać żądanie do zasobu lokalnego.

Kontekst / historia

Problem został opisany publicznie jako przykład obejścia zabezpieczenia SSRF w środowisku Node.js. Scenariusz testowy opiera się na aplikacji Express udostępniającej endpoint służący do pobierania wskazanego URL po wcześniejszej walidacji hosta. Dodatkowo przygotowano lokalny zasób zwracający przykładowe dane wrażliwe, aby wykazać praktyczną możliwość nieautoryzowanego dostępu.

W przedstawionym materiale bezpośrednie żądanie do lokalnego adresu kończy się blokadą odpowiedzią 403. Jednak zastosowanie alternatywnego zapisu adresu loopback pozwala uzyskać odpowiedź 200, co potwierdza nieskuteczność uproszczonej kontroli. Tego rodzaju problemy są dobrze znane w świecie bezpieczeństwa aplikacji, ponieważ filtry SSRF oparte wyłącznie na porównywaniu ciągów znaków regularnie zawodzą w zetknięciu z niekanonicznymi reprezentacjami adresów.

Analiza techniczna

Istota problemu wynika z różnicy między tym, jak aplikacja interpretuje host dostarczony przez użytkownika, a tym, jak ostatecznie rozpoznaje go parser URL i stos sieciowy. jeżeli kontrola bezpieczeństwa ogranicza się do sprawdzenia, czy host jest równy określonemu łańcuchowi, może nie wykryć innego zapisu tego samego celu sieciowego.

W opisywanym proof of concept serwer analizuje parametr URL, sprawdza hostname, a następnie wykonuje żądanie, jeżeli nie uzna hosta za lokalny. Bezpośrednie użycie localhost lub adresu loopback zostaje zablokowane. Jednak zapis odpowiadający mapowanemu adresowi IPv6 dla 127.0.0.1 może przejść walidację, jeżeli biblioteka lub własna logika aplikacji nie dokonuje pełnej normalizacji i klasyfikacji adresu jako loopback.

To klasyczny przykład canonicalization bypass, czyli obejścia zabezpieczenia poprzez alternatywną reprezentację tej samej wartości. W praktyce podobne błędy mogą obejmować wiele wariantów zapisu i rozwiązywania adresów:

adresy IPv6 mapujące IPv4,
zapis dziesiętny, szesnastkowy lub ósemkowy,
nietypowe warianty skróconych adresów,
nazwy DNS rozwiązujące się do adresów prywatnych lub lokalnych,
przekierowania HTTP prowadzące ostatecznie do zasobu wewnętrznego.

Bezpieczna ochrona przed SSRF nie powinna więc polegać wyłącznie na sprawdzaniu tekstowej postaci hosta. Poprawne podejście obejmuje parsowanie URL, rozwiązywanie DNS po stronie serwera, ocenę wszystkich uzyskanych adresów IP, blokowanie zakresów loopback, private, link-local i reserved oraz kontrolę schematów i portów. Istotne jest również ograniczenie lub ponowna walidacja przekierowań HTTP, ponieważ pierwotnie dozwolony adres może finalnie prowadzić do zasobu wewnętrznego.

Konsekwencje / ryzyko

Skutki skutecznego SSRF zależą od architektury środowiska i poziomu dostępu aplikacji do sieci. W najprostszym wariancie atakujący może uzyskać dostęp do usług wystawionych wyłącznie lokalnie, takich jak panele administracyjne, interfejsy debugowe, lokalne API, endpointy zdrowia usługi czy serwisy pomocnicze nasłuchujące wyłącznie na loopback.

W opisywanym scenariuszu główny wpływ dotyczy możliwości odczytu danych, które miały być dostępne tylko z hosta lokalnego. W rzeczywistych wdrożeniach konsekwencje mogą być szersze:

ujawnienie sekretów aplikacyjnych,
enumeracja usług wewnętrznych,
obejście segmentacji logicznej,
nadużycie zaufania między komponentami,
eskalacja ataku do dalszej kompromitacji podatnych usług backendowych.

Ryzyko rośnie szczególnie wtedy, gdy aplikacja ma szeroki dostęp sieciowy do systemów zarządzania, narzędzi CI/CD, baz danych, usług chmurowych lub wewnętrznych interfejsów administracyjnych.

Rekomendacje

Organizacje korzystające z aplikacji Node.js oraz bibliotek sprawdzających charakter hosta powinny traktować ten przypadek jako wyraźne ostrzeżenie przed stosowaniem uproszczonych filtrów SSRF. Skuteczna ochrona powinna być wielowarstwowa i obejmować zarówno logikę aplikacji, jak i kontrolę sieciową.

Zastąpić walidację opartą na nazwie hosta pełną analizą i normalizacją URL.
Rozwiązywać DNS po stronie serwera i oceniać wszystkie zwrócone adresy IP przed wykonaniem połączenia.
Blokować zakresy loopback, private, link-local, multicast oraz reserved dla IPv4 i IPv6.
Traktować adresy IPv6 mapowane z IPv4 jako równoważne odpowiadającym im adresom IPv4.
Ograniczyć dozwolone schematy do HTTP i HTTPS oraz stosować listę akceptowanych portów.
Wyłączyć automatyczne przekierowania lub ponownie walidować cel po każdym przekierowaniu.
Wdrażać listy dozwolonych domen i hostów tam, gdzie pozwala na to model biznesowy.
Segmentować ruch wychodzący i blokować dostęp do zasobów wewnętrznych oraz metadanych chmurowych na poziomie sieci.
Monitorować logi pod kątem nietypowych reprezentacji adresów, wariantów IPv6 i podejrzanych portów.
Uwzględniać w testach bezpieczeństwa canonicalization bypass, DNS rebinding i redirect chaining.

Podsumowanie

Przypadek is-localhost-ip 2.0.0 pokazuje, iż choćby pozornie prosta kontrola bezpieczeństwa może zostać ominięta przez alternatywny zapis tego samego adresu. W podatnościach SSRF problemem często nie jest sam parser URL, ale błędne założenie, iż pojedyncza tekstowa postać hosta wystarcza do jednoznacznej oceny ryzyka. Dla zespołów bezpieczeństwa i deweloperów najważniejszy wniosek jest prosty: skuteczna ochrona przed SSRF wymaga normalizacji, klasyfikacji adresów po stronie serwera, kontroli DNS oraz egzekwowania polityk sieciowych. Każda implementacja oparta wyłącznie na blokowaniu słowa localhost lub kilku znanych wzorców powinna zostać uznana za niewystarczającą.