Spoofing DNS i zatruwanie pamięci podręcznej

Fałszowanie DNS polega na dostarczeniu podrobionej odpowiedzi DNS, aby ofiara rozwiązała nazwę na adres IP kontrolowany przez napastnika. Zatrucie pamięci podręcznej to szczególna odmiana tego ataku, w której podrobiona odpowiedź zostaje zaakceptowana i zapisana przez resolver rekurencyjny, infekując każdego korzystającego z niego klienta.

Celem jest zazwyczaj przekierowanie ruchu: wysyłanie użytkowników do stron phishingowych, miejsc pobierania złośliwego oprogramowania lub serwerów proxy typu man-in-the-middle.

Gdy resolver wysyła zapytanie, napastnik próbuje wstrzyknąć podrobioną odpowiedź zanim odpowie właściwy serwer autorytatywny. Jeśli fałszerstwo dotrze jako pierwsze i będzie zawierać oczekiwane pola, wygra wyścig i zostanie zapisane w pamięci podręcznej.

Dlatego w ataku i obronie tak duże znaczenie mają opóźnienie, kolejność pakietów oraz wychodzący port resolvera.

Aby podrobiona odpowiedź UDP została zaakceptowana, napastnik musi dopasować:

• Źródłowy adres IP (serwera autorytatywnego).
• Port docelowy (wychodzący port resolvera).
• Najmę zapytania i jego typ.
• 16-bitowy identyfikator transakcji (TXID).

Bez zabezpieczeń jedyną rzeczywistą tajemnicą pozostaje TXID, co daje szansę około 1 na 65 536 dla każdego pakietu.

Ujawnienie sprawy przez Dana Kaminsky’ego w 2008 roku pokazało, że zatruwanie pamięci podręcznej jest znacznie łatwiejsze, niż sądzono. Zamiast przeprowadzać jeden wyścig dla każdego rekordu, napastnik odpytuje wiele nieistniejących subdomen (aaa.bank.com, aab.bank.com...) i zalewa resolver podrobionymi odpowiedziami zawierającymi złośliwy rekord NS lub rekord glue dla całej domeny.

Każda próba jest nowym wyścigiem, a brak trafienia nie wiąże się z karą wynikającą z pamięci podręcznej, dzięki czemu napastnik może ponawiać próby aż do trafienia i zatruć całą strefę.

Głównym zabezpieczeniem wprowadzonym po ataku Kaminsky’ego było losowanie portu źródłowego. Zamiast stałego portu wychodzącego resolver wybiera losowy port efemeryczny dla każdego zapytania.

Napastnik musi teraz odgadnąć zarówno TXID (16 bitów), jak i port źródłowy (około 16 bitów), co zwiększa przestrzeń wyszukiwania do około 2^32. Dzięki temu ślepe zatruwanie pamięci podręcznej przez napastnika spoza trasy staje się niepraktyczne, choć nie jest niemożliwe w przypadku implementacji o słabej entropii.

Napastnik spoza trasy nie widzi zapytania i musi ślepo odgadnąć TXID oraz port. Napastnik na trasie (złośliwa sieć Wi-Fi, przejęty router lub dostawca internetu) może bezpośrednio odczytać zapytanie i bez trudu przygotować pasującą odpowiedź.

Fałszowanie na trasie całkowicie omija losowanie portu, dlatego do uzyskania silnych gwarancji potrzebne są szyfrowany transport i walidacja DNSSEC, a nie tylko entropia.

Napastnicy nie zawsze fałszują pakiety. Nieautoryzowany serwer DHCP może przekazać klientom adres złośliwego resolvera, przez co każde zapytanie będzie obsługiwane przez napastnika. Złośliwe oprogramowanie podobnie modyfikuje plik /etc/resolv.conf lub ustawienia routera.

Historyczne zagrożenia, takie jak złośliwe oprogramowanie DNSChanger, przez lata po cichu przekierowywały DNS ofiar na fałszywe serwery. Należy zweryfikować, z których resolverów faktycznie korzystają wszystkie urządzenia.

Resolvery egzekwują reguły bailiwick: odpowiedź może dostarczać rekordy wyłącznie dla nazw należących do strefy, dla której dany serwer jest autorytatywny. Odpowiedź dla bank.com nie może przemycić rekordu dla unrelated.com.

Ogranicza to wstrzykiwanie w stylu ataku Kaminsky’ego do odpytywanej domeny i zapobiega zanieczyszczeniu niezależnych stref przez jedną zatrutą odpowiedź. Należy sprawdzić, czy resolver stosuje ścisłe filtrowanie bailiwick.

Oznaki trwającego lub zakończonego powodzeniem zatruwania:

• Nagły wzrost liczby zapytań dotyczących losowych, nieistniejących subdomen.
• Zduplikowane odpowiedzi DNS lub odpowiedzi przychodzące w niewłaściwej kolejności dla tego samego TXID.
• Adresy IP uzyskiwane w wyniku rozwiązywania nazw nagle wskazujące nieoczekiwane numery ASN lub lokalizacje geograficzne.
• Rozbieżność między odpowiedziami resolvera a zaufanym zapytaniem wykonanym poza pasmem.

Nie wystarczy pojedynczy mechanizm. Należy połączyć:

• Losowanie portu źródłowego i TXID, aby podnieść koszt ataku spoza trasy.
• Walidację DNSSEC, dzięki której podrobione odpowiedzi nie przejdą kontroli podpisu.
• DoT/DoH, aby odebrać napastnikom na trasie możliwość obserwacji i modyfikacji.
• Kodowanie 0x20 (losowe użycie wielkich i małych liter w nazwach zapytań) zapewniające dodatkową entropię.
• Monitorowanie zalewów NXDOMAIN i anomalii odpowiedzi.

W praktyce ślepe zatruwanie pamięci podręcznej przez napastników spoza trasy jest dziś rzadkie w przypadku zaktualizowanych resolverów, ale powraca za pośrednictwem kanałów bocznych, na przykład fragmentacji UDP oraz opartych na ICMP ataków polegających na wnioskowaniu o porcie, takich jak SAD DNS. Należy regularnie aktualizować resolvery i preferować resolvery przeprowadzające walidację oraz korzystające z szyfrowanego transportu.

Warto pamiętać, że najbardziej szkodliwe przejęcie DNS często nie wynika z pomysłowego wyścigu podczas zatruwania pamięci podręcznej, lecz ze skradzionego konta u rejestratora. Należy zabezpieczyć oba elementy.

Spoofing DNS fałszuje odpowiedzi, a zatruwanie pamięci podręcznej utrwala je w resolverze. Akceptacja zależy od zgodności źródłowego adresu IP, portu, nazwy zapytania i TXID. Randomizacja portu źródłowego oraz sprawdzanie zakresu autorytatywności podniosły poprzeczkę atakującym spoza ścieżki transmisji, ale atakujący znajdujący się na tej ścieżce oraz kanały boczne nadal stanowią zagrożenie.

Obrona warstwowa — entropia, walidacja DNSSEC, szyfrowany transport i monitorowanie — jest niezbędna. Następnie przyjrzymy się temu, jak atakujący wykorzystują DNS do przesyłania danych: tunelowaniu i eksfiltracji.