W ciągu ostatnich dwóch miesięcy atakujący nadużywali funkcji protokołu komunikacji internetowej HTTP/2, która sprawia, że serwery aplikacji internetowych, load balancery i serwery proxy są podatne na ataki typu rozproszona odmowa usługi (DDoS) na niespotykaną dotąd skalę. Google, AWS, Cloudflare i inni główni dostawcy infrastruktury chmurowej, a także dostawcy serwerów internetowych pracowali nad strategiami łagodzenia skutków i łatkami w prywatnych grupach, dopóki podatność nie została właśnie ujawniona.

Nowo nazwane ataki HTTP/2 Rapid Reset DDoS wykorzystują funkcję multipleksowania strumieni protokołu HTTP/2, która umożliwia równoległe wysyłanie wielu żądań HTTP za pośrednictwem tego samego połączenia transportowego TCP, a w szczególności zdolność klientów do jednostronnego resetowania tych strumieni. Problem jest śledzony jako CVE-2023-44487, a organizacje powinny sprawdzić, czy ich dostawcy serwerów internetowych i load balancerów mają dostępne poprawki lub zalecenia dotyczące łagodzenia skutków.

Zobacz również:

• Ministerstwo Cyfryzacji ostrzega przed rosnącym zagrożeniem atakami DDoS
• Palo Alto wzywa pilnie użytkowników jej zapór sieciowych, aby jak najszybciej zaktualizowali zarządzające nimi oprogramowanie
• Bezpieczeństwo w chmurze publicznej nadal priorytetowe

Multipleksowanie strumieni zwiększa skuteczność ataków DDoS

W starej wersji HTTP 1, która jest nadal obsługiwana przez większość serwerów i klientów internetowych, wiele żądań może być wysyłanych za pośrednictwem jednego połączenia TCP, ale są one wysyłane seryjnie, a serwer przetwarza je i odpowiada na nie w kolejności, w jakiej zostały odebrane. W HTTP/2 wiele żądań zwanych strumieniami, które składają się z ramek, takich jak HEADERS lub DATA, może być wysyłanych przez połączenie TCP jednocześnie i poza kolejnością. Dzieje się tak, ponieważ każdy strumień ma powiązany z nim identyfikator, więc serwer zawsze będzie wiedział, którego strumienia ramka jest częścią i jak odpowiedzieć. Jest to znane jako multipleksowanie strumieni i pozwala na bardziej efektywne wykorzystanie połączeń TCP i przyspiesza czas ładowania strony.

Wyobraźmy sobie nowoczesną stronę internetową, która zawiera wiele zasobów, skryptów stron trzecich i obrazów załadowanych z różnych lokalizacji. Przeglądarka uzyskująca dostęp do takiej strony za pośrednictwem protokołu HTTP/2 natychmiast rozpocznie równoległe ładowanie tych zasobów, nadając priorytet tym, które znajdują się w widoku użytkownika. Jeśli użytkownik natychmiast kliknie przycisk i odejdzie od strony, przeglądarka może zamknąć strumienie, nawet jeśli zasoby nie zostały w pełni załadowane lub wyrenderowane bez zamykania całego połączenia i otwierania nowych żądań. „Od końca 2021 r. większość ataków DDoS warstwy 7, które zaobserwowaliśmy w usługach własnych Google i projektach Google Cloud chronionych przez Cloud Armor, opierała się na protokole HTTP/2, zarówno pod względem liczby ataków, jak i szczytowych szybkości żądań”, napisaliinżynierowie Google w poście na blogu objaśniającym szczegóły nowego ataku. „Głównym celem projektowym HTTP/2 była wydajność i niestety funkcje, które sprawiają, że HTTP/2 jest bardziej wydajny dla legalnych klientów, mogą być również wykorzystywane do zwiększania wydajności ataków DDoS”.

Omijanie limitów jednoczesnych strumieni za pomocą Rapid Resets

Ponieważ serwer musi zużywać cykle procesora i pamięć do przetwarzania każdej ramki i strumienia, możliwość nadużywania współbieżnych strumieni w celu wyczerpania zasobów serwera, a tym samym spowodowania stanu odmowy usługi, była oczywista dla twórców protokołu od samego początku. Dlatego dodali ustawienie o nazwie SETTINGS_MAX_CONCURRENT_STREAMS, które serwer będzie przekazywał klientom punktu końcowego podczas pierwszego połączenia za pośrednictwem ramki SETTINGS.

Domyślnie wartość tego ustawienia jest nieograniczona, ale projektanci protokołu zalecają, aby nie była niższa niż 100, aby utrzymać wydajną równoległość. Z tego powodu w praktyce wielu klientów nie czeka na ramkę SETTINGS i po prostu zakłada minimalny limit 100 i wysyła 100 ramek od samego początku.

Problem pojawia się wraz z inną funkcją o nazwie RST_STREAM, która jest skrótem od „reset stream”. Jest to rodzaj ramki, którą klient może wysłać do serwera, aby wskazać, że wcześniej otwarty identyfikator strumienia powinien zostać anulowany. Pozwala to klientowi anulować żądania w locie dotyczące zasobów, które nie są już potrzebne, na przykład dlatego, że użytkownik kliknął stronę, zanim zasób został załadowany. Jest to przydatne, ponieważ mówi serwerowi, aby przestał odpowiadać na poprzednie żądanie i nie marnował przepustowości.

