DNS rebinding: jak strona WWW atakuje Twoją sieć lokalną

Wiele osób zakłada, że urządzenie „schowane” w sieci lokalnej — router, kamera IP, drukarka, panel administracyjny bez wystawienia na internet — jest bezpieczne, bo „nikt z zewnątrz do niego nie sięgnie”. DNS rebinding obala to założenie: pozwala złośliwej stronie WWW, otwartej w przeglądarce ofiary, wysyłać żądania do urządzeń w jej sieci lokalnej i odczytywać odpowiedzi. To atak stary jak sama sieć, a wciąż zaskakująco skuteczny, bo obchodzi jedno z fundamentalnych zabezpieczeń przeglądarki.

Fundament: polityka tego samego pochodzenia

Przeglądarki chroni polityka tego samego pochodzenia (same-origin policy, SOP). W skrócie: skrypt z https://atakujacy.example może wysłać żądanie do http://192.168.1.1, ale nie odczyta odpowiedzi, bo to inne pochodzenie (inny host). Dzięki temu strona w internecie nie może po prostu „przeczytać” Twojego routera.

Kluczowe jest jednak to, że pochodzenie definiuje się przez nazwę hosta, nie przez adres IP. I właśnie tę lukę wykorzystuje DNS rebinding.

Mechanizm ataku krok po kroku

Atakujący kontroluje domenę, powiedzmy atak.example, i jej serwer DNS. Kluczowo — ustawia dla niej bardzo krótki TTL (czas ważności odpowiedzi DNS, np. kilka sekund).

1. Ofiara wchodzi na atak.example (link z phishingu, reklama, cokolwiek). DNS zwraca prawdziwy adres serwera atakującego. Przeglądarka ładuje złośliwy skrypt JavaScript.
2. Skrypt zaczyna odpytywać atak.example w pętli. Dla przeglądarki to wciąż to samo pochodzenie — ta sama nazwa hosta.
3. Atakujący „przełącza” (rebind) DNS. Ponieważ TTL był krótki, przeglądarka wkrótce ponownie pyta o adres atak.example — a tym razem serwer DNS atakującego zwraca adres z sieci lokalnej ofiary, np. 192.168.1.1 (router) albo 127.0.0.1 (usługa na localhoście).
4. Skrypt trafia do urządzenia w LAN — i może czytać odpowiedzi. Z punktu widzenia przeglądarki to nadal atak.example (ta sama nazwa!), więc SOP nie blokuje odczytu. Skrypt komunikuje się z lokalnym urządzeniem tak, jakby był jego własną stroną.

Efekt: strona z internetu rozmawia z Twoim routerem, kamerą, panelem admina czy usługą deweloperską na localhoście — i odsyła zdobyte dane atakującemu. Cele bywają poważne: zmiana ustawień routera, kradzież danych z niezabezpieczonego API, a w chmurze — sięgnięcie po endpoint metadanych instancji (źródło poświadczeń).

Dlaczego to wciąż działa

DNS rebinding trwa w najlepsze, bo opiera się na trzech powszechnych błędnych założeniach:

• „Skoro to tylko w LAN, nie trzeba uwierzytelniania.” Mnóstwo urządzeń i paneli administracyjnych w sieci lokalnej nie wymaga logowania albo ma domyślne hasła. DNS rebinding zamienia „dostępne tylko lokalnie” w „dostępne dla dowolnej strony, którą otworzysz”.
• „Nie sprawdzamy nagłówka Host.” Wiele lokalnych usług odpowiada na żądanie niezależnie od tego, jaką nazwę hosta w nim podano — więc akceptuje atak.example wskazujące na ich IP.
• „To zbyt egzotyczne.” A jest to gotowa, zautomatyzowana technika, którą trywialnie wpleść w złośliwą stronę.

Obrona: warstwa sieci i warstwa usługi

Skuteczna ochrona łączy dwa poziomy — bo żaden sam nie wystarcza.

Po stronie sieci / resolvera (blokuj rebinding):

