N

aukowcy z Uniwersytetu Tsinghua i Uniwersytetu Kalifornijskiego na tegorocznej konferencji ACM CCS przedstawili nową metodę, którą można użyć do przeprowadzania ataków polegających na zatruwaniu pamięci podręcznej DNS. Nowe odkrycie ożywia błąd z 2008 roku, który kiedyś uważano za rozwiązany na dobre. W celu zrozumienia na czym polega reinkarnacja tego ataku powróćmy do jego podstaw. DNS jest książką adresową internetu. Co się dzieje jak wpisujemy adres URL (ang. Uniform Resource Locator) np. https://nfsec.pl do przeglądarki? Przeglądarka sprawdza swoją pamięć podręczną pod kątem wpisu DNS, aby znaleźć odpowiedni adres IP witryny. Jeśli nie zostanie znaleziony kontynuuje sprawdzanie pamięci podręcznej: systemu operacyjnego, najbliższego serwera DNS (routera lub ISP). Jeśli wpis nadal nie zostanie znaleziony to serwer DNS (routera lub ISP) inicjuje zapytanie DNS w celu znalezienia adresu IP serwera obsługującego nazwę domeny (autorytatywnego) i prosi go o podanie adresu IP szukanej domeny.

Dawne czasy

W momencie załadowania przez przeglądarkę adresu – adres IP zostanie zapisany w pamięci podręcznej przeglądarki oraz pośredniczących serwerach DNS. Oznacza to, że następnym razem, gdy będziemy chcieli odwiedzić ponownie https://nfsec.pl, kolejne wyszukiwanie DNS nie będzie konieczne. Ataki polegające na zatruwaniu pamięci podręcznej DNS polegają właśnie na “zanieczyszczaniu” tej samej pamięci podręcznej istniejącej na serwerach pośredniczących (routera lub ISP). Wyobraźmy sobie, że pamięć podręczna DNS, na której nasz komputer (jako klient) polega przy wyszukiwaniu adresu IP domeny nfsec.pl zwraca fałszywy adres IP zamiast oryginalnego. Atakujący mogli siać spustoszenie w internecie poprzez ten atak – bez konieczności stosowania sztuczek phishingowych – przekierowując ofiary bez ich wiedzy na złośliwe serwery. Taki błąd odkrył badacz bezpieczeństwa Dan Kaminsky w 2008 roku.

[ Klient ] - Podaj mi adres IP nfsec.pl -> [ Serwer DNS ] -- [ Prawdziwa strona IP:Y ]
                                                 /|\
                                                  |
                                   Podaj mu fałszywy adres IP X
                                                  |
                                                  |
                                            [ Atakujący ] -- [ Złośliwa strona IP:X ]

Każdy klient (aplikacja / urządzenie) wyszukujące adres IP dowolnej domeny za pomocą DNS zawiera unikalny numer “identyfikatora transakcji” (TXID – transaction identifier) w żądaniu przesyłanym do serwera DNS. Kiedy serwer odpowiada klientowi (np. nfsec.pl ma adres IP W.X.Y.Z) powinien on zaakceptować odpowiedź jako prawidłową tylko wtedy, gdy zawiera ten sam identyfikator transakcji. Powód tego zabezpieczenia jest prosty i ma zapobiegać sytuacji opisanej powyżej: aby nieuczciwy serwer DNS nie zalewał klienta złośliwymi i nieprawidłowymi wpisami DNS zatruwającymi jego pamięć podręczną. Gdyby ta kontrola nie została wprowadzona – atakujący serwer DNS mógłby z łatwością przekazać użytkownikowi fałszywy adres IP podczas łączenia się użytkownika z witryną.

