CDN Tsunami: nowy typ ataku DDoS wykorzystuje HTTP/3 i może zwielokrotnić ruch nawet 350 razy
CDN Tsunami: nowy typ ataku DDoS wykorzystuje HTTP/3 i może zwielokrotnić ruch nawet 350 razy
CDN miały przyspieszać strony i zwiększać ich odporność na przeciążenia. Naukowcy pokazali jednak, że sposób, w jaki część sieci CDN tłumaczy ruch HTTP/3 na HTTP/1.1, może zostać wykorzystany do przeprowadzenia ataku typu DoS. W testach nazwanych „CDN Tsunami” niewielki strumień ruchu mógł zostać zwielokrotniony nawet 350-krotnie w kierunku serwera źródłowego.
Badacze z National University of Singapore, Fuzhou University, University of Sheffield i Johns Hopkins University opisali dwie techniki ataku wykorzystujące różnice pomiędzy HTTP/3 używanym pomiędzy użytkownikiem a CDN-em oraz HTTP/1.1 wykorzystywanym pomiędzy CDN-em a serwerem origin. Wyniki zostały opublikowane w badaniu „CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks”.
Problem zaczyna się na styku HTTP/3 i HTTP/1.1
HTTP/3 wykorzystuje protokół QUIC oraz mechanizm kompresji nagłówków QPACK. Dzięki temu komunikacja pomiędzy klientem a CDN-em może być bardzo wydajna pod względem wykorzystania przepustowości.
Problem pojawia się wtedy, gdy CDN kończy połączenie HTTP/3 na swojej infrastrukturze, a następnie przekazuje żądanie do serwera źródłowego jako HTTP/1.1. Według badaczy taka niejednorodna konfiguracja występuje w popularnych usługach CDN.
Atakujący może wykorzystać tę różnicę, aby niewielką ilością danych przesyłanych do CDN wygenerować znacznie większe obciążenie po stronie serwera origin.
Nawet 350-krotne zwielokrotnienie ruchu
Pierwsza technika została nazwana HTTP/3 Bandwidth Amplification (HBA). Wykorzystuje ona QPACK, czyli mechanizm kompresji nagłówków HTTP/3.
Badacze wykazali, że odpowiednio przygotowane żądania mogą zostać po stronie CDN rozpakowane do znacznie większych nagłówków HTTP/1.1. W testach uzyskano maksymalny współczynnik zwielokrotnienia na poziomie około 350×. Dla porównania wcześniejsze badania dotyczące podobnego problemu z HTTP/2 osiągały około 166×.
Oznacza to, że problem nie polega wyłącznie na klasycznym „zalaniu” serwera ogromną ilością ruchu. CDN może stać się pośrednikiem, który sam zwiększa obciążenie kierowane do infrastruktury znajdującej się za nim.
Drugi problem: wyczerpywanie połączeń
Druga technika, HTTP/3 Connection Amplification (HCA), koncentruje się nie na przepustowości, lecz na liczbie połączeń z serwerem origin.
HTTP/3 pozwala multipleksować wiele strumieni w ramach jednego połączenia. Badacze wykazali, że CDN może w odpowiedzi na te strumienie tworzyć dodatkowe połączenia HTTP/1.1 z serwerem znajdującym się za CDN-em.
W jednym z eksperymentów cztery połączenia HTTP/3, z których każde obsługiwało 96 strumieni, doprowadziły do utworzenia 384 połączeń backendowych z testowanym serwerem Apache.
Jeżeli serwer ma ograniczoną liczbę jednoczesnych połączeń, atak może doprowadzić do sytuacji, w której zabraknie zasobów dla prawidłowych użytkowników.
Sprawdzono popularne sieci CDN
Badacze przeanalizowali sześciu dostawców CDN: Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly oraz Tencent.
W ramach pomiarów przeanalizowano ponad 151 tys. subdomen korzystających z tych usług. Około 42,3 tys. odpowiadało na żądania HTTP/3 i zostało sklasyfikowanych jako potencjalnie podatne na opisane mechanizmy. Autorzy podkreślają jednak, że pomiar nie oznacza, iż wszystkie te serwisy można skutecznie zaatakować — test sprawdzał określone cechy infrastruktury CDN, a nie przeprowadzał ataków na cudze serwery.
Czy oznacza to, że HTTP/3 jest niebezpieczne?
Nie. Problemem nie jest sam protokół HTTP/3.
Sednem sprawy jest sposób jego wdrożenia oraz tłumaczenie ruchu pomiędzy różnymi wersjami protokołu. HTTP/3 może działać prawidłowo i bezpiecznie, ale infrastruktura CDN musi odpowiednio kontrolować to, co dzieje się podczas przekazywania ruchu do serwera origin.
To ważna lekcja również dla administratorów stron internetowych: korzystanie z CDN nie oznacza automatycznie, że serwer źródłowy jest odporny na każdy rodzaj przeciążenia.
Jak można ograniczyć ryzyko?
Badacze zaproponowali kilka mechanizmów ochronnych po stronie CDN. Należą do nich m.in. ograniczenie rozmiaru wpisów w dynamicznej tablicy QPACK, ograniczenie liczby odwołań do pojedynczego wpisu oraz ustalenie maksymalnego rozmiaru rozpakowanego żądania HTTP/1.1.
Istotne jest również buforowanie kompletnego żądania HTTP/3 przed utworzeniem połączenia z serwerem origin.
Co z tego wynika dla właścicieli stron?
„CDN Tsunami” pokazuje, że bezpieczeństwo infrastruktury internetowej coraz częściej zależy od całego łańcucha komunikacji, a nie tylko od zabezpieczeń samego serwera.
CDN, reverse proxy, WAF, HTTP/3, HTTP/2 i serwer origin muszą być traktowane jako jeden system. Błąd lub nieoptymalne zachowanie na granicy pomiędzy tymi elementami może zostać wykorzystane do zwiększenia skuteczności ataku.
Dla administratorów najważniejsze pozostają więc monitoring obciążenia origin, odpowiednie limity połączeń, ochrona przed atakami aplikacyjnymi oraz śledzenie zmian i zaleceń dostawcy wykorzystywanej usługi CDN.
„CDN Tsunami” to kolejny przykład tego, że nawet mechanizm zaprojektowany z myślą o wydajności może stworzyć nową powierzchnię ataku, jeśli poszczególne warstwy infrastruktury nie są ze sobą odpowiednio zabezpieczone.
🛡️ Kompletny przewodnik 2025 – jak chronić wszystkie swoje konta w social mediach przed AI i cyberzagrożeniami W 2025 roku Czytaj dalej
Jak chronić się przed hakerami: Praktyczne porady dla użytkowników domowych i firm W dzisiejszym cyfrowym świecie hakerzy stanowią coraz większe Czytaj dalej
