Czym jest atak DDoS (cz. 2) — techniki i narzędzia

Podział ze względu na ilość atakujących urządzeń

1. Denial of Service (DoS)

DoS, w podstawowym tego słowa znaczeniu, jest atakiem polegającym na przeciążaniu zasobów wskazanego urządzenia lub na wykonaniu akcji skutkującej brakiem możliwości skorzystania z pewnych usług przez klientów ofiary. Atak DoS wykonywany jest z pojedynczego urządzenia (lub z bardzo ograniczonej liczby urządzeń).

Atak tego rodzaju może polegać np. na wysyłaniu dużej liczby zapytań wyszukiwania na forum internetowym, co spowoduje znaczny wzrost obciążenia bazy danych (procesora, dysku) odpytywanego serwera. Skutkiem ataku jest brak możliwości odwiedzenia forum przez innych internautów lub znaczne utrudnienie korzystania z serwisu (patrz też: „Layer 7 (D)DoS — atak na logikę”).

2. Distributed Denial of Service (DDoS)

DDoS to nic innego jak rozproszona wersja ataku DoS — zalewaniem  ofiary zajmuje się nie pojedyncza maszyna, a setki lub nawet tysiące urządzeń jednocześnie. Atak nadal jest skierowany na pojedyncze cele, jednak jego źródłem są urządzenia zazwyczaj kontrolowane przez crackerów poprzez złośliwe oprogramowanie.

Ze względu na ewolucję ataków odmowy dostępu (opisanej w cz. 1), obecnie praktycznie każdy atak ma charakter rozproszony, przez co DoS (uogólniając) zaczyna być synonimem DDoS.

3. Distributed Reflected Denial of Service (DRDoS) — wzmocnienie (amplifikacja) ataku

Ataki tego rodzaju wykorzystują tzw. wzmocnione odbicie (ang. reflective amplification) co powoduje zwiększenie przepustowości ataku bez znacznego zwiększania zasobów atakującego.

Jednym z pierwszych wariantów tego typu ataków był tzw. Smurf Attack, który schematycznie został przedstawiony na diagramie 1.:

Diagram 1. Przykład wzmocnienia ataku DrDoS — Smurf Attack.

Główną ideą „ataku Smerfów” jest fałszowaniu adresu źródłowego pakietów, które wysyłane są na adresy rozgłoszeniowe. Atakujący posyła pojedyncze pakiety, przykładowo żądania ICMP Echo Request, na adres broadcast, dzięki czemu urządzenie pośredniczące rozsyła żądanie do wszystkich węzłów we wskazanej domenie rozgłoszeniowej (podsieci). Rozgłaszanie stanowi tutaj  wzmocnienie (amplifikację) ataku, ponieważ atakujący, wysyłając małą liczbę pakietów, powoduje generację wielokrotnie większego ruchu.

Aby Smurf Attack odniósł skutek, pakiety nie mogą jednak krążyć po sieci w oryginalnej formie, ponieważ ostatecznie trafiłyby z powrotem do intruza, zalewając go. W tej technice atakujący kieruje ruch do wybranej maszyny (ofiary) poprzez fałszowanie pakietów IP (IP spoofing), aby pakiety wyglądały tak, jakby zostały wysłane z atakowanej maszyny. Po rozgłoszeniu „pinga”, aktywne węzły w sieci zamierzają odpowiedzieć do źródła — oryginalnie ofiary — pakietami ICMP Echo Response. Gdy adres źródłowy zostanie sfałszowany, wtedy wszystkie odpowiedzi trafią w wybrane miejsce, czyli do atakowanej maszyny.

„Atak smerfów” obecnie ma bardzo małe zastosowanie i jest możliwy do przeprowadzenia co najwyżej w słabo zabezpieczonych sieciach lokalnych, wykorzystujących najtańsze urządzenia sieciowe. Technika ta jest (prawie) całkowicie bezużyteczna poza sieciami lokalnymi, ponieważ większość urządzeń pośredniczących ISP weryfikuje adres źródłowy i docelowy przesyłanych pakietów, blokując ataki IP Spoofing, a więc w następstwie i Smurf Attack.