Przed 2008 rokiem rekurencyjne serwery DNS używały jednego otwartego portu (zwykle 53) do wysyłania i odbierania wiadomości od autorytatywnych serwerów nazw. Dan Kaminsky odkrył, że skoro odgadnięcie portu źródłowego nie stanowi problemu to istnieje tylko 65.536 (16-bitów) możliwych identyfikatorów transakcji do odgadnięcia. Patrząc na to odkrycie od strony brute force osoba atakująca mogła zatem wysłać wiele fałszywych (wykonać flood) odpowiedzi DNS (o ID od 0 do 65.535) w momencie, gdy rekurencyjny serwer odpytywał autorytatywny o daną domenę. Gdy złośliwa odpowiedź z prawidłowym identyfikatorem wiadomości pojawiała się przed odpowiedzią z serwera autorytatywnego dochodziło do zatrucia pamięci – i była zatruta tak długo, aż wygasł jej TTL (ang. Time to Live). W wyniku tego ataku resolvery DNS zaczęły stosować losowość portów źródłowych i dokładnie sprawdzać ranking bezpieczeństwa danych lądujących w pamięci podręcznej. W celu zatrucia pamięci po wprowadzeniu tego mechanizmu sfałszowane odpowiedzi musiałyby nie tylko odgadnąć identyfikator, ale także port źródłowy – zwiększając pulę do zgadnięcia z dziesiątek tysięcy do ponad biliona. To sprawiło, że atak przestał być praktycznie wykonywalny. IETF opublikował RFC 5452 o tym, jak zabezpieczyć system DNS przed tego rodzaju atakami (domeny podpisane cyfrowo mechanizmem DNSSEC [ang. Domain Name System Security Extensions] są na nie odporne).

Powrót truciciela

Jednak naukowcy z Uniwersytetu Tsinghua i Uniwersytetu Kalifornijskiego opublikowali metodę, która za pomocą kanału bocznego (ang. side channel) ponownie pozwala na ustalenie numeru portu źródłowego klienta DNS. W bezpieczeństwie komputerowym atakiem bocznym jest dowolny atak oparty na informacjach uzyskanych z implementacji systemu komputerowego, a nie na słabościach w samym zaimplementowanym algorytmie. Co w tym przypadku jest tym kanałem? Otóż odgadnięcie portu źródłowego staje się możliwe dzięki temu, jak jądro Linuksa obsługuje żądania ICMP (na przykład ping lub traceroute), a dokładniej mechanizm ograniczania szybkości wysyłania komunikatów ICMP. Na ironię – mechanizm ten został wprowadzony, aby zapobiec wykorzystaniu serwera jako nieświadomego uczestnika ataków odbicia (ang. reflection attack) – czyli atakujący wysyła bardzo dużo komunikatów ICMP z sfałszowanym adresem źródłowym (który jest ustawiony na IP ofiary) – nasz serwer zaczyna wysyła odpowiedzi, ale nie w stronę atakującego, a w stronę serwera ofiary. Prozaicznie można porównać to do sytuacji, w której ktoś z otwartej ręki uderzył nas w twarz, a my szybko się odwracając nie sprawdziliśmy kto to i oddaliśmy niewinnej osobie. W celu ograniczenia takich ataków limit szybkości odpowiedzi wbudowany w system Linux domyślnie posiada stałą wartość 1000 pakietów na sekundę i używa licznika do śledzenia tych żądań.

Nowa wersja ataku zatruwania pamięci DNS działa następująco:

• Serwer rekurencyjny (R-DNS) otwiera losowy port i wysyła zapytanie do serwera autorytatywnego (A-DNS) o adres danej domeny i oczekuje na odpowiedź.
• W tym momencie atakujący wysyła 1000 wiadomości sondujących różne porty do serwera R-DNS z sfałszowanym adresem źródłowym ustawionym na serwer A-DNS. W przypadku, gdy w sondowanym zestawie atakujący nie trafił na losowo otwarty port – serwer R-DNS wyślę taką samą ilość odpowiedzi ICMP typu 3 z kodem numer 3 – port niedostępny (ang. port unreachable) do serwera A-DNS (nie atakującego). Jak więc atakujący dowie się o otwartym porcie lub nie?
• Atakujący może teraz wysłać dodatkowy komunikat weryfikacyjny z własnego adresu i obserwować, czy odpowiedź ICMP wróci do niego, czy nie. Jeśli nie wróci – oznacza to, że wszystkie 1000 sondowanych portów jest zamkniętych – bo licznik dla limitu został osiągnięty na odpowiedzi o zamkniętych portach. Jeśli wróci – oznacza to, że w zestawie był co najmniej jeden otwarty port dla którego nie została wysłana wiadomość ICMP i licznik nie osiągnął limitu.
• Korzystając z tego podejścia atakujący może teraz podmienić sondowany zestaw wiadomości na te, które próbują odgadnąć identyfikator wiadomości (podobnie jak w przypadku oryginalnego ataku Kaminskiego) i zacząć zalewać serwer R-DNS w celu zatrucia jego pamięci podręcznej.

