Zatruwanie systemu nazw

Autor: Arkadiusz Tobiasz 14 lutego 2009

01hakin9W najnowszym numerze magazynu hakin9 trafiłem na bardzo ciekawy artykuł o zatruwaniu serwera nazw. Nawiązuje on sprawy poważnej luki w protokole DNS, którą w lipcu ubiegłego roku wykrył Dan Kaminsky. Cała sprawa wywołała ogromną burzę w mediach elektronicznych, a o szczegółach błędu dowiedzieliśmy się dopiero po akcji, której celem było zabezpieczenie najpopularniejszego opogramowania sieciowego.

Czym jest protokół DNS?

DNS to protokół komunikacyjny, który zapewnia zamianę adresów znanych użytkownikowi Internetu na adresy zrozumiałe dla urządzeń, które tworzą sieć komputerową.  Ogólnie rzecz ujmując protokół DNS zamienia adres internetowy na adres IP, którym posługują się urządzenia sieciowe. Specyfikacja tego protokołu zawarta jest w serii dokumentów RFC, a przede wszystkim w dokumentach o numerach 1034 i 1035.

Z czego się składa protokół DNS?

Pakiet DNS składa się z nagłówka po którym mogą wystąpić cztery sekcje takie jak: pytania, odpowiedzi, autoratywna oraz dodatkowa. Każda z sekcji zawiera rekordy zasobów, które zawierają informacje przypisane do konkretnej nazwy domenowej. Rekordy te mogą mieć różny typ i tak na przykład mamy typ A (adres IPv4), AAAA (adres IPv6) czy MX (nazwa serwera pocztowego).

Skupmy się jednak na nagłówku, który służy do opisania komunikatu i zawartości. Poniższy rysunek przedstawia jego schemat (zdjęcie z pochodzi z Wikipedii).

naglowek-dns-copy

Jak zauważyłeś składa się on z poszczególnych pól. Spróbuję je krótko opisać:
ID – identyfikator komunikatu, który rozróżnia poszczególne zapytania, a także odpowiedzi na nie.
QR – flaga, która określa czy dany komunikat jest pytaniem czy odpowiedzią.
OPCODE – rodzaj zapytania.
AA – flaga, której obecność mówi nam, że otrzymana odpowiedź jest autoratywna.
TC – mówi nam, że komunikat skrócono ze względu na ograniczenia użytego kanału komunikacyjnego.
RD – żądanie rekurencyjnej obsługi zapytania.
RA – flaga, która jest włączana w odpowiedziach od serwerów, które obsługują tryb rekurencyjny.
Z – zarezerwowane, które powinno być ustawione na zero we wszystkich odpowiedziach i zapytaniach.
RCODE – kod odpowiedzi, odpowiada za obsługę błędów

Ostatnie cztery pola odpowiedzialne są za ilość rekordów zasobów, które znajdują się w komunikacie. Kolejne dwie sekcje – pytania i odpowiedzi – wydają się być oczywiste, więc je pominę. Sekcja autoratywna zawiera nazwy serwerów, które mogą udzielić odpowiedzi autoratywnej. Natomiast sekcja dodatkowa służy przekazywaniu informacji przydatnych dla pytajacego.

Bezpieczeństwo

Bezpieczeństwo systemu nazw opiera się na dwóch źródłach: identyfikatorze komunikatu oraz pamięci podręcznej. Identyfikator komunikatu rozróżnia poszczególne zapytania, które wysyła resolver (biblioteka, zestaw podprogramów, który zawiera funkcje pozwalające na translację adresów symbolicznych na numeryczne i odwrotnie) i odpowiedzi udzielanych przez serwer.  Odpowiedź, której udziela serwer musi mieć taki sam identyfikator jak zapytanie, na które serwer odpowiada. Identyfikator to liczba 16-bitowa, czyli może przyjąć tylko 65 536 wartości. Mała długość identyfikatora może stanowić nieznaczne zagrożenie.