Współcześnie ataki wzmocnionego odbicia wykorzystują niecą inną ideę, a nawet protokoły — przykładowo protokół DNS. Ataki DNS DrDoS wykorzystują trzy słabości:

• specyfikę protokołu DNS, którego słabością jest wysyłanie dużych odpowiedzi;
• specyfikę protokołu UDP (używanego przez DNS), który nie jest tak dokładnie filtrowany przeciwko atakom IP Spoofing jak TCP. Są dwie przyczyny tej sytuacji — UDP nie musi posiadać adresu źródłowego oraz jest protokołem mniej popularnym od TCP, czyli też gorzej zabezpieczonym sprzętowo oraz programowo przez dostawców internetowych;
• ogólnodostępność serwerów DNS, co pozwala na łatwą enumeracją węzłów, które mogą służyć jako potencjalny węzeł ataku.

Amplifikacja ataku DNS DrDoS spowodowana jest odsyłaniem dużych odpowiedzi przez serwery DNS do celu, którego adres IP został sfałszowany — atakujący przesyłający sfałszowany pakiet o rozmiarze 64 bajtów może spowodować wysłanie odpowiedzi o rozmiarze 512 bajtów, co oznacza aż ośmiokrotne zwiększenie ataku.

DNS nie jest jedynym protokołem, który może zostać wykorzystany do ataków zwielokrotnionego odbicia. Zwiększenie ataku może być wykonane również z użyciem protokołów SNMP czy NTP. W pierwszym przypadku udało się wykorzystać 6-krotne wzmocnienie, w drugim nawet 200-krotne!

Błędy w konfiguracji urządzeń pośredniczących ISP oraz sama natura protokołów UDP oraz DNS powoduje, że współczesne ataki DrDoS mogą być bardzo dużym zagrożeniem. Na potwierdzenie tych faktów warto przytoczyć incydent z maja 2013 r., kiedy zanotowano próbę jednego z największych ataków DrDoS z wykorzystaniem DNS. Jego przepustowość wynosiła aż 167 Gbps (źródło)!

Co ciekawe atak ten udało się odeprzeć.

Podział ze względu na atakowaną warstwę

1. Layer 3/Layer 4 (D)DoS — ataki wolumetryczne

Ataki te skupiają się na zalewaniu pakietami lub datagramami, czyli wykorzystują głównie warstwę sieciową lub transportową modelu ISO/OSI (warstwę 3. lub 4.). Ataki wolumetryczne polegają na zalewaniu celu jak największą liczbą pakietów ICMP, SYN TCP lub datagramów UDP. Są to jedne z najprostszych ataków, co pozwala na ich łatwe przeprowadzenie z wykorzystaniem botnetów. Co gorsza, są to jedne z trudniejszych ataków do odparcia, jeśli liczba atakujących urządzeń jest bardzo duża.

Historycznie ciekawym atakiem sieciowym był atak pingu śmierci (ang. Ping of Death), który polegał na wysłaniu do ofiary pakietu ICMP o rozmiarze powyżej 65 535 bajtów (przykładowo używając komendy ping -l 65510 adres_ofiary, powodującej wysłanie pakietu o rozmiarze 65 538 bajtów). Niepoprawna implementacja stosu TCP/IP w starych systemach operacyjnych, w szczególności w Microsoft Windows 95 powodowała całkowite zawieszenie systemu parsującego pakiet.

