Jeśli podczas surfowania w Internecie natkniemy się na witryny kuszące tytułową frazą, radzimy nie cieszyć się przedwcześnie. Najprawdopodobniej trafiliśmy na kolejną stronę, która w bardziej bądź mniej sprytny sposób próbuje wyłudzić od nas pieniądze. W tym przypadku jest to skłonienie nas do wykupienia usługi dostępu do „super gadżetów: gier java, dzwonków tapet i innych”. Płatność odbywa się za pomocą SMS Premium (2,46 PLN/SMS – 4 SMS/tydzień lub 7,38 PLN/SMS – 1 SMS/tydzień). Organizatorem „promocji” jest firma holenderska. Aby zobrazować rząd wielkości korzyści majątkowych pochodzących z nieuwagi internautów, można przytoczyć informację prasową o przejęciu wspomnianej spółki przez spółkę niemiecką (obie działające w tym samym obszarze rynku). Wartość przejęcia: 20 milionów euro w gotówce oraz 1,9 miliona euro w nowowyemitowanych akcjach a także spłata długu w wysokości 9,8 miliona euro. Przewidywany roczny przychód nowej spółki – 95 milionów euro, zysk EBITA – 18 milionów euro.

(więcej…)

Bez wątpienia DNS jest jedną z najważniejszych usług w internetowym ekosystemie, zarówno dla zwykłych użytkowników, firm jak i przestępców. Paradoksalnie, przezroczystość i wszechobecność DNSu powoduje, że wielu administratorów nie zdaje sobie sprawy jak poważne konsekwencje mogą nieść za sobą udane ataki na DNS. Nie chodzi tutaj o podatności w samym protokole (jak na przykład ta opisywana przez nas wcześniej), ale o całkowite przejęcie kontroli nad delegacją domeny bez wykorzystywania jakichkolwiek luk w oprogramowaniu. Jest to szczególnie ważne dla firm rozpowszechniających swoje produkty czy usługi w internecie – utrata wizerunku może kosztować gigantyczne sumy. Na nic zdadzą się firewalle, systemy IDS/IPS, biometryczna kontrola dostępu w siedzibie firmy, jeśli przestępca po prostu zaloguje się  do panelu rejestratora korzystając z wykradzionego lub odgadniętego hasła i zmieni delegację domeny (lub poszczególne wpisy). “Domain hijacking” dotknął między innymi Twittera, Secunię, ICANN, IANA i innych. Zazwyczaj efektem takiego działania jest podmiana strony WWW, ale bywają też ataki bardziej subtelne. Zobaczmy co może się stać w wypadku np. sklepu internetowego zaatakowanego przez kogoś, kto chce uzyskać korzyści finansowe:

• przestępca kontrolujący czyjąś domenę może zdobyć jej prawidłowy certyfikat SSL (korzystając z usług legalnych firm wydających certyfikaty na podstawie wpisu do DNS),

• może czytać pocztę kierowaną do użytkowników danej domeny, w szczególności odzyskać ich hasła do innych serwisów (np. poprzez użycie linka “resetuj hasło”),

• może dystrybuować złośliwe oprogramowanie wykorzystując zaufanie do marki ofiary,

• może zdobyć loginy, hasła, adresy email użytkowników (np. klientów) serwisów w przejętej domenie, co może doprowadzić do następnych włamań,

• może wyłudzać pieniądze – np. podstawiając fałszywy sklep.

Oczywiście możliwych scenariuszy jest dużo więcej, przestępcy z dnia na dzień stają się coraz bardziej kreatywni.

Sama konstrukcja protokołu DNS (mechanizm TTL) powoduje, że nawet gdy uda się szybko odzyskać kontrolę nad domeną i przywrócić prawidłowe wpisy, te stworzone przez przestępców mogą pozostać w wielu miejscach sieci (serwery cache) przez wiele dni.

Dlatego bardzo ważne jest by w panelu rejestratora domenowego używać mocnych, niesłownikowych haseł. Jeśli rejestrator oferuje dodatkowe zabezpieczenia (np. potwierdzenie operacji emailem) należy z nich korzystać. Nieodzowne jest też ciągłe monitorowanie konfiguracji domen i raportowanie wszelkich zmian.

Od początku stycznia grupa serwerów DNS zalewana jest pytaniami ze sfałszowanymi adresami IP nadawcy. Echa tych ataków widziane są w systemie wczesnego wykrywania zagrożeń sieciowych ARAKIS. W ruchu sieciowym pozyskanym do tej pory zidentyfikowaliśmy ok. 20 atakowanych serwerów DNS należących m.in. do Dynamic Network Services (znany jako DynDNS), Verisign, GoDaddy, eNom, Hurricane Electric, TelecityGroup, czy SoftLayer Technologies.

(więcej…)

W dniu 28 lipca 2009 Micha Krause zgłosił błąd dotyczący popularnego serwera DNS — BIND9, który okazał się być podatny na zdalny atak typu DoS (Denial-of-Service).

Wykorzystanie luki umożliwia wyłączenie serwera BIND9 za pomocą pojedynczego pakietu UDP, o ile atakowany serwer DNS jest serwerem typu master przynajmniej dla jednej ze stref. Należy przy tym pamiętać, że zgodnie z RFC 1912 Common DNS Operational and Configuration Errors każdy serwer DNS powinien być podstawowym serwerem dla stref specjalnych, typu localhost, 0.0.127.in-addr.arpa, 255.in-addr.arpa, 0.in-addr.arpa.

