Firma Google zarejestrowała największy atak DDoS na swoją infrastrukturę, którego intensywność wyniosła 398 milionów zapytań na sekundę. Nowy atak przewyższa intensywnością poprzedni rekordowy atak DDoS siedmiokrotnie, w którym przestępcom udało się wygenerować strumień 47 milionów zapytań na sekundę. Dla porównania, cały ruch w Internecie szacuje się na poziomie 1-3 miliardów zapytań na sekundę. Oprócz Google z atakiem zmierzyły się również firmy Amazon i Cloudflare. Możliwość przeprowadzenia nowego ataku związana jest z wykrytą w protokole HTTP/2 luką (CVE-2023-44487), która pozwala na kierowanie ogromnego strumienia zapytań na serwer przy minimalnym obciążeniu klienta.
Nowa technika ataku nosi nazwę „Rapid Reset” i wykorzystuje fakt, że środki multiplexingu kanałów komunikacyjnych w HTTP/2 umożliwiają utworzenie strumienia zapytań w ramach już nawiązanego połączenia, bez otwierania nowych połączeń sieciowych i nie czekając na potwierdzenie odbioru pakietów. Luka ta jest traktowana jako wynik niedociągnięć protokołu HTTP/2, w specyfikacji którego stwierdzono, że w przypadku próby otwarcia zbyt dużej liczby strumieni należy anulować tylko te strumienie, które przekraczają limit, ale nie zamykać całego połączenia sieciowego.
Podobnie jak w wcześniej stosowanych metodach prowadzenia ataków na HTTP/2, w nowym ataku również tworzy się dużą liczbę strumieni w ramach jednego połączenia. Kluczową różnicą nowego ataku jest to, że zamiast czekać na odpowiedź, po każdym wysłanym zapytaniu kierowany jest fram z flagą RST_STREAM, natychmiastowo anulującą zapytanie. Anulowanie zapytania na wczesnym etapie pozwala pozbyć się ruchu zwrotnego w stronę klienta i ominąć ograniczenia istniejące na serwerach HTTP dotyczące maksymalnej liczby strumieni, które mogą być jednocześnie otwarte w ramach jednego połączenia w HTTP/2. W ten sposób, w nowym ataku, objętość zapytań kierowanych do serwera HTTP przestaje zależeć od opóźnień między wysłaniem zapytania a otrzymaniem odpowiedzi (RTT, round-trip time) i ogranicza się tylko do przepustowości kanału komunikacyjnego.
Ponieważ do przeprowadzenia ataku ze strony klienta wystarczy po prostu wysyłać zapytania, nie oczekując odpowiedzi, atak można przeprowadzić przy minimalnych kosztach. Na przykład, atak zarejestrowany przez firmę Cloudflare wynoszący 201 milionów zapytań na sekundę został przeprowadzony przy użyciu stosunkowo niewielkiego botnetu liczącego 20 tysięcy komputerów. Po stronie serwera koszty przetwarzania nadchodzących zapytań są znacznie wyższe, mimo ich anulowania, ponieważ konieczne jest wykonanie takich operacji jak alokacja struktur danych dla nowych strumieni, analiza zapytania, rozpakowywanie nagłówka i dopasowywanie URL do zasobów. W przypadku ataku na serwery proxy, atak może rozprzestrzenić się na backendy, ponieważ proxy może zdążyć przekazać zapytanie do backendu przed przetworzeniem ramki RST_STREAM.
Atak może być przeprowadzony tylko na podatne serwery obsługujące HTTP/2 (skrypt do sprawdzania manifestacji podatności w serwerach, zestaw narzędzi do przeprowadzenia ataku). Jak dotąd nie zarejestrowano ataków na HTTP/3, a możliwość ich przeprowadzenia nie została w pełni przeanalizowana, ale przedstawiciele Google zalecają programistom serwerów dodanie do implementacji HTTP/3 środków ochrony podobnych do tych zaimplementowanych w celu zablokowania ataku na HTTP/2.
Podatność na podatność i dostępność poprawek dla serwerów HTTP i proxy:
- nginx (ogłoszenie, wyjaśnienie, że podatność w pełni nie ujawnia się w nginx w konfiguracji domyślnej, ponieważ atak natrafi na limit liczby zapytań na połączenie (t.e. po każdym 1000 zapytaniu połączenie będzie resetowane). W poprawce dodano dodatkową ochronę poprzez ograniczenie intensywności zapytań za pomocą dyrektywy „limit_req”).
- W HAProxy skuteczna ochrona przed przekroczeniem limitu liczby strumieni HTTP/2 została dodana jeszcze w 2018 roku i działa od wersji 1.9-dev.
- Apache httpd (powstaje określony ruch na httpd, ale nie przenosi się na backendy i ogranicza się do obowiązujących od 2016 roku limitów połączeń klientów).
- mod_h2 dla Apache httpd.
- caddy
- envoy
- golang (problem został usunięty w wersjach Go 1.21.3 i 1.20.10).
- h2o (łatka).
- grpc-go
- hyper (podatność się nie ujawnia).
- jetty (naprawione w wersji 12.0.2, 11.0.17, 10.0.17 i 9.4.53.v20231009).
- netty
- nghttp2 (naprawione w wersji 1.57.0).
- Facebook proxygen
- .NET i ASP.NET Core (podatności podlega serwer http ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (naprawione w wersji 1.28.0).
- Apache Tomcat (naprawiono w wersjach 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (naprawiono w gałęzi 9.2.x).
Źródło: opennet.ru