Jest jednak pewien haczyk. Wysyłając ramkę RST_STREAM docelowy strumień nie jest już liczony do maksymalnego limitu jednoczesnych strumieni, więc klient może natychmiast otworzyć nowy strumień po wysłaniu resetu dla poprzedniego. Oznacza to, że nawet przy limicie jednoczesnych strumieni wynoszącym 100, klient może otwierać i resetować setki strumieni za pośrednictwem tego samego połączenia TCP w krótkich odstępach czasu. Serwer nadal musi wydawać zasoby na przetwarzanie ramek RST_STREAM. Nawet jeśli nie jest to dużo, przy milionach żądań szybko się to sumuje. Korzystając z tej techniki, atakującym udało się przeprowadzić ataki DDoS na niespotykaną dotąd skalę na serwery hostowane przez Google, Cloudflare i AWS.

„Gdy serwer HTTP/2 jest w stanie przetwarzać wysyłane przez klienta ramki RST_STREAM i wystarczająco szybko usuwać stan, takie szybkie resetowanie nie powoduje problemu”, stwierdzili inżynierowie Cloudflare w swoim raporcie. „Problemy zaczynają się pojawiać, gdy występuje jakiekolwiek opóźnienie lub opóźnienie w sprzątaniu. Klient może wykonywać tak wiele żądań, że gromadzą się zaległości w pracy, co powoduje nadmierne zużycie zasobów na serwerze”.

Największy atak HTTP/2 Rapid Reset zaobserwowany przez Google osiągnął szczyt na poziomie ponad 398 milionów żądań na sekundę (rps), Dla porównania, największy atak zaobserwowany przez firmę w 2022 roku osiągnął szczyt na poziomie 46 milionów rps. Atak, który uderzył w Cloudflare w sierpniu, osiągnął szczytową wartość 201 milionów rps, trzykrotnie większą niż największy atak DDoS wykryty wcześniej przez firmę. Ten nowy atak HTTP/2 Rapid Reset został przeprowadzony z botnetu składającego się z zaledwie 22 000 komputerów, który jest niewielki w porównaniu z innymi botnetami.

Wiele wariantów ataków DDoS HTTP/2

Ataki wykorzystujące nową technikę HTTP/2 są kontynuowane, a Google zaobserwowało wiele ich wariantów, z których niektóre są prawdopodobnie reakcją na środki łagodzące. Na przykład jeden z wariantów ataku otwierał i resetował strumienie partiami, czekając przed wysłaniem ramek RST_STREAM, a następnie otwierając kolejną partię. Prawdopodobnie ma to na celu pokonanie zabezpieczeń, które polegają na wykrywaniu dużej liczby ramek RST_STREAM w tym samym połączeniu TCP i zamykaniu połączenia w odpowiedzi.

„Ataki te tracą główną zaletę ataków anulujących, ponieważ nie maksymalizują wykorzystania połączenia, ale nadal mają pewną wydajność implementacji w porównaniu ze standardowymi atakami HTTP/2 DDoS, ale ten wariant oznacza, że wszelkie środki łagodzące oparte na ograniczaniu szybkości anulowania strumieni powinny ustalać dość ścisłe limity, aby były skuteczne”, powiedzieli inżynierowie Google.

Inna odmiana w ogóle nie używa anulowania RST_STREAM i zamiast tego próbuje otworzyć jak najwięcej jednoczesnych strumieni, ignorując limit reklamowany przez serwer. Standard HTTP/2 mówi, że w tym przypadku strumienie przekraczające limit powinny zostać unieważnione przez serwer, ale pełne połączenie TCP nie powinno zostać anulowane. Tak więc ten wariant ataku pozwala atakującym na utrzymanie pełnego potoku żądań przez cały czas. „Nie spodziewamy się, że zwykłe blokowanie poszczególnych żądań jest skutecznym środkiem zaradczym przeciwko tej klasie ataków - zamiast tego całe połączenie TCP musi zostać zamknięte po wykryciu nadużycia”, piszą inżynierowie Google.

Środki zaradcze i poprawki dla ataków DDoS HTTP/2

Strategie łagodzenia skutków tych ataków nie są proste, ponieważ istnieją uzasadnione zastosowania anulowania RST_STREAM, więc każdy właściciel serwera musi zdecydować, kiedy ma miejsce nadużycie i jak surowa powinna być reakcja w oparciu o statystyki połączenia i logikę biznesową. Na przykład, jeśli połączenie TCP ma ponad 100 żądań, a klient anuluje ponad 50% z nich, połączenie może być potencjalnie postrzegane jako nadużycie. Odpowiedzi mogą obejmować wysyłanie wymuszonych ramek GOAWAY lub natychmiastowe zamknięcie połączenia TCP.

Inną reakcją może być zablokowanie obraźliwego adresu IP przed dostępem do usługi za pośrednictwem protokołu HTTP/2 i tymczasowe przeniesienie go do protokołu HTTP 1.x. Problem z filtrami IP polega na tym, że wielu klientów może współdzielić ten sam adres IP i nie wszyscy mogą być złośliwi. Ograniczając żądania do HTTP 1.x, niezłośliwi klienci za filtrowanym adresem IP nadal będą mogli uzyskać dostęp do usługi internetowej, nawet jeśli doświadczą spadku wydajności.

Deweloperzy Nginx, popularnego odwrotnego proxy i load balancera, również dostarczyli środki zaradcze, które opierają się na konkretnych funkcjach, które serwer już zaimplementował, takich jak keepalive_requests, limit_conn i limit_req. W najbliższych dniach przygotują również łatkę, która jeszcze bardziej ograniczy wpływ takich ataków.

Microsoft, AWS, F5 i inne firmy zajmujące się infrastrukturą oraz twórcy oprogramowania do serwerów internetowych lub równoważenia obciążenia opublikowali rozwiązania łagodzące lub poprawki. Użytkownicy mogą śledzić oficjalny wpis w CVE tracker, aby uzyskać linki z zaktualizowanymi odpowiedziami od dostawców.

Źródło: CSO