Atak polega na wykorzystaniu mechanizmu aktualizacji DNS opisanego w RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE). Atakujący wysyła spreparowane zapytanie do serwera DNS z ustawioną wartością opcode na 5 (UPDATE) oraz rekordem ANY w sekcji Prerequisite. Przetworzenie takiego pakietu skutkuje niespełnioną asercją w funkcji dns_db_findrdataset(), i w efekcie kończy się wyjściem serwera BIND.

Warto w tym miejscu dodać, że w sieci pojawiły się rady, jak zablokować tego typu ataki przy pomocy prostej reguły w iptables. Niestety, są one nieskuteczne ponieważ RFC 2136 2.1 stanowi, że tego typu złośliwe zapytanie może zostać wysłane również przy użyciu protokołu TCP. Zalecanym rozwiązaniem jest aktualizacja serwera BIND do najnowszej wersji. Ostatecznie można zdecydować się również na blokowanie komunikacji do serwera master, zostawiając dostępne jedynie serwery slave. Warto tutaj nadmienić, że wyłączenie funkcji dynamicznej aktualizacji (np. poprzez opcję allow-update) – nie chroni przed opisywanym atakiem. (więcej…)

Przedwczoraj w sieci pojawił się exploit wykorzystujący błędy w DNS, o których pisaliśmy 9-tego lipca (Błędy w DNS dotyczące większości producentów).
Exploit pojawił się kilka dni po “wycieku” szczegółów błędów odkrytych przez Dana Kaminsky’ego. Większość producentów serwerów DNS udostępniła już poprawki (należy sprawdzić na stronie dostawcy). Dodatkowo (w miarę możliwości) warto ograniczyć dostęp do DNSu tylko do zaufanych klas adresów, wprowadzić zabezpieczenia przed spoofingiem na granicy sieci, oraz wyłączyć rekursywne odpowiedzi na pytania pochodzące z niezaufanych źródeł.

Jeżeli podjęcie powyższych kroków nie jest w tej chwili możliwe, administratorzy powinni co najmniej tymczasowo przekierować zapytania do DNSu, o którym wiadomo, że nie jest podatny (na przykład serwery OpenDNS).

Ostatnio w Internecie pojawiły się informacje o wykryciu bardzo groźnego błędu w DNS. W rzeczywistości są to pewne niedociągnięcia w protokole DNS, a także w popularnych jego implementacjach, które potencjalnie mogą zostać wykorzystane do ataku na serwery DNS. Atak ten może polegać na tzw. zatruwaniu pamięci serwera DNS (ang. DNS cache poisoning). W rezultacie serwer DNS odpytujący rekursywnie inny serwer DNS może zostać oszukany przez atakującego (który podszywa się pod serwer odpytywany), przez co klientowi zwracany jest fałszywy adres IP. Dzięki temu na przykład chcąc wejść na jakąś stronę internetową, zostaniemy skierowani na zupełnie inny serwer WWW. Może to być wykorzystywane np. do infekowania złośliwym oprogramowaniem ludzi surfujących po Internecie, lub wyłudzania od nich loginów i haseł do ich kont bankowych.

Pierwszym problemem jest sam protokół DNS, który wykorzystuje w komunikacji protokół UDP. Ponieważ taka komunikacja odbywa się bez połączenia, trudniej jest zweryfikować autentyczność serwera, z którego odbierane są dane (atakujący może się pod niego podszyć).

Ponadto, każde zapytanie zawiera potencjalnie unikalny losowo generowany 16-bitowy numer ID, który musi znaleźć się w odpowiedzi. Atakujący, chcąc podszyć się pod pytany serwer i sfałszować odpowiedź, musi zgadnąć ten numer. Niestety niektóre implementacje mogą używać słabych pod względem unikalności/losowości numerów ID, przez co atakujący może łatwiej i szybciej go zgadnąć.

Kolejnym problemem może być numer portu, z którego wysyłane jest zapytanie. Aby wymiana informacji przebiegła pomyślnie, odpowiedź musi zostać przesłana serwerowi zapytującemu na ten sam port, z którego wyszło zapytanie. Teoretycznie, serwer zapytujący ma do dyspozycji ponad 64 tysiące portów (porty o numerach powyżej 1024), lecz praktycznie rzadko zdarza się, aby serwery DNS wykorzystywały całą tę pulę za każdym zapytaniem zmieniając port źródłowy. Często do tego celu wykorzystywany jest tylko jeden port, który zmieniany jest w chwili restartu serwera, albo nawet w ogóle.

Zatem w najgorszym wypadku atak na serwer zapytujący („zatrucie” jego pamięci fałszywymi rekordami), sprowadza się tylko do odgadnięcia „na ślepo” ID transakcji. Przy założeniu, że zaatakowany serwer obsługuje dużą liczbę klientów (np. jest to serwer dużego dostawcy Internetu), zagrożenie może być poważne. Jednak nie zaobserwowano do tej pory takich ataków na skalę masową, mimo że podobne problemy pojawiają się od wielu lat. Choć teoretycznie konsekwencje udanych ataków tego typu mogą być niezwykle groźne dla użytkowników Internetu, wygląda jednak na to, że często nie jest łatwo wykorzystać powyższe błędy.

Producenci poszczególnych serwerów DNS już zajęli się opisanym problemem, wprowadzając losowe wykorzystywanie portów źródłowych. Większość najpoważniejszych dostawców udostępniło poprawki do swojego oprogramowania, inni są w trakcie ich opracowywania. Zainteresowani administratorzy serwerów DNS powinni dalszych informacji szukać na stronach producenta.

Info:

www.us-cert.gov,

isc.sans.org