• Ochrona przed DNS rebinding w resolverze. Wiele resolverów (np. dnsmasq z opcją stop-dns-rebind, Pi-hole, resolvery routerów) potrafi odrzucać odpowiedzi DNS z publicznych domen wskazujące na adresy prywatne (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) oraz na pętlę zwrotną. To odbiera atakowi kluczowy krok — „przełączenie” na adres lokalny.

Po stronie usługi (nie ufaj, że jesteś tylko w LAN):

• Weryfikuj nagłówek Host. Lokalna usługa powinna odpowiadać tylko na oczekiwane nazwy (localhost, jej właściwy adres), a odrzucać żądania z obcym Host — to prosta, skuteczna bariera.
• Wymagaj uwierzytelniania i tokenów. Nawet „wewnętrzny” panel musi wymagać logowania; brak uwierzytelniania to główny powód, dla którego rebinding jest opłacalny. Zgodne z podejściem Zero Trust: sieć lokalna nie jest granicą zaufania.
• Wiąż usługi z pętlą zwrotną, gdy to możliwe, i używaj HTTPS z walidacją certyfikatu — niepasujący certyfikat utrudnia atak.
• Wykorzystaj mechanizmy przeglądarki. Nowoczesne przeglądarki wdrażają Private Network Access (dawniej CORS-RFC1918): żądania z publicznej strony do sieci prywatnej wymagają dodatkowej zgody. To ważna warstwa, ale nie zastępuje zabezpieczenia usług.

Uwaga dla twórców aplikacji: brak walidacji Host i „ufanie sieci lokalnej” to ta sama rodzina błędów co błędna kontrola dostępu w OWASP Top 10 i luźne CORS opisane w przewodniku po nagłówkach.

Podsumowanie

DNS rebinding pokazuje, że „dostępne tylko w sieci lokalnej” nie znaczy „bezpieczne”. Atak obchodzi politykę tego samego pochodzenia, podmieniając adres pod tą samą nazwą hosta, i zamienia dowolną otwartą stronę w przyczółek do Twojego routera, urządzeń IoT i usług wewnętrznych. Obrona wymaga dwóch warstw: blokowania rebindingu na resolverze (odrzucanie prywatnych IP w odpowiedziach publicznych domen) oraz twardego zabezpieczenia samych usług (walidacja Host, uwierzytelnianie, brak zaufania do „bycia w LAN”).

Jeśli budujecie urządzenia, panele administracyjne albo usługi wewnętrzne i chcecie sprawdzić ich odporność na DNS rebinding i pokrewne ataki, odezwijcie się — testy bezpieczeństwa aplikacji i infrastruktury obejmują ten scenariusz.

Najczęstsze pytania (FAQ)

Czy HTTPS chroni przed DNS rebinding? Częściowo. Jeśli lokalna usługa wymaga poprawnego certyfikatu HTTPS dla swojej nazwy, atak jest trudniejszy, bo certyfikat nie będzie pasował do atak.example. Jednak wiele urządzeń w LAN działa po HTTP lub z certyfikatem samopodpisanym, więc HTTPS z walidacją to jedna z warstw, a nie kompletne rozwiązanie.

Czy zwykły firewall zatrzyma ten atak? Nie. Żądania wychodzą z przeglądarki ofiary, która jest wewnątrz sieci, więc firewall na brzegu widzi normalny ruch lokalny. Dlatego obrona musi działać na resolverze DNS i na samych usługach, a nie na zaporze brzegowej.

Jestem w chmurze — czy mnie to dotyczy? Tak, i bywa szczególnie groźne. DNS rebinding może posłużyć do sięgnięcia po endpoint metadanych instancji (np. 169.254.169.254), który bywa źródłem tymczasowych poświadczeń. Dlatego blokowanie dostępu do metadanych i wymuszanie ich nowszych, zabezpieczonych wersji to ważny element hardeningu chmury.

Jak sprawdzić, czy moje urządzenia są podatne? Najprościej przez test: czy usługa odpowiada na żądania z obcym nagłówkiem Host, czy wymaga uwierzytelniania i czy resolver w sieci blokuje prywatne adresy w odpowiedziach publicznych domen. Taki scenariusz uwzględniamy w testach bezpieczeństwa urządzeń i aplikacji wewnętrznych.