K

iedy wpisujemy URL w pasku adresu nasz komputer wysyła zapytanie DNS do właściwego serwera DNS i otrzymuje odpowiedni adres IP, który służy do osiągnięcia łączności z docelowym systemem. Protokoły takie, jak SSL/TLS, HTTPS zapewniają szyfrowanie komunikacji pomiędzy serwerem, a klientem po fakcie rozwiązania nazwy domeny. A, co jeśli atakujący przejmie komunikację pomiędzy serwerem DNS i jego klientem podczas procesu rozwiązywania domeny? Przekieruje ruch do spreparowanego serwera w celu kradzieży danych lub przeprowadzenia ataku DoS? W tym celu został opracowany mechanizm bezpieczeństwa pod postacią ciasteczka DNS.

Ciasteczka DNS są lekkim mechanizmem bezpieczeństwa opartym na transakcji. W swoim zamyśle mają one bronić serwery DNS i ich klientów przed atakami typu: DoS, DNS Amplification czy Cache Poisoning. Współgrają z istniejącymi mechanizmami transakcji DNS – działają nawet w sieciach gdzie obecne są rozwiązania typu NAT oraz NAT-PT. Aktualnie istnieje wiele uchybień w bezpieczeństwie działania obecnego protokołu DNS. W pierwszej części omówmy pokrótce kilka z nich:

Ataki DoS:

Kiedy klient wysyła żądanie do serwera DNS powoduje na nim określone obciążenie obliczeniowe. Rekursywny serwer DNS może obsługiwać oraz przetwarzać równolegle kilkanaście i więcej żądań. Im większy ruch jest obsługiwany przez serwer DNS tym jego moc obliczeniowa jest bardziej wykorzystywana. Jeszcze większe obciążenie powoduje wykorzystywanie mechanizmu DNSSEC, który bazuje na obliczeniach kryptograficznych w celu weryfikacji autentyczności transakcji DNS. Więc, jeśli atakujący zacznie fałszować źródłowy adres IP (IP Spoofing) i zacznie wysyłać ogromną ilość żądań DNS do serwera może doprowadzić do wyczerpania jego zasobów obliczeniowych ostatecznie przeprowadzając udany atak DoS. Dlaczego atakujący zadał sobie trud, aby fałszować źródłowy adres IP? Aby trudniej było określić, jaki ruch jest normalny i przepuszczalny, a jaki wrogi i należy go ograniczyć.

DNS Cache Poisoning:

Za pierwszym razem kiedy wpisujemy URL w pasku adresu przeglądarki nasz komputer wykona zapytanie DNS do odpowiedniego serwera DNS. Gdy tylko otrzyma odpowiedź zapisze sobie adres IP w pamięci podręcznej z licznikiem czasowym. Po upływie wyznaczonego czasu w liczniku wpis ten przestanie obowiązywać i komputer będzie musiał ponownie odpytać serwer DNS, gdy ponownie będziemy chcieli odwiedzić daną stronę. Dopóki licznik nie wygaśnie to, jeśli wpiszemy ten sam URL w pasku adresu – nasz komputer będzie szukał przetłumaczenia domeny na adres IP w swojej pamięci cache. Załóżmy teraz, że nasza maszyna wykonała zapytanie DNS i czeka na odpowiedź od serwera DNS. Niestety w ramach ataku zamiast autentycznej i potwierdzonej odpowiedzi otrzymujemy fałszywą, kierującą na adres IP strony atakującego (dodatkowo licznik czasowy został ustawiony na bardzo długi okres). W ten sposób nasza pamięć podręczna została otruta i za każdym razem nasza stacja będzie rozwiązywała URL na serwer agresora. W ten sam sposób mogą być otruwane pamięci cache serwerów DNS, które odpytujemy. Wynika to z faktu, że serwery DNS naszych ISP otrzymują odpowiedzi od innych serwerów DNS i odpowiedzi przechowują w swoich pamięciach. Jeśli ich pamięć zostanie otruta fałszywa odpowiedź rozprzestrzeni się do wszystkich domowych routerów, komputerów itd., które obsługują.

DNS Amplification Attack:

Jeśli atakujący wysyła całe mnóstwo zapytań DNS to serwera DNS, ale wcześniej sfałszował swój adres IP wskazując go na maszynę ofiary – to wszystkie odpowiedzi na zapytania DNS zostaną wygenerowane i odesłane do maszyny ofiary. Normalnie bez żadnego mechanizmu bezpieczeństwa serwer DNS nie rozróżnia, które zapytania DNS pochodzą z legalnego, a które z podrobionego ruchu sieciowego. W dodatku atak jest wzmacniany ze względu na fakt, że odpowiedzi na zapytania DNS są objętościowo większe i mogą łatwo zalać komputer ofiary oraz wyczerpać przepustowość jego łącza – przeprowadzając udany atak DoS.

Istniejąca ochrona DNS:

Istnieje już kilka mechanizmów bezpieczeństwa, które mogą posłużyć do zabezpieczenia komunikacji DNS, ale każda z nich ma swoje mocne i słabe strony. Na przykład DNSSEC (ang. DNS Security Extensions) jest rozszerzeniem bezpieczeństwa używanym do weryfikacji autentyczności transakcji DNS. DNSSEC może zapewnić nas, że odpowiedź pochodząca od serwera DNS jest uwierzytelnionym źródłem danych i ochronić nas przed takimi atakami jak DNS Hijacking oraz DNS Cache Poisoning. Jednak – jak wspomniałem wcześniej – DNSSEC wykonuje wiele kryptograficznych obliczeń, co powoduje obciążanie obliczeniowe serwerów DNS. W rezultacie, jeśli atakujący sfałszuje źródłowy adres IP i zacznie wysyłać mnóstwo zapytań DNS ze złymi kluczami to spotęguje sytuację, w której może zostać przeprowadzony atak DoS. W dodatku DNSSEC wykorzystuje większe niż normalne odpowiedzi DNS jako sposób na dodanie dodatkowego zabezpieczenia: weryfikacji, czy przesłane dane pochodzą z określonego źródła i nie zostały po drodze zmodyfikowane. Brzmi znajomo prawda? Takie zachowanie przypomina schemat do wykorzystania w ataku wzmocnienia.

Kolejną warstwą bezpieczeństwa jest TSIG (ang. Transaction SIGnature). Używa kluczy kryptograficznych do nawiązania zaufanego połączenia pomiędzy klientem oraz serwerem w celu przeprowadzenia bezpiecznej transakcji. TSIG dostarcza dobry poziom bezpieczeństwa, ale nie jest trywialne do bezobsługowej implementacji. Dokłada dodatkowe obciążenie do istniejącego ekosystemu: wstępna wymiana i dystrybucja kluczy (także po ich cyklicznej wymianie); śledzenie stanu kluczy po stronie serwera oraz synchronizacji z klientem.

W drugiej części artykułu poznamy dokładną zasadę działania ciasteczek DNS oraz ich wpływ na bezpieczeństwo i prywatność.

Więcej informacji: RFC 7873 – Domain Name System (DNS) Cookies