Miesiąc: luty 2020

 W lipcu 2001 r. EEye Digital Security i kilka innych organizacji zajmujących się bezpieczeństwem w Internecie zobaczyło alarmującą liczbę skanów portu 80 w Internecie. W końcu odkryli, co stało się znane jako Code Red Worm. Code Red miał trzy odrębne fazy. Faza propagacji nastąpiła podczas pierwszych  19 dni miesiąca. Podczas tej fazy atakujący system skanował systemy docelowe na porcie TCP 80 i wysłał specjalnie spreparowane żądanie HTTP GET, które wykorzystało przepełnienie bufora IIS (nawet jeśli usługa indeksowania nie jest uruchomiona). Typowy wpis dziennika może

Pojawia się jako:

211.5.255.44 – – [16 / sie / 2001: 11: 30: 49 -0400] „GET

/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN% u9090% u685

8% ucbd3% u7801u9090% u6858% ucbd3% u7801% u9090% u6858% ucbd3% u7801% u9090% u9090% u8190% u00c3% u0003% u8b00% u531b% u53ff% u0078% u0000% ”400

Kiedy exploit się powiedzie, robak uruchomił się w pamięci RAM zainfekowanego serwera i stworzył 99 nowych wątków, aby zaatakować quasi-losowy zestaw adresów IP. Jeśli natywna wersja językowa wykorzystywanego serwera jest w języku angielskim, pagery internetowe serwera zostały zniekształcone komunikatem „Witamy na stronie http://www.worm.com! Zhakowany przez Chińczyków! ”Ta wiadomość pozostanie aktywna przez 10 godzin, a następnie zniknie. Faza powodziowa miała miejsce w dniach 20–27 dnia miesiąca. To wtedy naprawdę miał miejsce atak; codziennie od 20:00 do 23:59 UTC, zaatakowane serwery wysłały pakiety 100 KB na adres IP 198.137.240.91, który wcześniej był przypisany do www.whitehouse.gov. (Po odkryciu działań Code Red adres IP www.whitehouse.gov został zmieniony z adresu docelowego.) Dni od 28 do 31 miesiąca były fazą zakończenia, kiedy robak uśpił. Code Red był stosunkowo nieszkodliwy w porównaniu z tym, czym mógł być; raz zasnął, robak spał, chociaż można go było ponownie obudzić. Usunięcie robaka z pamięci RAM wymagało jedynie ponownego uruchomienia komputera, a łatka od Microsoft zapobiegałaby dalszej infekcji. Nawiasem mówiąc, chociaż można wykorzystać tylko serwery IIS, wpłynęło to również na wiele innych urządzeń nasłuchujących na porcie 80. Na przykład routery Cisco 600 DSL i urządzenia HP JetDirect nasłuchują na porcie 80 i ulegną awarii, gdy otrzymają pakiet przepełnienia bufora. W Internecie istniały trzy różne warianty Code Red, wszystkie działały zgodnie z opisem. W sierpniu 2001 r. Pojawiło się kilka nowych wariantów o nazwie Code Red II. W przeciwieństwie do Code Red, Code Red II nie zniszczył stron internetowych ani nie zainicjował ataku DDoS na żadną witrynę. Zamiast tego robak był destrukcyjny, instalował backdoory na zainfekowanych serwerach, zmieniał wiele ustawień rejestru, instalował wersję explorer.exe konia trojańskiego (Windows Explorer) i wyłączał narzędzie System File Checker (SFC). Robak rozprzestrzeniał się również szybko, wykorzystując do 300 wątków jednocześnie szukających innych systemów do zainfekowania.

Omawiane narzędzia wykorzystują wspólne podejście DoS: osoba atakująca wykorzystuje lukę w potencjalnej ofierze i wykorzystuje ten system do przeprowadzania ataków na zamierzoną ofiarę. Późniejsze rundy ataków DDoS używają jednak kodu, który jest powszechnie dostępny i który ma znane luki w zabezpieczeniach. I zbyt często luki są wykorzystywane po wydaniu łatki do ich usunięcia, ale są ignorowane przez niektórych administratorów systemu. Przykładem jest seria takich wydawnictw w połowie 2001 roku. W maju 2001 r. W usłudze indeksowania Microsoft IIS odkryto exploit przepełnienia bufora. W połowie czerwca Microsoft wydał biuletyn bezpieczeństwa ostrzegający ten organ administracyjny skrypty (pliki .ida) i kwerendy danych internetowych (pliki .idq) nie sprawdzały poprawnie granic. Tak się składa, że wydaje się, że większość serwerów IIS nie otrzymała łatki i zasadniczo każdy niezałatany serwer IIS stał się zombie DDoS.

