{"id":110728,"date":"2023-10-11T03:10:14","date_gmt":"2023-10-11T01:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake"},"modified":"2023-10-11T03:10:14","modified_gmt":"2023-10-11T01:10:14","slug":"uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","title":{"rendered":"Kwetsbaarheid in het HTTP\/2-protocol, die betrokken was bij de grootste DDoS-aanval","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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\u00ebnt een enorme stroom verzoeken naar de server te sturen. <\/p>\n

De nieuwe aanvalstechniek staat bekend als 'Rapid Reset' en maakt gebruik van de multiplexingmogelijkheden die HTTP\/2 biedt om een stroom van verzoeken te cre\u00ebren binnen een reeds gevestigde verbinding, zonder nieuwe netwerkverbindingen te openen en zonder te wachten op bevestiging van ontvangst van pakketten. De kwetsbaarheid wordt beschouwd als een gevolg van een tekortkoming in het HTTP\/2-protocol, waarvan in de specificatie staat dat bij het openen van te veel streams, alleen de streams die de limiet overschrijden moeten worden geannuleerd, maar de hele netwerkverbinding niet moet worden gesloten. <\/p>\n

In navolging van eerder toegepaste methoden voor aanvallen op HTTP\/2, worden er ook in de nieuwe aanval veel stromen binnen \u00e9\u00e9n verbinding gecre\u00eberd. 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\u00ebnt te vermijden en om de op HTTP-servers aanwezige beperkingen op het maximaal aantal stromen dat tegelijk binnen \u00e9\u00e9n 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.

\"Kwetsbaarheid<\/center> <\/p>\n

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<\/a> 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. <\/p>\n

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<\/a> maatregelen ter bescherming tegen aanvallen te implementeren in de HTTP\/3-implementaties, vergelijkbaar met die ter blokkering van aanvallen op HTTP\/2. <\/p>\n

Kwetsbaarheid en aanwezigheid van patches voor HTTP-servers en proxies: <\/p>\n