Masywny 13-dniowy atak DDoS botnetu na serwis streamingowy

Czy jesteście w stanie z ręką na sercu zapewnić, że aplikacje internetowe tworzone przez Wasze firmy są w stanie obsłużyć 292 tysiące żądań z 402 tysięcy różnych adresów IP na sekundę?

Atak DDoS przeprowadzony na tak dużą skalę byłby niemożliwy do odparcia dla wielu usług — niezależnie od tego, jak dobrze zostały opracowane, jakie zastosowano w nich praktyki bezpieczeństwa i jakie testy penetracyjne zdołały przetrwać.

Mimo to, jak wynika z nowego raportu firmy Imperva zajmującej się usuwaniem skutków ataków DDoS, celem równie dużego ataku padła tej wiosny pewna firma.

Nazwa firmy nie została podana do informacji publicznej, jednak, zgodnie z jej oświadczeniem, są to twórcy aplikacji do strumieniowej transmisji multimediów, którą w kwietniu tego roku obrano za cel masywnego ataku DDoS na 7. warstwę aplikacji. Przez blisko dwa tygodnie atak nieprzerwanie przesyłał ponad 100 tysięcy żądań na sekundę, osiągając maksymalną chwilową wartość na poziomie 292 tysięcy żądań. Pracownicy firmy Imperva opisują to zdarzenie jako największy atak DDoS w warstwie 7., jakiego kiedykolwiek byli świadkami.

Ataki DDoS w warstwie 7. aplikacji różnią się od ataków DDoS w warstwie sieciowej, których celem jest zablokowanie komunikacji pomiędzy docelową stroną a resztą Internetu poprzez maksymalne wykorzystanie jej przepustowości. Zamiast tego ataki w warstwie 7. próbują naśladować normalne zachowania użytkowników, pochłaniając zasoby na serwerze sieci Web poprzez zalewanie sieci dużą liczbą żądań HTTPS GET/POST.

Taki ruch może być trudny do oznaczenia jako złośliwy, ponieważ trudno odróżnić go od rzeczywistej działalności użytkowników.W rezultacie obrona przed atakami DDoS na warstwę 7. aplikacji może być znacznie trudniejsza. Mimo to, zdaniem firmy Imperva, jej pracownikom udało się złagodzić skutki ataku, a klient zdołał uniknąć jakichkolwiek przestojów.

W czasie dochodzenia w tej sprawie badacze zidentyfikowali potencjalne źródło zagrożenia: urządzenia IoT zainfekowane ściśle określoną wersją złośliwego oprogramowania Mirai.

Oprogramowanie Mirai zyskało rozgłos w 2016 r. po przeprowadzeniu za jego pomocąniszczycielskiego ataku DDoS na usługę nazw domen Dyn, który poskutkował zablokowaniem dostępu do niektórych spośród najpopularniejszych stron w całym Internecie.

Mirai odpowiada za stworzenie ogromnego botnetu poprzez skanowanie rozległych obszarów Internetu w poszukiwaniu otwartych portów Telnet i podejmowanie prób uzyskania dostępu do urządzeń za pomocą prostego triku — polegającego na wykorzystywaniu słabych nazw użytkownika i haseł.

W wyniku ataku ze smutkiem stwierdzono, że właściciele podatnych routerów IoT i kamer internetowych nie nauczyli się, że używanie domyślnej nazwy użytkownika i hasła na urządzeniu z dostępem do Internetu jest równie skuteczne jak całkowita rezygnacja z haseł.

Wiele wskazuje na to, że to nie pierwotna forma oprogramowania Mirai zaatakowała firmę rozrywkową, lecz jeden z wielu jego wariantów, które pojawiły się w sieci po udostępnieniu kodu źródłowego Mirai do pobrania.

Ujawnienie kodu nieco ułatwiło przejmowanie kamer monitoringu, routerów i wszelkich innych urządzeń IoT w celu bombardowania stron internetowych atakami — w tym najnowszym atakiem DDoS na 7. warstwę aplikacji.

Jak wykazała analiza adresów IP, których użyto do przeprowadzenia ataku, większość z dotychczas zidentyfikowanych urządzeń pochodziła z Brazylii.

Aby uniknąć zablokowania przez usługi łagodzące skutki ataków DDoS, hakerzy użyli prawdziwych nagłówków User Agent, dzięki czemu żądania wyglądały tak samo jak przesyłane przez legalną aplikację do pobierania strumieniowego.

I choć trudno jednoznacznie to potwierdzić, za motywację do przeprowadzenia ataku uważa się próbę przejęcia kont metodami credential stuffing oraz brute force. Botnety IoT nadal wykorzystuje się do przeprowadzania złośliwych ataków DDoS, dlatego z punktu widzenia konsumentów ważniejsze niż kiedykolwiek wydaje się dziś zapewnienie, aby ich połączone z siecią gadżety były należycie chronione i wspierane przez poprawki. W końcu nikt z nas nie chce być częściowo odpowiedzialny za jeden z największych w historii ataków DDoS w 7. warstwie aplikacji, czyż nie?