AWS, Cloudflare i Google ujawniły na początku października 2023 roku, że hakerzy wykorzystali nową lukę o nazwie „HTTP/2 Rapid Reset” do przeprowadzenia ogromnych ataków typu Distributed Denial of Service (DDoS). Według badaczy bezpieczeństwa były to, jak do tej pory, jedne z największych ataków DoS w historii Internetu. Dla przykładu Amazon odnotował kilkanaście ataków HTTP/2 Rapid Reset, których volumen przekraczał 100 milionów żądań na sekundę (RPS), największy z nich osiągnął poziom 155 milionów RPS.
Jak działa HTTP/2?
HTTP/1 i HTTP/2 to dwie różne wersje protokołu HTTP (Hypertext Transfer Protocol), który jest używany do przesyłania danych w sieci, zwłaszcza na stronach internetowych. HTTP/2 jest nowszym i bardziej wydajnym protokołem niż HTTP/1, co przekłada się na szybsze ładowanie stron internetowych (np. w HTTP/1, każde żądanie i odpowiedź zawierały pełne nagłówki HTTP, co mogło prowadzić do nadmiernego zużycia przepustowości. W HTTP/2 wprowadzono kompresję nagłówków, co zmniejsza rozmiar danych przesyłanych w nagłówkach). Z punktu widzenia bezpieczeństwa ważną różnicą jest fakt, że w HTTP/2 używanie protokołu SSL/TLS (Secure Sockets Layer/Transport Layer Security) jest praktycznie wymagane, podczas gdy w HTTP/1 jest to opcjonalne. To SSL/TLS zapewnia bezpieczeństwo i poufność komunikacji.
HTTP/2 umożliwiło zmniejszenie opóźnień – m.in. poprzez zastosowanie multipleksowania. Wprowadzając multipleksowanie (możliwość jednoczesnego pobierania wielu zasobów za pomocą jednego połączenia TCP), HTTP/2 usprawnia transmisje. Wysyłanie wielu równoległych żądań w protokole HTTP/1.1 wymaga nawiązania wielu połączeń TCP. To wynika bezpośrednio z modelu dostarczania HTTP/1.1, który zapewnia jedną odpowiedź na jedno połączenie, znaną jako kolejkowanie odpowiedzi. Natomiast multipleksowanie w HTTP/2 powoduje, że wiele strumieni danych może być przesyłanych jednocześnie w jednym połączeniu TCP. Każdy strumień reprezentuje żądanie lub odpowiedź, na przykład żądanie pobrania konkretnej części strony internetowej lub odpowiedź na to żądanie. Dzięki multiplexingowi możliwe jest równoczesne przesyłanie wielu strumieni danych, co eliminuje potrzebę tworzenia wielu osobnych połączeń TCP, jak to miało miejsce w przypadku HTTP/1.
Dzięki protokołowi HTTP/2 klient może otwierać wiele jednoczesnych strumieni w ramach jednego połączenia TCP, a każdy strumień odpowiada jednemu żądaniu HTTP. Maksymalna liczba jednocześnie otwartych strumieni jest teoretycznie kontrolowana przez serwer, ale w praktyce klienci mogą otworzyć 100 strumieni na żądanie, a serwery przetwarzają te żądania równolegle.
HTTP/2 Rapid Reset attack
Protokół HTTP/2 pozwala klientom wskazać serwerowi, że poprzedni strumień powinien zostać anulowany poprzez wysłanie ramki RST_STREAM.
Protokół nie wymaga, aby klient i serwer koordynowali w jakikolwiek sposób anulowanie rezerwacji, klient może to zrobić jednostronnie. Klient może także założyć, że anulowanie nastąpi natychmiast po odebraniu przez serwer ramki RST_STREAM, przed przetworzeniem jakichkolwiek innych danych z tego połączenia TCP. Atak ten nazywa się Rapid Reset, ponieważ opiera się na możliwości wysłania przez punkt końcowy ramki RST_STREAM natychmiast po wysłaniu ramki żądania, co powoduje, że drugi punkt końcowy zaczyna działać, a następnie szybko resetuje żądanie. Żądanie zostaje anulowane, ale połączenie HTTP/2 pozostaje otwarte.
Atak HTTP/2 Rapid Reset oparty na tej możliwości jest prosty: klient otwiera dużą liczbę strumieni jednocześnie, jak w standardowym ataku HTTP/2, ale zamiast czekać na odpowiedź na każdy strumień żądania z serwera lub proxy, klient natychmiast anuluje każde żądanie, wysyłając odpowiednie żądanie resetu. Możliwość natychmiastowego resetowania strumieni pozwala, aby każde połączenie miało nieograniczoną liczbę żądań w locie.
Anulując żądania, osoba atakująca nigdy nie przekroczy limitu liczby jednoczesnych otwartych strumieni. W typowej implementacji serwera HTTP/2 serwer nadal będzie musiał wykonać znaczną ilość pracy w przypadku anulowanych żądań, na przykład przydzielic zasoby potrzebne do analizy zapytania i dekompresji nagłówka.
Ponadto w przypadku gdy architektura implementuje rozwiązanie odwrotnego proxy (reverse proxy) żądanie może zostać przesłane do serwera zaplecza przed przetworzeniem ramki RST_STREAM. Co znacząco wpłynie na zużycie zasobów. Atakujący natomiast nie zostanie obciążony jakimkolwiek wysiłkiem, nie trzyma odpowiedzi i nie będzie musiał przetwarzać danych zwracanych przez serwer ofiary.
