Działanie systemu DNS

Jak powszechnie wiadomo, DNS odpowiada za translacje nazw domen na odpowiadające im adresy IP. W uproszczeniu, kiedy pytamy o adres „www.cache-poisoning.pl”, uzyskujemy informację, że odpowiadający tej nazwie adres IP to 193.59.201.40. W tym celu resolwer tworzy pakiet zwany zapytaniem i wysyła go do serwera DNS. Wymiana takich pakietów nazywa się transakcją.

W Sieci krąży wiele pakietów, dlatego w celu uporządkowania tego transakcyjnego chaosu wykorzystuje się identyfikator transakcji (transaction IDs). W przypadku zapytań DNS takim identyfikatorem jest QID (query ID). Jest to identyfikator składający się na pierwsze 16 bitów pakietu DNS.

Opis problemu

Gdzie leży słabość tego mechanizmu? Załóżmy, że użytkownik chce uzyskać od autorytatywnego serwera poprawną odpowiedź na zapytanie o adres IP dla domeny www.cache-poisoning.pl, czyli 193.59.201.40. Haker chce, aby użytkownik uwierzył, że www.cache-poisoning.pl to 1.2.3.4. W tym celu zasypuje użytkownika podstawionymi pakietami DNS zawierającymi fałszywy adres IP dla tego zapytania. Czym różnią się odpowiedzi wysyłane przez autorytatywny serwer, a czym te złe, wysyłane przez hakera? Różnicą jest właśnie nasz identyfikator QID.

W roku 1995 zwrócono uwagę na problem przewidywalności QID. Algorytmy zwiększały identyfikatory kolejno o 1, nie wprowadzając żadnej losowości. Haker musiał być tylko szybszy od autorytatywnego serwera w dostarczeniu pakietu do użytkownika, żeby zatruć jego cache.

Problem został rozwiązany przez wprowadzenie losowych QID-ów. Implementacja tego rozwiązania ma jednak pewne wady:

• im więcej zapytań wyśle użytkownik do autorytatywnego serwera, tym większe jest prawdopodobieństwo, że haker trafi w poprawny QID,

• w kiepskich generatorach liczb pseudolosowych losowość może być przewidywalna,

• 16 bitów to za mała liczba w dzisiejszych czasach, żeby zapewnić odpowiedni poziom bezpieczeństwa.

Istnieje jeszcze inny sposób na zatrucie pamięci serwera DNS. Nazywa się „RRset cache poisoning” i związany jest z samą budową pakietu DNS. Pakiet DNS nie ma bowiem stałej wielkości – składa się z nagłówka, kilku flag oraz RRset (Resource Records set). W pakiecie DNS znajduje się do trzech takich RR (Resource Records):

• Resource Record zawierający odpowiedź na nasze zapytanie (Answer RR), np. rekord A 193.59.201.40 dla zapytania o adres IP dla domeny www.cache-poisoning.pl,

• Resource Record zawierający informacje o serwerach autorytatywnych (Authority RR),

• Resource Record zawierający wszelkie dodatkowe informacje (Additional RR), czasem zwany „glue recordem”.

Gdzie leży słabość takiej budowy pakietu? Wyobraźmy sobie następujący scenariusz. Haker tak modyfikuje swój serwer DNS, że za każdym razem w odpowiedzi oprócz poprawnych danych w sekcji Answer i Authority wysyła także spreparowane dane w sekcji Additional. Zakłada serwis www.zły-serwis.pl. Instaluje na nim wiele podstron, których adresy DNS znajdują się na kontrolowanym przez niego serwerze DNS (np. linki do obrazków). Nieświadomy użytkownik wchodzi na taką stronę, korzystając przy rozwiązywaniu nazw domenowych z resolwera swojego ISP, i otrzymuje informacje o adresach IP dla serwisu zły-serwis.pl, ale w sekcji dodatkowej dostaje informacje, że adres www.dobry-serwis.pl to 1.2.3.4, a resolwer jego ISP zapisuje tę informacje w swojej pamięci. Następnym razem, kiedy użytkownik wpisze w przeglądarkę adres www.dobry-serwis.pl, zostanie przekierowany na adres 1.2.3.4.