Innym wariantem tego rodzaju ataków jest działo Low Orbit Ion Cannon (LOIC). Zaprojektowany do użycia jako test obciążenia sieci, może być również wdrożony jako narzędzie DoS lub DDoS. LOIC działa w zasadzie, zalewając cel pakietami TCP i UDP, aby dowiedzieć się, czy routery potrafią obsłużyć obciążenie i jak zareagują – czy też przejmą całą przepustowość. Oryginalnie napisany w języku C #, pojawił się również wariant JavaScript (LS LOIC) i wersja Web (Low OrbitWeb Cannon). LOIC był szeroko wykorzystywany przez haktywistyczny kolektyw Anonymous. High Orbit Ion Cannon (HOIC) to modyfikacja LOIC. Ma łatwy w obsłudze graficzny interfejs użytkownika, który pozwala atakującym określić cele i skrypty wspomagające, aby kierować wiele stron na docelowym serwerze, podobnie jak strzelba zamiast karabinu. Ustawienie intensywności określa liczbę żądań na sekundę (2 / s dla niskiego i 8 / s dla wysokiego). HTTP Unbearable Load King (HULK) to odmiana innych narzędzi, które bombardują serwer WWW ogromną liczbą pakietów. Jednak większość wcześniejszych narzędzi wysyła żądania TCP SYN lub inne przewidywalne pakiety, co pozwala zaporze i / lub serwerowi wykryć atak i zamontować obronę. HULK generuje unikalny, nieprzewidywalny zestaw żądań zaprojektowany w celu udaremnienia obrony w oparciu o rozpoznawanie wzorców i filtrowanie pakietów.

Powyższy opis niektórych pierwszych narzędzi DDoS ma na celu ukazanie wczesnej linii bazowej, z której wyewoluowały późniejsze narzędzia, z których wiele jest po prostu odmianą wczesnych narzędzi. Mydoom (akaW32.MyDoom@mm i inne aliasy) to przykład ataku DoS za pośrednictwem robaka pocztowego, uruchomionego po raz pierwszy w 2004 r. Mydoom pojawia się jako wiadomość e-mail z pewnego rodzaju błędną wiadomością w temacie (np. „Błąd” lub „Awaria systemu poczty”). Co ciekawe, wiadomość e-mail można przygotować w kilku różnych językach, w tym w języku angielskim, francuskim i niemieckim. Wiadomość e-mail zawierała załącznik, który, jeśli zostanie wykonany, przekazał robaka na adresy znalezione w różnych plikach w systemie lokalnym, w tym w książce adresowej. Robaka można również skopiować do folderów współdzielonych w witrynach sieci peer-to-peer użytkownika. Wczesne wersje Mydoom zawierały ładunek, który mógłby zainicjować atak DoS przeciwko SCO Group 1 lutego 2004 r .; Grupa SCO była niepopularna, ponieważ w pozwie o wartości 1 miliarda dolarów twierdziła, że ​​kilka dystrybucji Linuksa narusza zasoby intelektualne UNIX SCO. Następnie wydano inne warianty Mydoom, w tym wersję zastosowaną w atakach na Koreę Południową i Stany Zjednoczone w lipcu 2009 r., Która obejmowała uruchomienie botnetu.

Oprogramowanie Zombie nie zawsze jest dystrybuowane przez osobę atakującą wykorzystującą lukę w zabezpieczonym systemie. Rzeczywiście bardzo często winowajcą jest użytkownik. Konie trojańskie są często mechanizmem dystrybucji kodu zombie. Na przykład oprogramowanie SubSeven jest wirusem typu backdoor. SubSeven często dostaje się do systemu użytkownika, ponieważ jest dystrybuowany w ramach programów dostępnych za pośrednictwem sieci Usenet i innych witryn internetowych, takich jak niektóre gry lub programy pornograficzne (np. SexxxyMovie.mpeg.exe). Potencjalni napastnicy często skanują dziś systemy komputerowe, szczególnie systemy domowe podłączone do Internetu za pośrednictwem DSL lub modemu kablowego, w poszukiwaniu obecności SubSeven, co zapewnia potencjalne backdoor do systemów użytkowników; administratorzy systemów uczą się również skanować w poszukiwaniu tego niebezpiecznego programu we własnych systemach.

