Ó

smego lipca 2008 roku Dan Kaminsky przedstawił poważne luki w implementacjach zabezpieczeń systemu nazw domenowych (ang. Domian Name System, DNS). Obejmują one luki wykryte w serwerach DNS BIND 8 i 9 przed wersjami 9.5.0-P1, 9.4.2-P1, oraz 9.3.5-P1; (2) Microsoft DNS w Windows 2000 SP4, XP SP2 i SP3, oraz Microsoft Server 2003 SP1 i SP2, a także prawdopodobnie w innych implementacjach, które pozwalają na sfałszowanie ruchu DNS techniką zatruwania DNS poprzez atak urodzinowy używający przekazywanych do rozpatrzenia rekordów in-bailiwick.

Jak napisał Paweł Wilk w serwisie heise online:

Procedura bailiwick checking występuje w momencie, gdy pośredniczący serwer nazw (ang. caching nameserver) przyjmuje odpowiedź na zapytanie DNS od innego serwera. Służy ona wyeliminowaniu informacji zawartych w dodatkowym rekordzie zasobów (Additional Resource Record, RR), które nie były zamawiane. Chodzi tu przede wszystkim o komunikaty niepochodzące z serwera nazw bezpośrednio odpowiedzialnego za obsługę domeny będącej przedmiotem zapytania (out of bailiwick). W ten sposób serwer zapobiega sytuacji, w której przy wywołaniu adresu www.example.com podstawione zostałyby informacje na przykład z www.noexample.com.

W połączeniu z atakiem urodzinowym napastnikowi i tak może się udać zmiana zawartości pamięci podręcznej serwera nazw. W tym celu zmusza on serwer DNS ofiary, np. za pomocą odnośników w e-mailach, do wywołania określonych adresów, np. aaa.example.com, aab.example.com, aac.example.com. Dla każdego z tych wywołań name server ofiary używa jednego identyfikatora transakcji. Im więcej takich identyfikatorów zostanie wykorzystanych, tym większe są szanse napastnika na odgadnięcie właściwej kombinacji. Do przeprowadzenia ataku potrzebna jest sfałszowana odpowiedź wyposażona w jeden z odgadniętych identyfikatorów. Prawdopodobieństwo znalezienia właściwego identyfikatora dla zapytania o www.example.com jest dość niewielkie. Napastnik może więc sobie pomóc, wprowadzając Additional Resource Record (RR) dla www.example.com z adresem IP kontrolowanego przez siebie serwera. Dzięki temu znacznie zwiększa się prawdopodobieństwo zmanipulowania pamięci cache’a, ponieważ rekord ten jest in-bailiwick.

W ten sposób specjalista od zabezpieczeń Dan Kaminsky odkrył właśnie ogólną metodę zredukowania przypadkowości generowanych liczb do tego stopnia, że możliwe jest efektywne zastosowanie ataku wymierzonego w dane pamięci podręcznej. Okazało się również, że poza atakami na rekord CNAME możliwe jest także podsunięcie serwerowi nazw odpowiedzi ze sfałszowanymi parametrami, której ten będzie używał w wywołaniach kierowanych do innych serwerów nazw. W ten sposób możliwe byłoby zmanipulowanie nie tylko jednego wpisu adresowego w pamięci podręcznej, ale i przekierowanie wszystkich kolejnych wywołań do serwera nazw kontrolowanego przez napastnika. Po odkryciu błędu w oficjalnym komunikacie CERT można przeczytać, że atakujący dzięki wykorzystaniu tej luki mógłby dowolnie przejmować kontrolę nad fragmentami Internetu i przekierowywać użytkowników do dowolnych, wrogich im miejsc. Przejmując DNS danego dostawcy Sieci, mógłby milionom jego użytkowników jednocześnie podmienić popularne wyszukiwarki, strony banków, serwisy społecznościowe na ich phishingowe odpowiedniki. Atakując korporacyjne środowiska, mógłby przechwytywać poufne informacje firm i śledzić ich biznesowe zamiary. Ja można przeczytać w serwisach informacyjnych – odkrywca luki początkowo założył, że do sfałszowania zapytań DNS tą techniką wymagane jest kilka sekund, jednak H.D. Moore (autor frameworku Metasploit) tworząc pierwsze dwa exploity wykazał, że na sfałszowanie podręcznej pamięci jednego serwera DNS potrzeba od jednej do dwóch minut. Zbigniew Jasiński specjalista ds. DNS-u w Dziale Domen NASK, znany ekspert bezpieczeństwa, specjalizujący się w systemach operacyjnych i sieciach komputerowych po trzech tygodniach od pojawienia się informacji o luce i odpowiednich łatach przeanalizował sytuację polskich serwerów DNS:

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 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…

Dane:

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

Podobne dane uzyskał austriacki CERT publikując raport, z którego wynika, że dwie trzecie providerów usług internetowych nie wprowadziło aktualizacji na swoich serwerach działających w trybie rekurencyjnym. Nałożenie odpowiednich łatek lub przeprowadzenie aktualizacji oprogramowania serwerów i resolwerów DNS wprowadza bardziej losowe wybieranie numeru portu źródłowego dla zapytań i w ten sposób utrudnia przeprowadzanie tego rodzaju ataków. W celu sprawdzenia swoich serwerów DNS wystarczy skorzystać z testu udostępnionego przez DNS OARC (ang. Domian Name System Operations, Analysis, and Research Center). W celu sprawdzenia serwera DNS, z którego aktualnie korzystamy wystarczy wydać polecenie:

dig +short porttest.dns-oarc.net TXT

Powinniśmy otrzymać wynik podobny do tego:

porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
83.8.123.49 is GREAT: 30 queries in 5.4 seconds from 30 ports with std dev 18946

Wyniki losowości doboru portów określane są za pomocą bitów Entropii. Wyniki GREAT (13.75 – 16.0 bitów) i GOOD (10.0 – 13.75 bitów) sugerują, że nasz serwer ma dużą odporność na atak zatruwania pamięci podręcznej DNS. Otrzymując wynik POOR (0 – 10.0 bitów entropii) należy jak najszybciej uaktualnić / zmienić serwer DNS. Istnieje również możliwość sprawdzenia publicznie dostępnych serwerów DNS, z których mamy zamiar skorzystać:

dig @208.67.222.222 +short porttest.dns-oarc.net TXT

Dla systemów Windows zapytania te będą przyjmowały postać:

nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net
nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net 208.67.222.222

Istnieje również możliwość wykonania testu na stronie WWW, który dodatkowo przedstawia nam graficzną interpretację losowości portów, jaką sami możemy ocenić. Podobny test (z możliwością sprawdzenia serwera pocztowego) udostępnił sam Dan Kaminsky na swoim blogu. Warto wspomnieć, że serwery dnscache (który został już kilka lat temu wyposażony w mocne mechanizmy losowego wyboru identyfikatora transakcji i numeru portu źródłowego) oraz OpenDNS bez większego wysiłku otrzymują bardzo dobry (GREAT) wynik losowości portów.

Więcej informacji: DNSSEC, djbdns, DoxPara, OpenDNS