DNS cache poisoning

DNS cache poisoning (zatruwanie pamięci podręcznej DNS) to atak, w którym napastnik wprowadza sfałszowane odpowiedzi do pamięci podręcznej rekurencyjnego serwera DNS. RFC 5452 opisuje skutek wprost: oszukany serwer buforujący powtarza przyjęte błędnie dane i kieruje swoich klientów do niewłaściwych, być może złośliwych serwerów ^[1]. CERT/CC ujmuje to podobnie: atakujący może sprawić, że klienci serwera nazw łączą się z niewłaściwymi hostami dla wybranych usług ^[2]. Niebezpiecznik wymienia DNS cache poisoning jako pierwszy z trzech sposobów ataku na DNS, obok włamania na serwer autorytatywny i przejęcia konta u rejestratora ^[4].

Jak działa

Resolver przyjmuje odpowiedź tylko wtedy, gdy spełnia ona cztery warunki: sekcja pytania odpowiada oczekującemu zapytaniu, pole ID zgadza się z ID pytania, odpowiedź przychodzi z adresu, na który wysłano pytanie, i dociera na ten sam adres i port, z którego pytanie wyszło ^[1]. Zwykle akceptowana jest pierwsza odpowiedź spełniająca te warunki ^[1]. Atakujący musi więc zgadnąć brakujące wartości i dostarczyć fałszywą odpowiedź, zanim dotrze prawdziwa.

Pole ID ma 16 bitów, więc przy pełnym wykorzystaniu wymaga średnio 32768 prób odgadnięcia; RFC odnotowuje doniesienia o implementacjach używających tylko 14 bitów, co obniża tę liczbę do 8192 ^[1]. Okno czasowe ataku RFC szacuje na rząd 100 ms, zależnie od odległości do prawdziwego serwera autorytatywnego ^[1]. Krótki TTL rekordu częściej otwiera nowe okno, co czyni podszywanie się łatwiejszym ^[1]. RFC podaje przykładowe wyliczenia: przy TTL 3600 sekund atakujący wysyłający 7000 fałszywych pakietów na sekundę ma 10% szans na podmianę rekordu w ciągu pierwszej doby i 50% po tygodniu; przy TTL 60 sekund próg 10% osiąga po 24 minutach, a 90% po około 9 godzinach ^[1].

RYS. 1Zatrucie cache resolvera

Zapora sieciowa nie chroni przed dopasowaniem adresu źródłowego, bo przepuszcza odpowiedzi, które wyglądają na pochodzące z właściwego adresu ^[1]. Dlatego zapora sieciowa (firewall) nie jest tu obroną.

Odmiany

Atak urodzinowy korzysta z tego, że fałszywe dane są dopasowywane do wielu oczekujących zapytań jednocześnie ^[1]. CERT/CC wskazuje trzy źródła słabości: za małą przestrzeń identyfikatorów, wiele jednoczesnych zapytań o to samo oraz stały port źródłowy ^[2].

DNS cache poisoning różni się od przejęcia DNS (DNS hijacking), w którym napastnik zmienia strefę u rejestratora albo na serwerze autorytatywnym, i od web cache poisoning, który dotyczy pamięci podręcznej HTTP, a nie DNS. Skutkiem wszystkich trzech bywa pharming, czyli kierowanie ofiary na fałszywą stronę mimo wpisania poprawnego adresu.

W WordPressie

Zatruty resolver nie zmienia plików strony. Szkoda powstaje po drodze, w dwóch miejscach.

Po stronie odwiedzających. Jeśli zatruto resolver używany przez klientów sieci, wpisanie adresu sklepu na WordPressie może prowadzić na serwer atakującego, który podsuwa kopię formularza logowania albo płatności ^[2]. Taką podmianę utrudnia TLS z certyfikatem SSL/TLS: fałszywy serwer musi okazać certyfikat dla tej domeny, a nagłówek HSTS (HTTP Strict Transport Security) nie pozwala przeglądarce przejść na nieszyfrowane HTTP.

Po stronie serwera. WordPress sam wykonuje połączenia wychodzące, między innymi pobierając aktualizacje. Od wersji 5.2 aktualizacje rdzenia są podpisywane kryptograficznie kluczem przechowywanym offline, a witryna weryfikuje podpis przed ich zastosowaniem ^[5]. Podpis to Ed25519 skrótu SHA384 zawartości pliku ^[5]. Zgodnie z zapowiedzią zespołu rdzenia strona ma pozostać bezpieczna nawet wtedy, gdy serwery wordpress.org zostaną zhakowane ^[5]. Podpis cyfrowy chroni więc aktualizację rdzenia WordPressa także przed podstawionym serwerem. Wpis zespołu rdzenia opisuje podpisywanie aktualizacji rdzenia ^[5].

Jak się bronić

RFC 5452 wymaga, by resolver używał nieprzewidywalnego portu źródłowego z zakresu dostępnych portów ^[1]. Losowy port działa jak dodatkowe pole ID, zawierające do 16 bitów ^[1]. CERT/CC zalecał także ograniczenie rekurencji do zaufanych klientów, filtrowanie ruchu z podszytymi adresami i lokalne resolvery buforujące ^[2].

Te środki podnoszą koszt ataku, ale go nie wykluczają. CERT/CC podkreśla, że bez zmian w samym protokole, takich jak te wprowadzane przez DNSSEC, nie da się całkowicie zapobiec zatruwaniu cache ^[2]. DNSSEC dodaje do DNS uwierzytelnianie pochodzenia danych i ich integralność ^[3], więc walidujący resolver odrzuci odpowiedź bez poprawnego podpisu. RFC 5452 zauważa jednak, że nawet zabezpieczony kryptograficznie DNS zyskuje na zdolności do szybkiego odrzucania fałszywych odpowiedzi ^[1].

Dla właściciela strony praktyczne kroki to podpisanie strefy domeny przez DNSSEC u operatora DNS, wymuszenie HTTPS z HSTS i ochrona konta u rejestratora przez uwierzytelnianie wieloskładnikowe (MFA), bo przejęcie konta jest równie skuteczną drogą przekierowania ruchu ^[4].

Historia i przykłady

8 lipca 2008 roku CERT/CC opublikował notatkę VU#800113 o podatności wielu implementacji DNS na zatruwanie cache; nadano jej identyfikator CVE-2008-1447 ^[2]. Skuteczność i praktyczność tych ataków wykazał Dan Kaminsky z firmy IOActive ^[2]. W lipcu i sierpniu 2008 roku kolejni producenci serwerów DNS wydawali poprawki ^[2]. W styczniu 2009 roku IETF opublikował RFC 5452 z wymaganiami dla resolverów ^[1].

W sierpniu 2013 roku domeny Twittera i New York Timesa przejęto inną metodą: przez konto u rejestratora i zmianę rekordów NS ^[4]. Przykład pokazuje, że obrona przed DNS cache poisoning nie zastępuje ochrony konta domeny.