Tak wyglądała przeszłość. Opracowane mechanizmy zabezpieczające zostały już dawno wprowadzone. Odpowiednie algorytmy zapewniają losowość identyfikatorów QID. Jeżeli chodzi o problem dodatkowych informacji w pakiecie DNS, to rozwiązane zostało to w ten sposób, że pytając o rekordy ze strefy dobry-serwis.pl, zapamiętujemy tylko rekordy z tej strefy, pomijając informacje z pozostałych.

A jednak problem zaistniał i znalazł go Dan Kaminsky. Załóżmy, że haker udaje, iż użytkownik pyta o adres aaaaa.dobry-serwis.pl. Zapytanie skierowane zostaje do resolwera ISP naszego nic niepodejrzewającego użytkownika. Resolwer dostawcy Internetu wysyła zapytanie do autorytatywnego serwera obsługującego strefę dobry-serwis.pl i otrzymuje informacje od autorytatywnego serwera, że taka domena nie istnieje (NXDOMAIN). W tym czasie haker próbuje trafić ze swoją odpowiedzią w pakiet skierowany do resolwera ISP. Haker przegrywa i resolwer dostaje prawidłowy pakiet. Haker ponawia próbę, tym razem dla domeny aaaab.dobry-serwis.pl, i również mu się nie udaje. Jednak gdzieś w okolicy domeny cvbxa.dobry-serwis.pl wygrywa wyścig z serwerem autorytatywnym i resolwer ISP dostaje fałszywy pakiet zawierający adres IP dla domeny cvbxa.dobry-serwis.pl. Ale tym razem w pakiecie znalazło się coś więcej! W sekcji Additional tego pakietu znajduje się informacja, że domena www.dobry-serwis.pl ma adres IP 1.2.3.4! W ten sposób haker połączył dwie opisane wyżej techniki. Zatruł cache resolwera ISP i oszukał użytkownika.

Rozwiązaniem tego problemu było wprowadzenie dodatkowych 16 bitów losowości w postaci zmiennego portu źródłowego resolwera, z którego wysyłane są zapytania DNS. Tak naprawdę jest to tylko obejście problemu. Problem RRset cache poisoning istnieje nadal – zmieniła się tylko liczba losowych portów do zgadnięcia z wielkości określonej przez 16 bitów do 32 bitów.

Sytuacja obecna

Jak wygląda sytuacja w naszym kraju dzisiaj, trzy tygodnie po pojawianiu się informacji o luce i odpowiednich łatkach? Kiepsko, żeby nie powiedzieć bardzo kiepsko.

Po przeanalizowaniu ponad 150 milionów zapytań DNS do serwerów domeny .pl okazało się, że ponad 2/3 resolwerów (znajdujących się w polskich klasach adresowych, bo takie adresy IP zostały przeanalizowane) jest nadal podatna na ten atak. Dziwne, że tak poważny problem został w taki sposób zbagatelizowany, a tzw. administratorzy zarządzający DNS-em i użytkownicy końcowi ze swoimi systemami (Windows/Linux/Mac OS X) nie załatali swoich maszyn.

W Sieci bowiem od dawna dostępne są odpowiednie aktualizacje na każdą platformę i ich zainstalowanie nie stanowi większego problemu zarówno dla doświadczonych administratorów, jak i dla zwykłych użytkowników.

Kilka dni temu w Sieci pojawił się również ogólnie dostępny exploit wykorzystujący lukę w systemie DNS. O ile wcześniej należało wykazać się znaczną wiedzą na temat bezpieczeństwa protokołu DNS, żeby z sukcesem zatruć cache serwera, o tyle teraz wystarczy skorzystać z gotowego narzędzia.

Dane

• Liczba przeanalizowanych zapytań: 157 287 682,

• Liczba różnych resolwerów: 23 022,

• Liczba resolverów podatnych na atak: 15 924 (69%).