Ataki DDoS II poł. 2011

Przeczytaj także: Zagrożenia internetowe III kw. 2011

Niektórzy producenci oprogramowania nie dostrzegają poważnego problemu w powyższej metodzie ataku. Jeżeli opcja renegocjacji SSL nie może zostać całkowicie wyłączona, zalecają ustawienie reguł ad-hoc w celu przerwania połączeń z klientami, którzy żądają renegocjacji SSL więcej razy niż wynosi limit w określonym przedziale czasowym.

Twórcy programu utrzymują, że nawet jeżeli serwer nie obsługuje renegocjacji SSL, wciąż może zostać zaatakowany przy użyciu zmodyfikowanej wersji ich programu. W tym przypadku duża liczba połączeń TCP jest ustanawiana dla każdego nowego SSL handshaking; jednak skuteczny atak może wymagać większej liczby botów.

Autorzy utrzymują, że opublikowali to narzędzie, aby zwrócić uwagę na „wątpliwe bezpieczeństwo SSL". Oto, co piszą na swoim blogu: „Branża powinna podjąć działania w celu rozwiązania tego problemu, tak aby obywatele znów czuli się bezpieczni. Metoda ochrony prywatnych danych wykorzystywana przez SSL jest złożona, niepotrzebna i nieadekwatna dla 21 wieku”.

Apache Killer

W sierpniu wykryto krytyczną lukę w popularnym serwerze WWW Apache HTTPD, która pozwalała cyberprzestępcom wyczerpać zasoby serwera poprzez niewłaściwe przetwarzanie nagłówka HTTP „Range: Bytes”. Pole to pozwala klientowi na stopniowe pobieranie plików poprzez stosowanie określonych zakresów bajtów. Podczas przetwarzania dużej liczby zakresów Apache zużywa dużo pamięci, stosując do każdego zakresu kompresję zip. Może to prowadzić do awarii serwisu, chyba że konfiguracja serwera sieciowego ogranicza przydzieloną do tego procesu pamięć. Podatne na ataki wersje Apache to wersje 2.0.x, łącznie z 2.0.64 oraz 2.2.x, w tym 2.2.19.

Apache poinformował również, że atak DoS był aktywnie wykorzystywany przy użyciu szeroko rozpowszechnionego w Internecie skryptu PERL. Specjaliści ds. bezpieczeństwa zalecili, aby do momentu wypuszczenia łaty bezpieczeństwa administratorzy systemu wprowadzili określone ustawienia w konfiguracjach serwera, które pomogłyby wykryć żądania wielu zakresów, a w efekcie zignorowanie pola „Zakres” lub odrzucenie całego żądania.

Obecnie luka ta została załatana w wersjach 2.2.20 i 2.2.21; jednak wersja 2.0.65 z uaktualnieniami bezpieczeństwa nie została jeszcze opublikowana.

Podatne na ataki tablice mieszające

W 2003 roku naukowcy z Rice University opublikowali artykuł zatytułowany Denial of Service via Algorithmic Complexity Attacks, w którym opisali koncepcję ataku DoS na aplikacje wykorzystujące tablice mieszające. Chodziło o to, że jeżeli aplikacja nie wykorzystuje zrandomizowanej funkcji mieszającej w implementacji swojej tablicy mieszającej, osoba atakująca może wybrać dużą liczbę kolidujących kluczy i „przekazać” je aplikacji. W efekcie, złożoność algorytmu wykorzystywanego do wprowadzania pary „klucz-wartość” zwiększa się dziesięciokrotnie, prowadząc do zwiększonego zużycia czasu CPU. Mimo że problem ten został zgłoszony dawno temu, nikt nie opracował kodu „proof-of-concept” pokazującego praktyczne możliwości przeprowadzenia ataku. Aż do końca 2011 roku.

Podczas konferencji Chaos Congress Conference dwóch naukowców z Niemiec przedstawiło referat, w którym podjęli na nowo stary problem tablic mieszających oraz ataków DoS. W referacie opisano atak, który wykorzystuje luki w wielu językach programowania, łącznie z PHP, ASP.NET, Java, Python oraz Ruby. Wszystkie z tych platform wykorzystują podobne algorytmy mieszające, w których można znaleźć kolizje. Aby „odłączyć” serwer, osoba atakująca może wysłać żądanie POST do aplikacji sieciowej stworzone przy użyciu jednej z wymienionych wyżej technologii. Żądanie powinno zawierać specjalnie wybrane parametry dla formularza sieciowego itd., które spowodują wiele kolizji. Aplikacje sieciowe stosują z reguły tablice mieszające do przechowywania przekazywanych im parametrów. Omawiany referat opierał się na teście ataku „proof-of-concept” na podatne platformy i podawał teoretyczne i rzeczywiste czasy wymagane do przetworzenia szkodliwych żądań POST dla różnych platform. Ogólnie rzec biorąc, w zależności od platformy, konfiguracji serwera i ilości danych w żądaniu POST, jedno żądanie może angażować CPU przez czas od kilku minut do kilku godzin. W przypadku serii takich żądań osoby atakujące mogą „odłączyć” serwer wielordzeniowy lub nawet klaster serwerów.

Niemieccy naukowcy zauważyli również, że takie żądania POST do atakowanego serwera teoretycznie mogą być generowane w locie przez kod HTML lub JavaScript na stronie internetowej osoby trzeciej – tak jak w atakach XSS (cross-site scripting). W efekcie, w ataku DDoS może pośrednio uczestniczyć duża liczba użytkowników.