Wszystkie współczesne systemy są odporne na atak Ping of Death, jednak warto zaznaczyć, że wykorzystywanie szczegółów implementacyjnych stosu TCP/IP było niegdyś bardzo popularne. W wyszukiwaniu błędów w takich implementacjach, szczególnie przydatna okazuje się metoda fuzzingu (o której można przeczytać w dwóch artykułach dotyczących narzędzia Scapy). Fuzzing do dnia dzisiejszego ułatwia znajdowanie podobnych luk, w szczególności w obsłudze protokołów parsowanych przez sprzęt sieciowy kiepskiej jakości — czyli w najtańszych switchach lub routerach nieznanych firm.

Kolejną techniką często wykorzystywaną przez napastników jest fragmentacja pakietów IP. „Fragmentation Attacks” wykorzystują cechę dzielenia dużych pakietów IP, które ostatecznie muszą być połączone przez stos sieciowy atakowanego systemu. Scalanie pakietów zajmuje pewne zasoby procesora, jest to więc dobry „dodatek” to innych metod ataku. Fragmentacja pakietów jest też interesująca z innego powodu — odpowiednio wykorzystana pozwala omijać sygnatury systemów IDS/IPS, czyli jedną z głównych warstw zabezpieczeń sieciowych. Fragmentacja pakietów była również używana w przeszłości w eksploitach takich jak: Teardrop, Bonk, Boink, NewTear, Nestea, które wykorzystywały cechę „nakładania się” fragmentów pakietów, co powodowało błędy w systemach operacyjnych — eksploity te wykorzystywały więc ideę podobną do ataku Ping of Death.

2. Layer 7 (D)DoS — atak na logikę

Celem tej rodziny ataków nie jest infrastruktura sieciowa, a sama aplikacja (usługa), która stanowi ostatnią (7.) warstwę w modelu OSI/ISO.

Przed przeprowadzeniem samego ataku L7 napastnik musi przeanalizować aplikację pod kątem czasów odpowiedzi. Celem jest znalezienie „wąskich gardeł” aplikacji, czyli akcji, które w szczególny sposób obciążają procesor, pamięć, dysk, sieć lub inne zasoby bądź usługi. Po enumeracji wąskich gardeł napastnik rozpoczyna klasyczne zalewanie, tym razem jednak zapytaniami do aplikacji (np. HTTP POST), których celem jest nie tyle wyczerpanie przepustowości serwera, co wyczerpanie innych zasobów, np. czasu procesora.

Zakładając, że usługą jest web aplikacja (np. forum internetowe), atakujący może wykonać wiele operacji wyszukiwania, które w dużym stopniu obciążają: bazę danych, pamięć oraz dysk twardy. Kilka równoległych prób wykonania takiej czynności może skutecznie zablokować możliwość korzystania z forum. Innym ciekawym miejscem ataku mogą być ekrany logowania, które wykorzystują — niestety ironicznie — bezpieczne funkcje KDF (ang. key derivated functions, np. BCrypt) do obliczania kryptograficznego skrótu hasła. Gdy formularz logowania nie jest zabezpieczony przed wielokrotną próbą logowania, atak wysyłający wiele prób logowania będzie skutkował wielokrotnym obliczaniem skrótu KDF, co zgodnie z założeniami funkcji, jest operacją bardzo kosztowną obliczeniowo. Wiele serwerów można skrajnie obciążyć, wysyłając tysiące danych uwierzytelniających (dosłownie z kilku maszyn).

Innym przykład ataku L7 (chociaż numer warstwy nie jest tutaj już taki jednoznaczny) polega na wykorzystaniu zbyt dokładnego, nierozproszonego monitoringu. Gdy na jednej maszynie uruchomione jest zbyt wiele usług zapisujących szczegółowe logi — serwera aplikacji, interpretera języka web aplikacji, dziennika systemowego, zapory przeciwogniowej — wtedy nawet proste ataki DoS powodują nie tyle wyczerpanie dostępnego łącza, co transferu operacji dyskowych, a nawet samego czasu procesora. Skutkuje to oczywiście brakiem możliwości obsłużenia logiki aplikacji, do której łączą się klienci.

