Kwetsbaarheid in het HTTP/2-protocol, die betrokken was bij de grootste DDoS-aanval

Google heeft de grootste DDoS-aanval op zijn infrastructuur geregistreerd, met een intensiteit van 398 miljoen verzoeken per seconde. Deze nieuwe aanval overtreft de vorige record-DDoS-aanval met zeven keer in intensiteit, waarin aanvallers een stroom van 47 miljoen verzoeken per seconde wisten te genereren. Ter vergelijking, het totale verkeer op het web wordt geschat op 1-3 miljard verzoeken per seconde. Naast Google kregen ook Amazon en Cloudflare met de aanval te maken. De mogelijkheid van deze nieuwe aanval is gerelateerd aan het ontdekken van een kwetsbaarheid in het HTTP/2-protocol (CVE-2023-44487), die het mogelijk maakt om bij minimale belasting van de cliënt een enorme stroom verzoeken naar de server te sturen.

De nieuwe aanvalstechniek staat bekend als 'Rapid Reset' en maakt gebruik van de mogelijkheden van multiplexing die in HTTP/2 worden geboden, waardoor het mogelijk is om een stroom verzoeken te vormen binnen een al gevestigde verbinding, zonder nieuwe netwerkverbindingen te openen en zonder te wachten op bevestiging van de ontvangst van pakketten. De kwetsbaarheid wordt beschouwd als het gevolg van een tekortkoming in het HTTP/2-protocol, waarvan in de specificatie is vermeld dat bij het openen van te veel stromen, alleen de stromen die de limiet overschrijden, moeten worden geannuleerd, maar het volledige netwerkverbinding niet moet worden gesloten.

In navolging van eerder toegepaste methoden voor aanvallen op HTTP/2, worden er ook in de nieuwe aanval veel stromen binnen één verbinding gecreëerd. Het belangrijkste verschil in de nieuwe aanval is dat in plaats van te wachten op een antwoord, er na elk verzonden verzoek onmiddellijk een frame met de RST_STREAM-vlag wordt gestuurd, dat het verzoek direct annuleert. Het annuleren van het verzoek in een vroeg stadium helpt om terugverkeer naar de cliënt te vermijden en om de op HTTP-servers aanwezige beperkingen op het maximaal aantal stromen dat tegelijk binnen één verbinding kan worden geopend, te omzeilen. Op deze manier hangt het aantal verzoeken dat naar de HTTP-server wordt gestuurd niet meer af van de vertraging tussen het verzenden van het verzoek en het ontvangen van het antwoord (RTT, round-trip time), maar is het alleen afhankelijk van de bandbreedte van de verbinding.

Omdat het voor een aanval aan de kant van de klant voldoende is om simpelweg verzoeken te verzenden zonder antwoorden te ontvangen, kan de aanval met minimale overhead worden uitgevoerd. Bijvoorbeeld, een aanval van 201 miljoen verzoeken per seconde die door Cloudflare werd geregistreerd, werd uitgevoerd met behulp van een relatief klein botnet van 20.000 computers. Aan de kant de server zijn de kosten voor het verwerken van inkomende verzoeken aanzienlijk hoger, ondanks hun annulering, omdat er operaties zoals het toewijzen van datastructuren voor nieuwe stromen, het parseren van verzoeken, het uitpakken van de header en het matchen van de URL met de bron moeten worden uitgevoerd. Bij een aanval op reverse proxies kan de aanval zich uitbreiden naar de backends, omdat de proxy het verzoek mogelijk naar de backend kan omleiden voordat de RST_STREAM-frame wordt verwerkt.

De aanval kan alleen worden uitgevoerd op kwetsbare servers die HTTP/2 ondersteunen (een script om de kwetsbaarheid van servers te controleren, een toolkit voor het uitvoeren van de aanval). Voor HTTP/3 zijn er nog geen aanvallen geregistreerd en de mogelijkheid om deze uit te voeren is nog niet volledig geanalyseerd, maar vertegenwoordigers van Google raden ontwikkelaars aan servers maatregelen ter bescherming tegen aanvallen te implementeren in de HTTP/3-implementaties, vergelijkbaar met die ter blokkering van aanvallen op HTTP/2.

Kwetsbaarheid en aanwezigheid van patches voor HTTP-servers en proxies:

• nginx (aankondiging, verduidelijking dat de kwetsbaarheid zich niet volledig manifesteert in nginx in de standaardconfiguratie, omdat de aanval zal stuiten op de limiet voor het aantal verzoeken per verbinding (d.w.z. na elke 1000 verzoeken wordt de verbinding gereset). In de patch is er aanvullende bescherming toegevoegd door de intensiteit van aanvragen te beperken via de 'limit_req'-directive).
• In HAProxy is effectieve bescherming tegen het overschrijden van de limiet voor het aantal HTTP/2-stromen toegevoegd in 2018 en wordt deze toegepast vanaf versie 1.9-dev.
• Apache httpd (er ontstaat een bepaalde belasting op httpd, maar deze breidt zich niet uit naar de backends en blijft beperkt tot de geldende limieten voor clientverbindingen die sinds 2016 bestaan).
• mod_h2 voor Apache httpd.
• caddy
• envoy
• golang (probleem opgelost in versies Go 1.21.3 en 1.20.10).
• h2o (patch).
• grpc-go
• hyper (kwetsbaarheid manifesteert zich niet).
• jetty (opgelost in 12.0.2, 11.0.17, 10.0.17 en 9.4.53.v20231009).
• netty
• nghttp2 (opgelost in versie 1.57.0).
• Facebook proxygen
• .NET en ASP.NET Core (de kwetsbaarheid betreft de http-server ASP.NET Core Kestrel).
• Node.js
• proxygen
• swift-nio-http2 (opgelost in versie 1.28.0).
• Apache Tomcat (hersteld in versies 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
• Apache Traffic Server (hersteld in de 9.2.x tak).

Bron: opennet.ru