Atak DNS spoofing polega na złośliwej podmianie adresów IP w pamięci podręcznej serwera nazw, co wymusza przekierowanie ruchu ofiary na fałszywe strony internetowe kontrolowane przez przestępców. Aby się przed nim chronić, należy bezwzględnie wdrożyć protokół DNSSEC, korzystać z szyfrowanych kanałów VPN oraz regularnie czyścić lokalny cache DNS na urządzeniach końcowych.
To jest brutalna prawda o architekturze internetu. System wymyślony dekady temu po prostu nie zakładał, że ktoś będzie masowo kłamać w odpowiedziach na zapytania UDP. A hakerzy kłamią. Więc musimy łatać ten dziurawy okręt własnymi siłami u siebie na serwerach.
Co to jest atak DNS spoofing i dlaczego oszukuje twoją przeglądarkę?
Wpisujesz w pasek przeglądarki adres swojego banku. Przeglądarka nie ma pojęcia, gdzie fizycznie w sieci leży ten serwer. Potrzebuje numeru. Adresu IP. Pyta więc lokalny serwer nazw o drogę. I tu wchodzi atakujący. Podrzuca fałszywą odpowiedź ułamki sekund przed tym, zanim zrobi to prawdziwy serwer bazowy. Twój komputer zapisuje to kłamstwo w pamięci podręcznej.
Od tego momentu masz problem.
Przeglądarka ładuje stronę, która wygląda identycznie jak twój bank. Ty wpisujesz hasło. Atakujący je przejmuje. Zjawisko to nazywamy zatruwaniem pamięci podręcznej DNS. Działa tak dobrze, bo protokół przesyłania pakietów w swojej pierwotnej formie nie posiada mechanizmów uwierzytelniania nadawcy. Serwer pyta, ktoś odpowiada, serwer wierzy na słowo. Zmieniliśmy te zasady na robocie u nas w firmie dopiero po bolesnej wpadce, ale o tym za chwilę. Zwykły użytkownik jest całkowicie ślepy na ten proces z poziomu interfejsu graficznego. Nie widzi podmiany.
Jak dokładnie przebiega zatruwanie pamięci podręcznej DNS?
Mechanika tego oszustwa opiera się na wyścigu z czasem. Przestępca nie włamuje się na twój komputer. On atakuje infrastrukturę rozwiązującą nazwy domenowe. Robi to w specyficzny, asymetryczny sposób.
- Haker wysyła do serwera rekursywnego zapytanie o domenę, którą chce podrobić, wiedząc, że serwer nie ma jej jeszcze w swoim lokalnym cache’u, co zmusza maszynę do wysłania zapytania wyżej w hierarchii do serwerów autorytatywnych i otwarcia portu nasłuchującego na odpowiedź zewnętrzną.
- Rusza nasłuch.
- Atakujący zalewa serwer rekursywny tysiącami fałszywych odpowiedzi UDP z podrobionym adresem IP, zgadując identyfikator transakcji (Transaction ID) zanim prawowity serwer zdąży odesłać prawdziwy pakiet.
- Serwer zapisuje fałszywy wpis i od teraz serwuje go każdemu użytkownikowi w sieci.
Wygranie tego wyścigu to loteria. Ale dysponując odpowiednią mocą obliczeniową, hakerzy skracają czas zgadywania do minimum. To nie jest teoria z książek. To się dzieje na żywo w niezabezpieczonych sieciach publicznych.
Skąd hakerzy wiedzą, jak podmienić rekordy DNS na serwerze?
Brak weryfikacji tożsamości pakietów UDP to największa dziura w systemie. Pakiety nie mają wbudowanego podpisu. Haker musi tylko trafić w odpowiedni port i 16-bitowy numer identyfikacyjny. Pamiętam wdrożenie na warszawskim Mokotowie u jednego z dostawców lokalnych w 2019 roku. Siedzieliśmy w serwerowni do trzeciej nad ranem. Wywalało nam routing na potęgę. Okazało się, że stary router brzegowy łykał fałszywe pakiety UDP z zewnątrz jak pelikan. Zrobiliśmy twardy reset BGP, potem zawiesiło się filtrowanie portów, więc wprowadzono poprawkę na firewallu tuż przed poniedziałkiem. Prawda jest zresztą absolutnie taka, że nikt wtedy nie myślał o bezpieczeństwie zapytań, po prostu chcieliśmy żeby sieć wstała. Klnęliśmy na czym świat stoi. Dopiero później zorientowaliśmy się, że ktoś celowo zatruwał nam tablice routingu.
Hakerzy skanują internet w poszukiwaniu otwartych resolverów. Używają botnetów do generowania ruchu. Znajdują słaby punkt i uderzają. Nie interesuje ich włamanie do konkretnej firmy. Interesuje ich przejęcie kontroli nad ruchem tysięcy ludzi naraz. Zmiana jednego rekordu A w tablicy przekierowuje całe osiedle na fałszywy panel logowania do poczty.
Jakie są najczęstsze skutki ataku man-in-the-middle przez DNS?
Konsekwencje są natychmiastowe i zazwyczaj finansowe. Kiedy ruch zostaje przekierowany, ofiara ląduje w środowisku całkowicie kontrolowanym przez stronę trzecią. To klasyczny wariant ataku man-in-the-middle, gdzie intruz stoi między tobą a usługą, z której chcesz skorzystać.
| Wektor ataku | Skutek techniczny na urządzeniu | Realna strata ofiary |
| Fałszywy portal bankowy | Przechwycenie sesji logowania w locie | Kradzież środków z konta. |
| Zatrucie aktualizacji OS | Pobranie złośliwego payloadu zamiast łatki | Instalacja ransomware na dysku twardym. |
| Przechwycenie poczty e-mail | Zmiana rekordów MX w locie | Wyciek korespondencji firmowej. |
| Kradzież ciasteczek sesyjnych | Wymuszenie logowania przez proxy hakera | Przejęcie kont w mediach społecznościowych. |
Widzicie to zestawienie wyżej. Bez mała prawie dziewięćdziesiąt procent udanych ataków tego typu kończy się utratą danych uwierzytelniających. Przestępcy nie bawią się w finezję. Kopiują kod HTML prawdziwej strony i stawiają go na swoim hostingu. Resztę załatwia zatruty serwer nazw, który sam posyła im ofiary.
Czy certyfikaty SSL chronią przed fałszywym adresem IP?
Zastanawiacie się zresztą, dlaczego kłódka w przeglądarce wciąż świeci na zielono, gdy ktoś kradnie wasze dane? Sam się nad tym borykałem dzisiaj u siebie we wtorek przeglądając logi z incydentów bezpieczeństwa. Przeglądarka widzi kłódkę. Ufa jej. Ale to oprogramowanie jest w gruncie rzeczy głupie. Certyfikat wystawił haker na własnym serwerze Let’s Encrypt, na który was bezczelnie przekierował. Przeglądarka sprawdza tylko, czy certyfikat zgadza się z domeną, na którą rzekomo weszliście. A przecież domena w pasku się zgadza. Zgadza się tekst. Nie zgadza się adres IP pod spodem, ale przeglądarka o to nie pyta.
To jest po prostu BZDURA z punktu widzenia szczelności systemu. Ludzie ufają kłódkom. A kłódka gwarantuje tylko tyle, że połączenie między wami a serwerem hakera jest szyfrowane. Haker widzi wszystko tekstem jawnym na swoim końcu rury. SSL nie weryfikuje tożsamości właściciela serwera w tanich certyfikatach DV (Domain Validation). Udowadnia jedynie kontrolę nad domeną w danym momencie. A skoro haker kontroluje DNS, udowadnia kontrolę nad domeną automatycznie.
Atak DNS spoofing – na czym polega i jak się przed nim chronić w sieci firmowej?
Dochodzimy do sedna. Atak DNS spoofing – na czym polega i jak się przed nim chronić, gdy odpowiadasz za infrastrukturę setek pracowników? Podstawa to rezygnacja z domyślnych serwerów dostarczanych przez lokalnych operatorów. Są wolne i często fatalnie zabezpieczone. Zastępujemy je rozwiązaniami korporacyjnymi. Ale to nie wystarczy.
Musimy wdrożyć walidację. Protokół DNSSEC dodaje kryptograficzne podpisy cyfrowe do rekordów. Kiedy serwer rekursywny pyta o adres, otrzymuje odpowiedź wraz z podpisem. Następnie weryfikuje ten podpis kluczem publicznym. Jeśli haker wyśle fałszywy pakiet, nie podrobi podpisu, bo nie ma klucza prywatnego. Serwer odrzuci kłamstwo. Użytkownik zobaczy błąd ładowania strony, ale jego dane pozostaną bezpieczne. Lepiej nie załadować strony wcale, niż załadować stronę przestępcy.
Dlaczego wdrożenie DNSSEC sprawia administratorom tyle problemów?
Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku. Ale z moich bezpośrednich obserwacji wynika, że firmy po prostu boją się awarii. Źle skonfigurowany DNSSEC odcina firmę od świata. Jeśli klucze kryptograficzne wygasną i nikt ich nie odnowi, cały internet uzna waszą domenę za fałszywą.
Widziałem to na własne oczy u klienta z branży e-commerce. Administrator zapomniał zrotować klucze. Rano sklep zniknął z sieci dla wszystkich użytkowników korzystających z Google DNS i Cloudflare. Dostawca internetu umył ręce. Straty szły w dziesiątki tysięcy złotych za każdą godzinę przestoju. Ludzie rezygnują z bezpieczeństwa na rzecz wygody i świętego spokoju na dyżurze. Zmieniliśmy te zasady na robocie. Wymuszamy monitoring ważności kluczy z alertami na telefon. Bez tego wdrożenie podpisywania strefy to tykająca bomba zegarowa.
Jakie narzędzia pomagają wykryć fałszywy serwer nazw u zwykłego użytkownika?
Dla domowego użytkownika sprawa wygląda inaczej. Nie macie dostępu do konfiguracji strefy. Musicie polegać na narzędziach diagnostycznych i własnej paranoi. Pierwszym krokiem jest użycie polecenia nslookup lub dig w terminalu systemowym. Zwykły ping też dużo mówi.
Otwierasz terminal. Wpisujesz ping do swojego banku. Zapisujesz adres IP. Rozłączasz się ze swoją siecią Wi-Fi, łączysz się przez dane komórkowe LTE. Robisz to samo. Jeśli adresy IP drastycznie się różnią, a nie jest to kwestia klastrów load-balancingowych (co można sprawdzić w internecie), masz powód do niepokoju. Hakerzy często celują w domowe routery z dziurawym oprogramowaniem. Przejmują panel admina, zmieniają serwer nazw na swój i gotowe. Cały domowy ruch leci przez Rosję albo Chiny.
Korzystajcie z VPN. Zawsze. Dobry klient VPN szyfruje cały ruch sieciowy, włączając w to zapytania o adresy domenowe. Tunneling wymusza używanie bezpiecznych resolverów dostawcy VPN, omijając to, co ustawił operator kablówki czy zhakowany router w kawiarni. To najprostsza i najbardziej brutalna metoda odcięcia się od lokalnych trucicieli pamięci podręcznej.
Czy zmiana domyślnych serwerów dostawcy internetu cokolwiek daje?
Tak. I to dużo. Twój dostawca internetu często oszczędza na infrastrukturze. Jego serwery są podatne na zatruwanie z powodu braku aktualizacji BINDa czy Unbounda. Zmień DNS na routerze na publiczne, zweryfikowane rozwiązania. To zajmuje minutę. A ratuje sieć przed masowymi atakami na poziomie krajowym.
Ustawienia w Windowsie czy macOS pozwalają nadpisać konfigurację z DHCP. Wpisz adresy Cloudflare (1.1.1.1) lub Quad9 (9.9.9.9). Quad9 dodatkowo filtruje zapytania, blokując domeny znane z dystrybucji złośliwego oprogramowania. Zrobi to za ciebie. Z kolei Google (8.8.8.8) ma tak potężną infrastrukturę, że zatrucie ich cache’u jest fizycznie niemal niemożliwe dla przeciętnego gangu ransomware. Różnicę w czasie ładowania stron też odczujecie natychmiast na plus. Operatorzy lokalni mają po prostu słaby sprzęt.
Atak DNS spoofing – na czym polega i jak się przed nim chronić, to w zasadzie pytanie o higienę cyfrową. Oprogramowanie antywirusowe nie zawsze złapie przekierowanie na poziomie pakietów UDP. Antywirus skanuje pliki na dysku. Zapytania sieciowe są często poza jego jurysdykcją. Wymuszajcie protokół DoH (DNS over HTTPS) w ustawieniach przeglądarki Firefox i Chrome. To zamyka zapytania o domeny w szyfrowanym tunelu HTTPS. Dostawca internetu nawet nie widzi, o jakie strony pytacie. O hakerze podsłuchującym sieć Wi-Fi nie wspominając.
Zaloguj się teraz na swój domowy router. Sprawdź zakładkę WAN. Zobacz, jakie adresy IP widnieją w sekcji serwerów nazw. Jeśli są to adresy przydzielone automatycznie przez dostawcę, zmień je na sprawdzone, globalne rozwiązania. Skonfiguruj DoH w swojej głównej przeglądarce. Zrób to od razu. Zostawienie domyślnych ustawień sieciowych to proszenie się o kradzież oszczędności przy najbliższym logowaniu do banku przez publiczne Wi-Fi w pociągu.
Często zadawane pytania (FAQ)
- Co to jest DNS spoofing?
DNS spoofing (zatruwanie pamięci podręcznej) to atak polegający na podmianie prawdziwego adresu IP przypisanego do domeny na fałszywy. W efekcie użytkownik zostaje potajemnie przekierowany na serwer hakera. - Jak sprawdzić, czy padłem ofiarą zatrucia DNS?
Użyj komendy ping lub nslookup w terminalu. Porównaj zwrócony adres IP z wynikami uzyskanymi po połączeniu przez inną sieć, np. komórkową. - Czy antywirus chroni przed atakiem DNS spoofing?
Nie zawsze. Antywirusy rzadko analizują pakiety UDP w locie. Lepszą ochroną jest VPN i włączenie DNS over HTTPS (DoH) w przeglądarce. - Jakie darmowe serwery DNS są najbezpieczniejsze?
Zaleca się zmianę domyślnych serwerów dostawcy na Cloudflare (1.1.1.1), Quad9 (9.9.9.9) lub Google (8.8.8.8). - Czym jest protokół DNSSEC?
To technologia dodająca podpisy kryptograficzne do odpowiedzi serwerów nazw, uniemożliwiająca hakerom podrzucenie fałszywego adresu IP bez posiadania klucza prywatnego domeny. - Czy korzystanie z VPN zapobiega atakom na serwery nazw?
Tak. VPN szyfruje zapytania sieciowe i wysyła je do własnych, chronionych resolverów, całkowicie ignorując potencjalnie zainfekowany router domowy.
Bibliografia
1. CERT Polska – https://cert.pl
2. NASK – https://nask.pl
3. Niebezpiecznik – https://niebezpiecznik.pl
4. Zaufana Trzecia Strona – https://zaufanatrzeciastrona.pl
5. Sekurak – https://sekurak.pl
6. Cloudflare – https://cloudflare.com