Kolejnym rodzajem ataku na warstwę aplikacji jest atak Slowloris, wykorzystujący słabości niektórych serwerów web aplikacji, które w niezbyt bezpieczny sposób zarządzają wątkami oraz gniazdami sieciowymi. Na atak ten szczególnie wrażliwy jest serwer Apache(1.x, 2.x) (w odróżnieniu od IIS czy nginx).

Atak Slowloris polega na wysyłaniu częściowych zapytań HTTP do serwera aplikacji, które mają utrzymać sesję oraz licznik limitu czasu odpowiedzi niedokończonego zapytania HTTP. Prawidłowo skonstruowane zapytanie HTTP posiada:

• nagłówki (GET /, Host, User-Agent…),
• pustą linię (CRLF),
• treść (np. „content” zapytania POST) lub pustą linię, gdy nie ma treści.

Częściowe zapytanie Slowloris posiada wyłącznie:

• nagłówek oraz
• pustą linię.

Brakuje więc linii zawierającej treść zapytania (lub informacji o braku treści). Treść ta zostaje przysyłana, w małych częściach, po dłuższym czasie. Przykładowa treść żądania HTTP w ataku Slowloris wygląda następująco:

"GET /$rand HTTP/1.1\r\n"

. "Host: $sendhost\r\n"

. "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n"

. "Content-Length: 42\r\n";

Powyższe zapytanie przez niektóre serwery web aplikacji zostanie zakolejkowane w wątku, co zablokuje go na pewien czas, wraz z gniazdem sieciowym. Czas blokady w domyślnych konfiguracjach może wynosić nawet 300 sekund, więc wysyłając niekompletne zapytania HTTP można łatwo unieruchomić serwer ze względu na brak wolnych wątków czy gniazd sieciowych do obsługi innych żądań. Atak Slowloris na domyślne instancje serwerów Apache jest na tyle skuteczny, że potrafi w kilka sekund całkowicie wyłączyć je dla innych klientów i to w zasadzie niezależnie od parametrów serwera!

Slowloris jest atakiem niezwykle niebezpiecznym, ponieważ atakujący przesyła małą liczbę pakietów do celu (w porównaniu z innymi metodami DoS). Zapytania Slowlorisa nie są też wykrywane przez systemy IDS/IPS, ponieważ są w praktyce poprawnymi, niezłośliwymi zapytaniami HTTP.

Jak widać, ataki na warstwę aplikacji są bardzo trudne do wykrycia oraz zapobiegania, ponieważ trudno je odróżnić od ruchu zwykłych klientów korzystających z usług. Samo wykrycie złośliwych zapytań może być skomplikowane, ponieważ wcale nie muszą one zalewać systemu w takiej ilości, jak w atakach L3/L4. Co gorsza, atakujący w łatwy sposób może modyfikować sygnaturę ataku, czyli zapytanie do aplikacji, i ponownie obciążyć zasoby.

DoS warstwy aplikacji wymaga więc większego przygotowania niż atak wolumetryczny skierowany na warstwę 3. i 4., jednak dalej są to techniki proste do wykonania — przez co są bardzo niebezpieczne.

Narzędzia do testów

Istnieje niezliczona liczba narzędzi do testowania ataków DoS. Aby rozpocząć badanie swoich systemów przeciwko skomplikowanym atakom DoS, warto zapoznać się z podstawowymi narzędziami, które w łatwy sposób potrafią pokazać skalę problemu.

Omówmy kilka prostych programów służących do przeprowadzania ataków odmowy dostępu do usługi.

1. LOIC (Low Orbit Ion Canon)

Proste, jednak niezwykle potężne narzędzie służące do zalewania datagramami UDP, TCP oraz żądaniami HTTP. LOIC został napisany w języku C#, więc przeznaczony jest dla systemów Windows. Istnieją jednak odmiany tego narzędzia, które potrafią przeprowadzać atak bezpośrednio przez przeglądarkę internetową.