Nowa metoda zatruwania systemu nazw

Kaminsky odkrył, że większość serwerów nazw podczas realizacji zapytań rekurencynyjnych, wysyłało zapytania z jednego i tego samego portu. W związku z tym serwery są podatne na atak przedstawiony na przykładzie poniżej:

ns.ofiara.pl – serwer nazw, które pamięć będziemy zatruwać, obsługuje żądania rekursywne, a zapytania wysyła z jednego portu.
www.pewnastrona.pl – nazwa, którą haker chce przejąć.
1.2.3.4 – adres komputera, który kontroluje haker.
ns.pewnastrona.pl – serwer nazw autoratywny dla domeny www.pewnastrona.pl.

Haker rozpoczyna od poproszenia serwera ns.ofiara.pl o rozwiązanie nazwy a1.pewnastrona.pl. Ważne jest, aby była to nazwa, której ofiara nie ma zapisanej w pamięci podręcznej i jednocześnie nie musi ona istnieć w przestrzeni nazw domen. Haker dodatkowo zaznacza, aby żądanie obsługiwane było w trybie rekursywnym. Wszystko może być wysłane z fałszywego IP, ponieważ nie jest ważna otrzymana odpowiedź. Serwer ns.ofiara.pl stara się rozwiązać nazwę.

Serwer nazw ns.ofiara.pl chcąc rozwiązać nazwę a1.pewnastrona.pl musi skontaktować się z serwerem autoratywnym dla strefy www.pewnastrona.pl, którym jest ns.pewnastrona.pl. Tutaj wkracza haker, który podszywa się pod serwer ns.pewnastrona.pl i wysyła sfałszowane odpowiedzi do serwera nazw ns.ofiara.pl. Odpowiedź ta zawiera informację, że adresem dla www.pewnastrona.pl jest 1.2.3.4. Atakujący musi dodatkowo wysłać dużą liczbę pakietów z różnymi identyfikatorami, ponieważ nie zna identyfikatora komunikatu.

Atak powiedzie się tylko wtedy, gdy hakerowi uda odgadnąć się prawidłowy identyfikator komunikatu. Kiedy atak się powiedzie serwer ns.ofiara.pl zapamięta tą odpowiedź w swojej pamięci podręcznej i kazde zapytanie o stronę www.pewnastrona.pl przekieruje na adres 1.2.3.4.

Wszystkich, których ta notatka zainteresowała zachęcam do lektury artykułu w najnowszym numerze magazynu hakin9, w którym to zagadnienie zostało o wiele szerzej opisane.

Jeden komentarz

  1. […] pisałem o zatruwaniu systemu nazw, a dzisiaj trochę o zdalnym łamaniu haseł. Nakłonił mnie do tego bardzo ciekawy artykuł w […]

Odpowiedz

 

Arkadiusz Tobiasz student Akademii Ekonomicznej im. Karola Adamieckiego w Katowicach na specjalnościach informatyka ekonomiczna oraz rachunkowość. Więcej...

jQuery Validation i funkcja remote

Jakiś czas temu zwrócił się do mnie użytkownik z problemem. Chodzi o to, że korzysta on z pluginu walidacji jQuery, […]

Zend Framework: integracja z Uploadify

W tym wpisie postaram się przedstawić Wam w jaki sposób zintegrować skrypt Uploadify z Zend Frameworkiem. Dzięki temu będziemy mogli […]

Javascript: Czasowe wyświetlanie reklamy

Czasami chcemy, aby na pewnym elemencie naszej strony wyświetlała się reklama przez jakiś czas, a następnie zniknęła. W tym wpisie […]

Linux: backup wszystkich baz danych MySQL

Swego czasu pisałem o tym jak z poziomu konsoli można szybko i przyjemnie zrobić backup bazy MySQL. Wszystko jest ładnie […]