Przedwczoraj w sieci pojawił się exploit wykorzystujący błędy w DNS, o których pisaliśmy 9-tego lipca (Błędy w DNS dotyczące większości producentów).
Exploit pojawił się kilka dni po “wycieku” szczegółów błędów odkrytych przez Dana Kaminsky’ego. Większość producentów serwerów DNS udostępniła już poprawki (należy sprawdzić na stronie dostawcy). Dodatkowo (w miarę możliwości) warto ograniczyć dostęp do DNSu tylko do zaufanych klas adresów, wprowadzić zabezpieczenia przed spoofingiem na granicy sieci, oraz wyłączyć rekursywne odpowiedzi na pytania pochodzące z niezaufanych źródeł.

Jeżeli podjęcie powyższych kroków nie jest w tej chwili możliwe, administratorzy powinni co najmniej tymczasowo przekierować zapytania do DNSu, o którym wiadomo, że nie jest podatny (na przykład serwery OpenDNS).

Ostatnio w Internecie pojawiły się informacje o wykryciu bardzo groźnego błędu w DNS. W rzeczywistości są to pewne niedociągnięcia w protokole DNS, a także w popularnych jego implementacjach, które potencjalnie mogą zostać wykorzystane do ataku na serwery DNS. Atak ten może polegać na tzw. zatruwaniu pamięci serwera DNS (ang. DNS cache poisoning). W rezultacie serwer DNS odpytujący rekursywnie inny serwer DNS może zostać oszukany przez atakującego (który podszywa się pod serwer odpytywany), przez co klientowi zwracany jest fałszywy adres IP. Dzięki temu na przykład chcąc wejść na jakąś stronę internetową, zostaniemy skierowani na zupełnie inny serwer WWW. Może to być wykorzystywane np. do infekowania złośliwym oprogramowaniem ludzi surfujących po Internecie, lub wyłudzania od nich loginów i haseł do ich kont bankowych.

Pierwszym problemem jest sam protokół DNS, który wykorzystuje w komunikacji protokół UDP. Ponieważ taka komunikacja odbywa się bez połączenia, trudniej jest zweryfikować autentyczność serwera, z którego odbierane są dane (atakujący może się pod niego podszyć).

Ponadto, każde zapytanie zawiera potencjalnie unikalny losowo generowany 16-bitowy numer ID, który musi znaleźć się w odpowiedzi. Atakujący, chcąc podszyć się pod pytany serwer i sfałszować odpowiedź, musi zgadnąć ten numer. Niestety niektóre implementacje mogą używać słabych pod względem unikalności/losowości numerów ID, przez co atakujący może łatwiej i szybciej go zgadnąć.

Kolejnym problemem może być numer portu, z którego wysyłane jest zapytanie. Aby wymiana informacji przebiegła pomyślnie, odpowiedź musi zostać przesłana serwerowi zapytującemu na ten sam port, z którego wyszło zapytanie. Teoretycznie, serwer zapytujący ma do dyspozycji ponad 64 tysiące portów (porty o numerach powyżej 1024), lecz praktycznie rzadko zdarza się, aby serwery DNS wykorzystywały całą tę pulę za każdym zapytaniem zmieniając port źródłowy. Często do tego celu wykorzystywany jest tylko jeden port, który zmieniany jest w chwili restartu serwera, albo nawet w ogóle.

Zatem w najgorszym wypadku atak na serwer zapytujący („zatrucie” jego pamięci fałszywymi rekordami), sprowadza się tylko do odgadnięcia „na ślepo” ID transakcji. Przy założeniu, że zaatakowany serwer obsługuje dużą liczbę klientów (np. jest to serwer dużego dostawcy Internetu), zagrożenie może być poważne. Jednak nie zaobserwowano do tej pory takich ataków na skalę masową, mimo że podobne problemy pojawiają się od wielu lat. Choć teoretycznie konsekwencje udanych ataków tego typu mogą być niezwykle groźne dla użytkowników Internetu, wygląda jednak na to, że często nie jest łatwo wykorzystać powyższe błędy.

Producenci poszczególnych serwerów DNS już zajęli się opisanym problemem, wprowadzając losowe wykorzystywanie portów źródłowych. Większość najpoważniejszych dostawców udostępniło poprawki do swojego oprogramowania, inni są w trakcie ich opracowywania. Zainteresowani administratorzy serwerów DNS powinni dalszych informacji szukać na stronach producenta.

Info:

www.us-cert.gov,

isc.sans.org