Naukowcy z Uniwersytetu Kalifornijskiego i Uniwersytetu Tsinghua odkryli serię krytycznych luk w zabezpieczeniach, które mogą prowadzić do ataków zatruwania pamięci podręcznej DNS („zanieczyszczania wpisów DNS przechowywanych w pamięci serwera”).
O bezpieczeństwie DNS pisaliśmy dużo w naszej kampanii tutaj. W dzisiejszym artykule opiszemy nową technikę ataku zwaną „atakiem SAD DNS” (skrót od Side-channel AttackeD DNS), która umożliwia złośliwemu aktorowi przeprowadzenie ataku w kanale bocznym (ang. side channel) odbywającym się poza normalnym kierunkiem zapytania DNS, przekierowując ruch pierwotnie skierowany do określonej domeny na serwer znajdujący się pod ich kontrolą.
Atak ten umożliwia podsłuchiwanie i manipulowanie komunikacją DNS. Lecz zanim przejdziemy do jego szczegółów, najpierw przedstawimy trochę teorii.
Jak wygląda ekosystem DNS?
Serwery DNS należą do jednej z kilku głównych kategorii: rekurencyjny serwer (resolver takie jak 1.1.1.1 lub 8.8.8.8), serwery nazw (takie jak serwery główne DNS lub autorytatywny DNS np. Cloudflare). Istnieją również elementy ekosystemu DNS, które działają jako „spedytorzy” (ang. forwarders), takie jak dnsmasq. W typowym wyszukiwaniu DNS te serwery DNS współpracują ze sobą, aby wykonać zadanie dostarczania adresu IP dla określonej domeny do klienta (klient jest zwykle programem tzw. sub resolverem – prostym programem rozpoznawania nazw wbudowanym w system operacyjny). Atak SAD DNS jest ukierunkowany na komunikację między rekurencyjnymi serwerami DNS a serwerami nazw.
Każdy z uczestników DNS (klient, rekurencyjny serwer DNS, serwer nazw) używa protokołu DNS do komunikacji między sobą. Większość najnowszych innowacji w DNS dotyczy ulepszenia transportu między użytkownikami i rekurencyjnymi serwerami DNS poprzez użycie w nim szyfrowania. Uaktualnianie protokołu transportowego między rekurencyjnym serwerem (resolver) i autorytatywnymi serwerami jest nieco bardziej skomplikowane, ponieważ wymaga nowego mechanizmu wykrywania, który poinstruuje rekurencyjny serwer DNS, kiedy używać (lub nie używać) bezpieczniejszego kanału komunikacji. Poza kilkoma przykładami, większość komunikacji nadal odbywa się przez UDP. Jest to główny problem, który umożliwia przeprowadzenie nowego ataku na DNS.
Atak SAD DNS
Atak SAD DNS otrzymał numer CVE-2020-25705, a jego wyniki zostały przedstawione na konferencji ACM Bezpieczeństwa Komputerów i Komunikacji (ACM CCS ’20).
Odkryty atak jest ważnym kamieniem milowy, ponieważ jest to pierwszy atak z wykorzystaniem bocznego kanału sieciowego, który można dozbroić oraz ma poważne konsekwencje dla bezpieczeństwa. Atak umożliwia atakującemu spoza ścieżką umieszczenie złośliwego rekordu DNS w pamięci podręcznej DNS.
Luka dotyczy systemów operacyjnych Linux 3.18-5.10, Windows Server 2019 (wersja 1809) i nowszych, macOS 10.15 i nowszych oraz FreeBSD 12.1.0 i nowszych.
Forwardery DNS stają się nową powierzchnią ataku
Rekurencyjne serwery DNS (resolvery) w celu poprawy wydajności odpowiedzi w sieci zazwyczaj buforują odpowiedzi na zapytania o adresy IP (posiadają zdefiniowany czas TTL). Ale ten sam mechanizm można wykorzystać do zatruwania pamięci podręcznych przez podszywanie się pod adresy IP wpisów DNS dla danej witryny i przekierowywanie użytkowników próbujących odwiedzić tę witrynę na inną wybraną przez atakującego witrynę. Skuteczność takich ataków spadła częściowo ze względu na protokoły, takie jak DNSSEC (rozszerzenia zabezpieczeń systemu nazw domen), które tworzą bezpieczny system nazw domen poprzez dodawanie podpisów kryptograficznych do istniejących rekordów DNS i obronę opartą na randomizacji, która umożliwia rekurencyjnym serwerom DNS, aby używały innego portu źródłowego i identyfikatora transakcji (TxID) dla każdego zapytania.
Zauważając, że te dwa środki łagodzące nadal są dalekie od szerokiego zastosowania z powodu „zachęt i kompatybilności”, naukowcy powiedzieli, że opracowali atak typu side-channel, który można z powodzeniem wykorzystać przeciwko najpopularniejszym stosom oprogramowania DNS, tworząc w ten sposób publiczne resolwery DNS jak Cloudflare 1.1.1.1 i Google 8.8.8.8 podatne na tego typu atak.
Nowatorski atak na kanał boczny
Atak SAD DNS działa, wykorzystując zainfekowaną maszynę w dowolnej sieci, która jest w stanie wyzwolić żądanie z usługi przesyłania dalej DNS lub rekurencyjnego serwera. Atak może być łatwy do przeprowadzenia z publicznej sieć bezprzewodowej zarządzanej przez bezprzewodowy router np. w kawiarni, centrum handlowym lub lotnisku.
Następnie wykorzystuje kanał boczny w stosie protokołów sieciowych, aby skanować i odkrywać, które porty źródłowe są używane do zainicjowania zapytania DNS, a następnie wstrzyknąć dużą liczbę sfałszowanych odpowiedzi DNS poprzez brutalne wymuszenie TxID.
Mówiąc dokładniej, badacze wykorzystali kanał używany w żądaniach nazwy domeny, aby zawęzić dokładny numer portu źródłowego, wysyłając sfałszowane pakiety UDP, każdy z innym adresem IP, do serwera ofiary i wywnioskować, czy sfałszowane sondy trafiły na właściwy port źródłowy na podstawie otrzymanych odpowiedzi ICMP (lub ich braku).
Opisywane metoda skanowania portów osiąga prędkość skanowania 1000 portów na sekundę, co łącznie zajmuje jej nieco ponad 60 sekund, aby przeglądnąć cały zakres portów (dostępnych jest 65536 portów). Gdy port źródłowy zostanie w ten sposób odgadnięty, atakujący musi jedynie wstawić złośliwy adres IP, aby przekierować ruch w witrynie i pomyślnie przeprowadzić atak polegający na zatruwaniu „zanieczyszczeniu” pamięci podręcznej DNS.
Jak można załagodzić atak SAD DNS?
Naukowcy oprócz pokazania sposobów rozszerzenia okna ataku, które umożliwia atakującemu skanowanie większej liczby portów, a także wstrzyknięcie dodatkowych fałszywych rekordów w celu zatrucia pamięci podręcznej DNS, w swoim badaniu wykazali, że ponad 34% resolverów (serwerów rekurencyjnych DNS) w Internecie jest podatnych na ataki, z czego 85% obejmują popularne usługi DNS, takie jak Google i Cloudflare.
Aby przeciwdziałać SAD DNS, naukowcy zalecają wyłączenie wychodzących odpowiedzi ICMP i bardziej agresywne ustawienie limitu czasu zapytań DNS.
Naukowcy stworzyli również narzędzie do sprawdzania serwerów DNS, które są podatne na ten atak. Ponadto grupa pracowała z zespołem ds. Bezpieczeństwa jądra Linuksa nad poprawką, która losuje globalny limit szybkości ICMP, aby wprowadzić szumy do kanału bocznego.