Sårbarhet i HTTP/2-protokollet, som användes i den största DDoS-attacken

Google har registrerat den största DDoS-attacken mot sin infrastruktur, med en intensitet på 398 miljoner förfrågningar per sekund. Den nya attacken överträffar den tidigare rekorddömda DDoS-attacken med sju gånger intensitet, där angripare lyckades generera en ström av 47 miljoner förfrågningar per sekund. Som jämförelse uppskattas den totala trafiken på hela webben ligga på 1-3 miljarder förfrågningar per sekund. Förutom Google drabbades även företagen Amazon och Cloudflare av attacken. Möjligheten till en ny attack är kopplad till en sårbarhet som upptäckts i HTTP/2-protokollet (CVE-2023-44487), vilket möjliggör att en stor mängd förfrågningar kan riktas mot servern med minimal belastning på klienten.

Den nya attacktekniken har fått namnet "Rapid Reset" och utnyttjar de multiplexeringsverktyg som tillhandahålls i HTTP/2, vilket gör det möjligt att skapa en ström av förfrågningar inom ett redan etablerat samband, utan att behöva öppna nya nätverkskopplingar och utan att vänta på bekräftelse på att paket har mottagits. Sårbarheten ses som en följd av brister i HTTP/2-protokollet, där det anges att när man försöker öppna ett för stort antal flöden, ska endast de flöden som överstiger gränsen avslutas, men inte den totala nätverkskopplingen.

I likhet med tidigare använda metoder för attack på HTTP/2 skapas även i den nya attacken ett stort antal flöden inom en och samma koppling. En avgörande skillnad med den nya attacken är att istället för att vänta på svar skickas ett ram med RST_STREAM-flaggan omedelbart efter varje skickad förfrågan, vilket omedelbart avbryter förfrågan. Att avbryta förfrågan i ett tidigt skede gör det möjligt att eliminera den omgivande trafiken mot klienten och kringgå de begränsningar som finns på HTTP-servrar rörande det maximala antalet flöden som kan vara öppna inom en och samma HTTP/2-koppling. Således slutar mängden förfrågningar som riktas till HTTP-servern i den nya attacken att bero på fördröjningar mellan avsändning av förfrågningar och mottagande av svar (RTT, round-trip time) och beror endast på den tillgängliga bandbredden.

Eftersom det räcker med att skicka förfrågningar utan att få svar för att genomföra en attack på klientsidan, kan attacken utföras med minimala overheadkostnader. Ett exempel är en attack upptäckt av företaget Cloudflare, som hade 201 miljoner förfrågningar per sekund och genomfördes med hjälp av en relativt liten botnät med 20 000 datorer. På serversidan servern är kostnaderna för att bearbeta de inkommande förfrågningarna betydligt högre, trots att de annulleras, eftersom det är nödvändigt att utföra operationer som att allokera datakonstruktioner för nya flöden, parsa förfrågan, packa upp rubriken och matcha URL med resursen. Vid attacker mot omvända proxyer kan attacken sprida sig till baksidan, eftersom proxy kan hinna omdirigera förfrågan till baksidan före behandlingen av RST_STREAM-ramen.

Attacken kan endast genomföras mot sårbara servrar som stöder HTTP/2 (ett skript för att kontrollera sårbarheten i servrar, verktyg för att genomföra attacken). För HTTP/3 har inga attacker registrerats än och möjligheten att genomföra dem har ännu inte analyserats, men representanter från Google rekommenderar utvecklare servrar att inkludera skyddsåtgärder i implementeringarna av HTTP/3, liknande de som införts för att blockera attacker mot HTTP/2.

Sårbarhet och tillgång till korrigeringar för HTTP-servrar och proxyer:

• nginx (meddelande, förklaring av att sårbarheten inte fullt ut manifesterar sig i nginx med standardkonfiguration, eftersom attacken kommer att nå gränsen för antalet förfrågningar per förbindelse (d.v.s. efter varje 1000 förfrågningar kommer förbindelsen att avbrytas). Denna korrigering inkluderade ytterligare skydd mot överdrivna förfrågningar via direktivet "limit_req").
• I HAProxy lades effektivt skydd mot överskridande av gränsen för antal HTTP/2-strömmar till i 2018 och träder i kraft från version 1.9-dev.
• Apache httpd (en viss belastning skapas på httpd, men den sprider sig inte till baksidan och begränsas av de gällande begränsningarna för klientanslutningar som trädde i kraft 2016).
• mod_h2 för Apache httpd.
• caddy
• envoy
• golang (problemet är löst i utgåvorna Go 1.21.3 och 1.20.10).
• h2o (patch).
• grpc-go
• hyper (sårbarheten manifesterar sig inte).
• jetty (fixat i 12.0.2, 11.0.17, 10.0.17 och 9.4.53.v20231009).
• netty
• nghttp2 (fixat i version 1.57.0).
• Facebook proxygen
• .NET och ASP.NET Core (sårbarheterna gäller http-servern ASP.NET Core Kestrel).
• Node.js
• proxygen
• swift-nio-http2 (fixat i version 1.28.0).
• Apache Tomcat (åtgärdad i versionerna 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
• Apache Traffic Server (åtgärdad i grenen 9.2.x).

Källa: opennet.ru