Analiza problemu DNS cache poisoning w polskim Internecie.
69% resolverów nadal podatne na atak.

Dnia 2008-07-08 (CVE-2008-1447) w Internecie pojawiły się informacje o wykrytej słabości protokołu DNS pojawiającej się w wielu powszechnie dostępnych implementacjach tego protokołu umożliwiającej atak "zatrucia" pamięci serwera DNS (ang. cache poisoning). Odkrywcą tej luki jest Dan Kaminsky.

Dział Domen NASK sprawdził jak wygląda problem, jaki jest wektor ataku i jak sytuacja przedstawia się po 3 tygodniach od publikacji dziury.

Jak powszechnie wiadomo DNS odpowiada za translacje nazw domen na odpowiadające im adresy IP. W uproszczeniu, kiedy pytam o adres www.cache-poisoning.pl uzyskuję informację, że odpowiadający tej nazwie adres IP to 193.59.201.40. W tym celu resolver 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.

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. Hacker chce aby użytkownik uwierzył, że www.cache-posinoning.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 od autorytatywnego serwera, a czym te złe wysyłane od hackera? Właśnie naszym identyfikatorem 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. Hacker musiał być tylko szybszy od autorytatywnego serwera w dostarczeniu pakietu do użytkownika żeby zatruć jego cache.

Problem został rozwiązany poprzez 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 hacker trafi w poprawny QID,
• w kiepskich generatorach liczb losowych, 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 jest różnej wielkości i 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? Załóżmy taki scenariusz. Hacker modyfikuje swój serwer DNS tak, ż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 resolvera 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 resolver 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 rozwiązano 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 innych stref.

A jednak problem zaistniał i znalazł go Dan Kaminsky. Załóżmy, że hacker udaje, że użytkownik pyta o adres aaaaa.dobry-serwis.pl. Zapytanie skierowane zostaje do resolvera ISP naszego nic nie podejrzewającego użytkownika. Resolver ISP wysyła zapytanie do autorytatywnego serwera obsługującego strefę dobry-serwis.pl. Resolver ISP otrzymuje informacje od autorytatywnego serwera, że taka domena nie istnieje (NXDOMAIN). W tym czasie hacker próbuje trafić ze swoją odpowiedzią w pakiet skierowany do resolvera ISP. Hacker przegrywa i resolver dostaje prawidłowy pakiet. Hacker 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 resolver ISP dostaje fałszywy pakiet zawierający adres IP dla domeny cvbxa.dobry-serwis.pl, ale w pakiecie znajduje się coś więcej! W sekcji Additional tego pakietu znajduje się informacja, że domena www.dobry-serwis.pl posiada adres IP 1.2.3.4! W ten sposób hacker połączył dwie opisane wyżej techniki. Zatruł cache resolvera 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 resolvera z którego wysyłane są zapytania DNS. Tak naprawdę to obejście problemu. Problem RRset cache poisoning istnieje nadal. Zmieniła się tylko ilość losowych portów do zgadnięcia z 16 do 32 bitów.

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

Po przeanalizowaniu ponad 150 000 000 zapytań DNS do serwerów domeny .pl okazuje się, że ponad 2/3 resolveró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 i użytkownicy końcowi ze swoimi systemami (Windows/Linux/Mac) nie załatali swoich maszyn.

W sieci od dawna dostępne są odpowiednie aktualizacje na każdą platformę i zainstalowanie ich 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 tę lukę w systemie DNS. O ile wcześniej należało wykazać się sporą wiedzą na temat bezpieczeństwa protokołu DNS żeby wykorzystać tę lukę o tyle teraz wystarczy skorzystać z gotowego narzędzia.

Liczba przeanalizowanych zapytań: 157287682
Liczba różnych resolverów: 23022
Liczba resolverów podatnych na atak: 15924 (69%)