Jak widzimy limit i licznik szybkości odpowiedzi komunikatów ICMP wydawał się poprawnie zaimplementowany dla ograniczenia innego ataku, dopóki nie został wykorzystany wbrew jednej z podstawowych zasad bezpieczeństwa danych: nie można pozwolić, aby prywatne informacje wpływały na publicznie dostępne metryki. Ograniczenie szybkości komunikatów ICMP z licznikiem narusza tę zasadę, ponieważ osoba atakująca może na niego wpływać zgadując, czy “tajny” numer portu jest otwarty, czy nie.

Atak ten został nazwany SAD DNS (ang. Side-channel AttackeD DNS) – CVE-2020-25705. Podatnych jest na niego wiele rodzajów serwerów DNS (np. BIND, Unbound, dnsmasq) pełniących rolę serwerów rekursywnych jak i spedytorów (ang. forwarders) z funkcją zapamiętywania odpowiedzi DNS. Ze względu na stały licznik system Linux jest podatny od wersji 3.18 do 5.9.

Obrona

Jednym z rozwiązań jest zniszczenie powodu reanimacji ataku – czyli kanału bocznego np. poprzez dodanie losowości dla wartości limitu szybkości komunikatów ICMP: łatka dla Linuksa została już wprowadzona do wydania 5.10 i zostanie przeniesiona do innych stabilnych wersji (warto obserwować CVE dla używanej dystrybucji: RedHat, Ubuntu itd.). Można ją również zaimplementować poprzez prosty skrypt:

#!/usr/bin/env bash 
while :
do
     echo $((500 + ${RANDOM} % 1500)) > /proc/sys/net/ipv4/icmp_ratelimit
     echo $((500 + ${RANDOM} % 1500)) > /proc/sys/net/ipv6/icmp/ratelimit
     sleep .95
done

Który będzie uruchamiany z poziomu daemona cron:

# Skopiuj do /etc/cron.d/icmp_ratelimit
*/10 * * * * flock -xn /var/run/.icmpratelimit -c /usr/local/sbin/icmp_ratelimit.sh

To samo możemy wykonać z poziomu iptables:

iptables -I OUTPUT -p icmp -m icmp --icmp-type port-unreachable -m limit --limit \
$((500 + ${RANDOM} % 1500))/second -j ACCEPT

Od strony protokołu DNS możemy: zaimplementować DNSSEC (DoH jest podatne na ten atak); możemy zmniejszyć limit czasu zapytania (ang. DNS query timeout) w celu zminimalizowania okna ataku; wykorzystać kodowanie bitu 0x20 i ciasteczka DNS.

Podsumowanie

Mimo, że SAD DNS otwiera stare rany DNS, należy zauważyć że ta technika też ma swoje ograniczenia. Na przykład rekursywne serwery DNS z “jakimś tam” ruchem sieciowym, co chwilę otwierają i zamykają porty, co wprowadza wiele wyników fałszywie pozytywnych dla atakującego – może zacząć zgadywać identyfikatory transakcji nie dla tego portu, co powinien. Dochodzi do tego również wystarczająco duży limit szybkości wychodzenia komunikatów ICMP o portach, aby móc skanować ich zakresy z rozsądną szybkością. Szybkość skanowania ma tutaj kluczowe znaczenie, ponieważ musi zostać zakończona, gdy zapytanie do serwera nazw ofiary jest nadal w toku.

Więcej informacji: DNS cache poisoning attacks return due to Linux weakness, SAD DNS Explained