We wrześniu 2000 r. Zgłoszono nowe narzędzie DDoS o nazwie Trinity. Trinity jest w stanie przeprowadzić kilka rodzajów ataków powodziowych na miejscu ofiary, w tym ACK, fragment, RST, SYN, UDP i inne powodzie. Oprogramowanie agenta Trinity musi zostać umieszczone w systemach Linux zagrożonych przepełnieniem bufora. Kod binarny agenta zwykle znajduje się w /usr/lib/idle.so. Jednak komunikacja od przewodnika lub intruza do agenta odbywa się za pośrednictwem Internet Relay Chat (IRC) lub oprogramowania do przesyłania wiadomości ICQ w America Online. Podczas gdy atakujący musi śledzić adresy IP zainfekowanych systemów za pomocą Trinoo i TFN, wszyscy agenci Trinity zgłaszają się atakującemu, pojawiając się w tym samym pokoju czatu. Oryginalne raporty mówiły, że agent Trinity komunikował się kanałem IRC o nazwie # b3eblebr0x; inne kanały IRC prawdopodobnie również są wykorzystywane do DDoS. IRC korzysta z portów TCP 6665 do −6669, a Trinity wydaje się używać portu 6667. Ponadto plik binarny o nazwie / var / spool / uucp / uucico jest programem typu backdoor, który nasłuchuje połączeń TCP na porcie 33270; atakujący łączący się z tym portem i podający hasło! @ # osiągnie rootkit w systemie, którego dotyczy luka.

Atak Apache. W sierpniu 2000 r. Po raz pierwszy wykryto atak DDoS na serwery Apache Web. W ataku wykorzystano lukę, w wyniku której adres URL wysłany na serwer Apache zawierający tysiące ukośników (/) wprowadziłby serwer w stan, który pochłonąłby ogromną ilość czasu procesora. Ten konkretny atak został zainicjowany przez ponad 500 komputerów z systemem Windows o zaatakowanym zabezpieczeniu i prawdopodobnie byłby skuteczny przeciwko serwerom WWW Apache przed wersją 1.2.5.

Trinoo, TFN / TFN2 K i Stacheldraht były pierwszymi i prawdopodobnie najlepiej zbadanymi narzędziami DDoS. Oczywiście pojawiły się inne narzędzia, które stały się coraz bardziej złożone, ale te wczesne narzędzia pozostają dostępne, a niektóre systemy pozostają podatne na te formy ataku. Na przykład w listopadzie 1999 r. Stało się dostępne narzędzie Shaft DDoS. Sieć Shaft wygląda koncepcyjnie podobnie do sieci Trinoo z programami obsługi klienta zarządzającymi (shaftmaster), które z kolei zarządzają programami agentów (shaftnode). Podobnie jak Trinoo, komunikacja handler-agent korzysta z protokołuUDP, z programami obsługi nasłuchującymi na porcie 20433 i agentami nasłuchującymi na porcie 18753. Klient komunikuje się z programem obsługi przez telnetting do portu TCP 20432. Sam atak jest zalewaniem pakietów atak, a klient kontroluje rozmiar zalewanych pakietów i czas trwania ataku. Jedną sygnaturą Shaft jest to, że numer kolejny dla wszystkich pakietów TCP wynosi zawsze 0 × 28374839.

Tribe Flood Network 2 K (TFN2 K) został wydany w grudniu 1999 roku i jest przeznaczony dla serwerów UNIX i Windows NT. TFN2K jest złożonym wariantem oryginalnego TFN z funkcjami zaprojektowanymi specjalnie w celu:

* Utrudnij rozpoznawanie i filtrowanie ruchu TFN2K

* Zdalne wykonywanie poleceń

* Ukryj prawdziwe źródło ataku za pomocą fałszowania adresów IP

* Transportuj ruch TFN2K przez wiele protokołów transportowych, w tym UDP, TCP i ICMP

* Zmieszaj próby zlokalizowania innych węzłów w sieci TFN2K, wysyłając pakiety „wabiące”

TFN2 K, podobnie jak TFN, może zużywać całą przepustowość systemu, zalewając zaatakowaną maszynę danymi. Jednak TFN2 K, w przeciwieństwie do TFN, obejmuje również ataki zaprojektowane w celu awarii lub wprowadzenia niestabilności w systemach poprzez wysyłanie zniekształconych lub nieprawidłowych pakietów, takich jak te znalezione w atakach Teardrop i Land. TFN2K wykorzystuje architekturę serwera klienta, w której pojedynczy klient wydaje polecenia jednocześnie do zestawu agentów TFN2K. Następnie agenci przeprowadzają ataki DoS na ofiarę (ofiary). Oprogramowanie agenta jest instalowane na komputerze, który został już przejęty przez atakującego.