CDN Tsunami: nowa klasa ataków DoS wykorzystująca translację HTTP/3 do HTTP/1.1

Wprowadzenie do problemu / definicja

CDN Tsunami to nowo opisana technika ataków odmowy usługi, która wykorzystuje sposób, w jaki sieci dostarczania treści tłumaczą ruch HTTP/3 na HTTP/1.1 pomiędzy warstwą brzegową a serwerem źródłowym. Problem nie wynika z pojedynczego błędu programistycznego, lecz z architektury pośredniczącej, w której nowoczesny protokół używany przez klienta nie jest utrzymywany end-to-end aż do originu.

W praktyce oznacza to, że relatywnie niewielki ruch wysyłany przez napastnika może zostać przekształcony przez infrastrukturę CDN w znacznie większe obciążenie po stronie backendu. To istotne ostrzeżenie dla organizacji, które traktują CDN jako domyślną warstwę ochronną przed atakami DoS.

W skrócie

Badacze opisali dwa główne warianty ataku w ramach CDN Tsunami: HTTP/3 Bandwidth Amplification oraz HTTP/3 Connection Amplification. Pierwszy prowadzi do zwiększenia zużycia pasma po stronie originu, a drugi do wyczerpywania zasobów połączeniowych i utrzymywania backendu w stanie przeciążenia.

HTTP/3 Bandwidth Amplification wykorzystuje dekompresję nagłówków QPACK do pełnej postaci HTTP/1.1.
HTTP/3 Connection Amplification wymusza otwieranie wielu połączeń backendowych przez multipleksowane strumienie HTTP/3.
W badaniach wszystkie sześć analizowanych platform CDN było podatnych na wariant wzmacniający ruch.
Pięć z sześciu badanych platform było podatnych na wariant związany z wyczerpywaniem puli połączeń.
Maksymalna zaobserwowana amplifikacja sięgała około 350 razy w wybranych scenariuszach.

Kontekst / historia

Ryzyka związane z translacją protokołów w CDN nie są całkowicie nowe. Wcześniejsze analizy pokazywały już, że konwersja nowocześniejszych wersji HTTP do HTTP/1.1 może tworzyć nieoczekiwane możliwości amplifikacji ruchu oraz przeciążania usług zaplecza.

CDN Tsunami przenosi ten problem do środowiska HTTP/3, które jest coraz szerzej wdrażane na brzegu sieci. Badanie objęło sześciu dużych dostawców CDN: Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly i Tencent. Zespół badawczy wskazał, że kluczowym źródłem ryzyka jest heterogeniczne wdrożenie protokołów, w którym klient komunikuje się z CDN przez HTTP/3, ale połączenie z originem realizowane jest już w HTTP/1.1.

Autorzy przeprowadzili również analizę ekspozycji w skali Internetu, identyfikując dziesiątki tysięcy subdomen potencjalnie narażonych na ten model ataku. Jednocześnie zaznaczono, że nie prowadzono aktywnych testów przeciwko obcym środowiskom produkcyjnym.

Analiza techniczna

Pierwszy wariant, HTTP/3 Bandwidth Amplification, opiera się na QPACK, czyli mechanizmie kompresji nagłówków stosowanym w HTTP/3. Atakujący może przesyłać do CDN niewielkie referencje indeksowe, które na brzegu są rozwijane do pełnych nagłówków HTTP/1.1 przed przekazaniem ich do serwera źródłowego. W efekcie kilka bajtów po stronie klienta może skutkować znacznie większym wolumenem danych kierowanych do originu.

Najsilniejszy efekt pojawia się wtedy, gdy dostawca CDN obsługuje dynamiczną tabelę QPACK. Napastnik może najpierw wprowadzić do tabeli duży wpis nagłówka, a następnie wielokrotnie odwoływać się do niego krótkimi indeksami w kolejnych strumieniach. To właśnie w takich scenariuszach odnotowano najwyższe współczynniki amplifikacji.

