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…)

Odkryto poważny błąd implementacyjny w pakiecie OpenSSL wykorzystywanym przez system Debian i dystrybucje na nim oparte (m.in. Ubuntu i Knoppix), który powoduje podczas generowania kluczy korzystanie z niewielkiego zbioru liczb pseudolosowych.

Podatność jest dziedziczona przez wszystkie aplikacje korzystające z podatnej wersji OpenSSLa (m.in. OpenSSH). Błąd ten został zgłoszony 13-tego maja tego roku. Powstał w wyniku usunięcia z kodu źródłowego pakietu małego fragmentu, co spowodowało osłabienie generatora liczb pseudolosowych. W efekcie jedyną zmienną wykorzystywaną w procesie generowania klucza, którą można uznać za “losową”, jest numer identyfikacyjny procesu (PID). Gwoli przypomnienia: w systemach linuksowych maksymalny numer procesu, to 32 768, co właściwie sprowadza do tej liczby maksymalną ilość wygenerowanych niepowtarzalnych kluczy przy takich samych parametrach wejściowych. Co więcej, w większości dystrybucjach debianowskich przydzielanie numeru PID odbywa się sekwencyjnie, co dodatkowo powoduje, że liczby pseudolosowe wykorzystywanych do generowania kluczy są jeszcze mniej “losowe”.

To wszystko sprawia, że potencjalna próba złamania klucza metodą brute-force może trwać znacznie krócej, niż zakładano (zmniejszenie potrzebnego do tego czasu do wartości akceptowalnej dla atakującego). Złamany klucz/certyfikat może być wykorzystany do podszycia się lub ataku typu man-in-the-middle na sesję SSH oraz SSL, co jest szczególnie groźne w kontekście bankowości elektronicznej, handlu elektronicznego, oraz innych serwisów WWW korzystających z połączeń szyfrowanych (HTTPS).

Wszystkie klucze SSH i SSL wygenerowane po wrześniu 2006 roku z użyciem pakietu OpenSSL wchodzącego w skład systemów opartych na dystrybucji Debiana mogą być podatne na złamanie. Zaleca się wygenerowanie wszystkich kluczy/certyfikatów na nowo. Należy pamiętać, że istotny jest system na którym został wygenerowany klucz, a nie system który go wykorzystuje. Może więc się zdarzyć, że podatny klucz będzie używany przez maszynę, na której nie ma ani Debiana, ani OpenSSL.

Poniżej przydatne narzędzie do testowania podatności kluczy:

• security.debian.org

Dostępne są już łaty do pobrania z oficjalnej strony Debiana:

• OpenSSL
• OpenSSH
• Można także skorzystać z menedżera pakietów apt-get

Lista dystrybucji linuksowych opartych na Debianie:

• Wikipedia (angielska)

Źródła:

• lists.debian.org
• Debian Security Advisory