Zatruj mi DNS: małe przypomnienie

Pozornie kwestia wydaje się prosta. DNS odpowiada za translacje nazw domen na odpowiadające im adresy IP. Atakujący stara się zmienić zawartość rekordów serwera DNS, zastępując adresy właściwe adresami prowadzącymi do niebezpiecznych (np. phishingowych) stron.

W momencie gdy internauta próbuje dostać się na bezpieczną stronę, resolwer generuje odpowiednie zapytanie i wysyła je do serwera DNS. Jednak zatruty serwer kończy transakcję, w odpowiedzi prowadząc użytkownika pod zupełnie inny adres IP, niż by należało. Tam czekają już interesujące niespodzianki – wszelkiej maści trojany, robaki i rootkity.

Jak dochodzi do zatrucia 

Błędna konfiguracja DNS, luki w oprogramowaniu – wszystko to sprawia, że serwer DNS może otrzymać dane, które nie pochodziłyby z autorytatywnych serwerów DNS. Atakujący poszukuje exploitów, które pozwoliłyby na wprowadzenie do pamięci cache serwera takich danych – jeśli mu się to uda, a serwer odpowiednio nie uwiarygodni odpowiedzi DNS, wszyscy jego użytkownicy będą przekierowywani „na manowce”.

Serwer po otrzymaniu odpowiedzi na zapytanie od innego serwera stara się wyeliminować z niego wszystkie dane, które nie byłyby zamawiane – przede wszystkim komunikaty, które nie pochodzą z serwera zajmującego się obsługą domeny, o którą pytano. Ma to uniemożliwić sytuację, w której po zapytaniu o adres www.webhosting.pl przyszłyby dane z wwwwebhosting.pl.

Atakujący z kolei próbuje zmienić zawartość cache'u serwera nazw. Wywołuje kolejne adresy – np. a.webhosting.pl, b.webhosting.pl, c.webhosting.pl – a każde z takich zapytań to kolejna transakcja, kolejny identyfikator. Więcej identyfikatorów to więcej szans na jego odgadnięcie, a do skutecznego ataku potrzebny jest choć jedno efektywne trafienie.

Serwery można zabezpieczyć

O technicznych szczegółach takiego ataku pisaliśmy już w artykule 69 procent serwerów DNS w Polsce podatnych na atak! – odsyłamy do niego zainteresowanych. Tutaj jedynie zaznaczymy, że możliwe jest odpowiednie zabezpieczenie serwerów DNS. Pomocne jest tu wyłączenie zapytań rekurencyjnych i używanie tylko zapytań iteracyjnych, a także wprowadzenie randomizacji portów.

Co różni te dwa typy zapytań? W zapytaniu rekurencyjnym serwer DNS, gdy sam nie zna odpowiedzi, to przesyła pytanie dalej – a gdy uzyska odpowiedź, to umieszcza ją w swoim cache'u, zwracając wynik do pytającego. Zapytanie iteracyjne polega na tym, że serwer, który nie zna odpowiedzi na dane pytanie, nie przesyła go dalej, lecz przesyła pytającemu adres innego serwera DNS, który powinien móc dostarczyć odpowiedzi.

Z kolei wprowadzenie randomizacji portu źródłowego w DNS sprawia, że atakujący, który próbuje wprowadzić fałszywe dane, musi odgadnąć nie tylko identyfikator transakcji, ale także port, na którym ona przebiega. Dzięki wprowadzonej do serwera DNS BIND poprawce, jest to już standardowo stosowana technika, która utrudnia (choć nie uniemożliwia) przeprowadzenie ataku. Jak widać – zabezpieczenie serwera DNS jest w zasięgu każdego (kompetentnego) administratora.

Ufaj swojemu bankowi

Czy może być lepszy cel ataku cache poisoning niż witryna bankowa? Wprowadzenie internauty na phishingową stronę może pozwolić na przechwycenie jego haseł, a co za tym idzie, wyprowadzenie z konta pieniędzy. Udało się to z bankiem Bradesco – czy nie mogłoby się udać także z którymś z polskich banków?

Sprawdziliśmy stan rzeczy za pomocą standardowego narzędzia, przygotowanego przez Internet Assigned Numbers Authority (IANA). Listę działających w Polsce banków znaleźliśmy w Wikipedii.

Nie było tak źle, jak mogliśmy się spodziewać. Największe, najpopularniejsze banki w Polsce okazały się dobrze zabezpieczone. Tuzom klasy PKO BP czy Pekao SA, trudno cokolwiek zarzucić w kwestii bezpieczeństwa. Problem zaczyna się wśród banków mniejszych.

Podczas przeprowadzonych pod koniec kwietnia br. roku testów, zidentyfikowaliśmy trzy banki, które były szeroko otwarte na atak cache-poisoning – narzędzie testujące przyznało im status Highly vulnerable. Były to:

1. Bank Gospodarstwa Krajowego (bgk.com.pl),

2. Sandander Consumer Bank (santanderconsumer.pl),

3. Sygma Bank Polska (sygmabank.pl).

Z kolei dziewięć banków zostało w teście ocenionych jako podatne – uzyskały status Vulnerable. Były to:

1. Bank Polskiej Spółdzielczości (bankbps.pl),

2. Bank BPH (bph.pl),

3. AIG Bank (aigbank.pl),

4. Bank Ochrony Środowiska (bosbank.pl),

5. Meritum Bank (meritumbank.pl),

6. Bank Rozwoju Cukrownictwa (brc.pl),

7. Dominet Bank (dominetbank.pl),

8. Fortis Bank (fortisbank.com.pl),

9. ING Bank Śląski (ingbank.pl),

10. Noble Bank (noblebank.pl).

O naszym odkryciu poinformowaliśmy w pierwszym rzędzie wszystkie rzeczone banki. Uznaliśmy, że tydzień czasu to wystarczający czas, aby jakoś zareagować. Niestety, otrzymaliśmy odpowiedź tylko z jednej instytucji – był nią Bank BPH.