Drugi wariant, HTTP/3 Connection Amplification, koncentruje się na zasobach połączeniowych originu. Część CDN otwiera połączenie HTTP/1.1 do backendu już po odebraniu ramek HEADERS, zanim dotrze pełne ciało żądania. Dzięki multipleksowaniu HTTP/3 pojedyncze połączenie klienta może utrzymywać wiele równoległych strumieni, z których każdy może spowodować zestawienie osobnego połączenia do serwera źródłowego.

Jeżeli napastnik następnie bardzo wolno dosyła kolejne fragmenty danych, CDN utrzymuje żądania w stanie niekompletnym, a backend pozostaje zajęty przez długi czas. W testach laboratoryjnych niewielka liczba połączeń HTTP/3 była w stanie wygenerować setki połączeń backendowych do serwera Apache z ograniczoną pulą gniazd, prowadząc do opóźnień, timeoutów i błędów niedostępności usług.

Konsekwencje / ryzyko

Z perspektywy obrony problem jest szczególnie istotny, ponieważ atak nie wymaga przejęcia kontroli nad serwerem źródłowym ani modyfikacji konfiguracji aplikacji. Wystarczy, że organizacja korzysta z podatnego modelu obsługi HTTP/3 na brzegu CDN i translacji do HTTP/1.1 po stronie backendu.

W wariancie nastawionym na amplifikację pasma skutkiem może być wzrost zużycia przepustowości, obciążenia infrastruktury i kosztów transferu danych. Z kolei wariant połączeniowy uderza w limity sesji, kolejki żądań, mechanizmy keep-alive oraz timeouty aplikacyjne, co może prowadzić do degradacji usług nawet przy stosunkowo niewielkim ruchu wejściowym po stronie atakującego.

Choć nie opublikowano informacji o aktywnym wykorzystaniu tej techniki w realnych incydentach i nie przypisano jej identyfikatorów CVE, model ataku jest realistyczny i opiera się na zachowaniach obserwowanych w rzeczywistej infrastrukturze CDN. Część dostawców miała również potwierdzić zgłoszenia i wdrożyć środki ograniczające ryzyko.

Rekomendacje

Organizacje korzystające z CDN powinny zweryfikować, czy po stronie klient–edge wykorzystywany jest HTTP/3 oraz jaki protokół funkcjonuje pomiędzy CDN a originem. Kluczowe jest ustalenie, czy dostawca buforuje kompletne żądanie przed zestawieniem połączenia backendowego oraz jakie limity stosuje wobec liczby połączeń inicjowanych przez pojedyncze połączenie klienta.

Ograniczyć rozmiar pojedynczych wpisów w dynamicznej tabeli QPACK.
Wprowadzić limity liczby odwołań do tego samego wpisu w jednym strumieniu.
Egzekwować maksymalny rozmiar zdekompresowanego żądania HTTP/1.1 przed przekazaniem go do originu.
Stosować niezależne timeouty dla połączeń CDN–origin.
Przejrzeć limity połączeń, keep-alive oraz ochronę przed slow request i resource exhaustion po stronie backendu.
Monitorować anomalię między ruchem przychodzącym do edge a ruchem kierowanym do originu.

W środowiskach o podwyższonym ryzyku zasadne może być także czasowe ograniczenie lub selektywne wyłączenie HTTP/3 dla wybranych usług, jeśli analiza biznesowa wykaże, że korzyści wydajnościowe nie równoważą potencjalnej ekspozycji operacyjnej.

Podsumowanie

CDN Tsunami pokazuje, że nowe klasy zagrożeń mogą pojawiać się nie tylko w wyniku błędów implementacyjnych, lecz także na styku zgodnych ze specyfikacją komponentów. W tym przypadku źródłem ryzyka jest sama translacja HTTP/3 do HTTP/1.1 i sposób, w jaki CDN zarządza kompresją nagłówków oraz zestawianiem połączeń z originem.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona oferowana przez CDN nie powinna być traktowana jako pełna gwarancja odporności na DoS wymierzony w backend. Wraz z rosnącą adopcją HTTP/3 model zagrożeń musi uwzględniać również podatności wynikające z warstw pośredniczących i konwersji protokołów.