LOIC bardzo mocno zyskał na popularności dzięki grupie Anonymous, która namawiała internautów do używania go podczas ataków na różne organizacje rządowe, np. podczas strajków ws. ACTA.

Obsługa narzędzia jest bardzo prosta i sprowadza się w zasadzie do wpisania adresu celu i wybrania szybkości ataku.

Rysunek 1. Low Orbit Ion Cannon (źródło: Sourceforge.net).

Link do narzędzia

2. XOIC

Nieco rozbudowana wersją LOIC, która przy równie prostym GUI potrafi wykonać dość skuteczne ataki wolumetryczne. W trybie DoS aplikacja zalewa serwer z wykorzystaniem protokołów TCP/HTTP/UDP oraz ICMP. Narzędzie przeznaczone jest wyłącznie dla Windows 7/8.

Rysunek 2. XOIC (źródło: Sourceforge.net).

Link do narzędzia

3. Hulk (http Unbearable Load King)

Multiplatformowy skrypt Pythona służący do przeprowadzania ataków DoS. Jest to już bardziej zaawansowane narzędzie od LOIC/XOIC, gdyż stara się ono dynamicznie zmieniać żądania, w celu omijania podstawowych wzorców systemów IDS/IPS.

Link do narzędzia

4. Slowloris oraz RUDY

Slowloris jest skryptem zaprezentowanym przez znanego hakera — RSnake’a — który pokazał nową, niezwykle efektywną metodę ataku DoS warstwy aplikacji, polegającą na wysyłaniu odpowiednio spreparowanych żądań HTTP GET.

Slowloris.pl jest multiplatformowym skryptem Perla, który potrafi unieruchomić serwer web aplikacji przy wykorzystaniu bardzo małych zasobów. Atak Slowloris opisano w jednym z wcześniejszych paragrafów. Warto dodać, że skrypt nie powinien być uruchamiany na platformie Microsoft Windows z powodu ograniczeń na liczbę otwieranych gniazd w tym systemie.

Link do narzędzia

Drugim narzędziem, który wykorzystuje ideę RSnake’a jest RUDY — R-U-Dead-Yet DDoS Attack Tool. RUDY podczas ataku używa metody HTTP POST, która powoli „zatyka” serwer aplikacji, podobnie jak ma to miejsce w przypadku ataku Slowloris. Co ciekawe niektóre serwery z mechanizmami „anti-slowloris” mogą być podatne na atak RUDY, gdyż zabezpieczenia mogą skupiać się wyłącznie na zapytaniach HTTP GET, z których R-U-Dead Yet nie korzysta.

Link do narzędzia

5. THC-SSL-DOS

Narzędzie z serii „The Hackers Choise” do ataków zwielokrotnionego odbicia, które wykorzystuje specyfikę protokołu SSL. Program podczas testów wielokrotnie ustanawia sesję SSL, która do działania wymaga przeprowadzenia kilku obliczeń. Niestety mechanizm „SSL Handshake” w połączeniu z opcją automatycznej renegocjacji (SSL Renegotiation) został tak skonstruowany, że wielokrotnie więcej obliczeń wykonywane jest po stronie serwera niż klienta. Właśnie ten efekt zwielokrotnienia został wykorzystany przez THC-SSL-DOS.

THC-SSL-DOS jest narzędziem niezwykle efektywnym — podobnie jak ataki z rodziny „slowloris”, atak na warstwę SSL nawet z pojedynczego komputera może sparaliżować działanie całego serwera WWW.

Problem renegocjacji SSL staje się powoli rozwiązywalny, przez co THC-SSL-DOS nie jest już tak potężnym narzędziem jak kilka lat temu. Warto jednak dalej wykorzystywać go do testów — wyżej wspomniany problem w SSL nie musi objawiać się tylko w protokole HTTPS, ale również w innych protokołach, takich jak POP3S czy SMTPS.

Link do narzędzia

Adrian “Vizzdoom” Michalczyk