{"uuid": "c7644a91-f18d-4fe0-9c6d-9442a66d6a65", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-44487", "type": "seen", "source": "https://t.me/hacking_Attack/122284", "content": "Black Hat Ethical Hacking\nMassive DDoS Attacks Exploiting HTTP/2 Rapid Reset Zero-Day Vulnerability\n\nMassive DDoS Attacks Exploiting HTTP/2 Rapid Reset Zero-Day Vulnerability\nPost Views: 1 Premium Content https://www.blackhatethicalhacking.com/wp-content/uploads/2023/07/Patreon.png Subscribe to Patreon to watch this episode.\nReading Time: 3 Minutes\nIn a collaborative effort to tackle record-breaking distributed denial-of-service (DDoS) attacks employing an innovative technique known as HTTP/2 Rapid Reset, tech giants Amazon Web Services (AWS), Cloudflare, and Google have taken swift action. These layer 7 attacks, which were initially detected in late August 2023, exploited a susceptibility tracked under CVE-2023-44487, with a CVSS score of 7.5 out of 10.\n\nThe essence of these attacks revolves around a zero-day flaw found in the HTTP/2 protocol, a fundamental component of modern web communications. Notably, HTTP/2 enhances efficiency through the multiplexing of requests over a single TCP connection, resulting in concurrent streams.\n\nHowever, the Rapid Reset attack capitalizes on a specific feature of HTTP/2. In the event a client wants to abort a request, it can issue an RST_STREAM frame to terminate the data exchange. Threat actors leverage this method to send and cancel requests in rapid succession. This ingeniously sidesteps the server\u2019s concurrent stream limit, effectively overwhelming the target without reaching its configured threshold.\nSee Also: So you want to be a hacker? Offensive Security, Bug Bounty Courses\nMark Ryland and Tom Scholl at AWS clarify this technique: \u201cHTTP/2 rapid reset attacks consist of multiple HTTP/2 connections with requests and resets in rapid succession. For example, a series of requests for multiple streams will be transmitted followed up by a reset for each of those requests. The targeted system will parse and act upon each request, generating logs for a request that is then reset, or canceled, by a client.\u201d\n\nWhat\u2019s most concerning is the ability to reset streams instantly, essentially enabling each connection to accommodate an indefinite number of requests in flight. This loophole allows threat actors to unleash a barrage of HTTP/2 requests that can overwhelm a website\u2019s capacity to respond to new incoming requests, effectively causing it to go offline.\n\nhttps://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_U63BEe0i4PMZO9Ro_WlR-waPi3QLKunyuJzEWBWWyyChxUHHKZ3VbR2nc2rDuliFbWsYcXJP0QoQcWqWzrLv_Gt9FTQYiiucMZAkbtHc0Zh9z_Moan_85io-rFAx-cCPl4ETEJD-SH-YR12voLZqUSOQCsfi264340yIqREw8wSp56a7TQkGdjiJdzdb/s728-rw-ft-e30/map.jpg \n\nCrucially, such attacks can be executed with a relatively small botnet, consisting of as few as 20,000 machines, as observed by Cloudflare.\n\nGrant Bourzikas, Chief Security Officer at Cloudflare, points out the magnitude of this vulnerability: \u201cThis zero-day provided threat actors with a critical new tool in their Swiss Army knife of vulnerabilities to exploit and attack their victims at a magnitude that has never been seen before.\u201d\nTrending: Necurs: Uncovering the Sophisticated Botnet Trending: Offensive Security Tool: Noir HTTP/2 is widely adopted, used by 35.6% of all websites according to W3Techs, and 77% of requests use HTTP/2 as per data from Web Almanac.\n\nGoogle Cloud has reported encountering multiple variants of the Rapid Reset attacks, some not as effective as the initial version but more efficient than standard HTTP/2 DDoS attacks. F5, in an independent advisory, recommends limiting the number of concurrent streams and persisting HTTP connections as protective measures.\n\nOrganizations are urged to proactively address this vulnerability, as Bourzikas emphasizes, \u201cAfter today, threat actors will be largely aware of the HTTP[...]", "creation_timestamp": "2026-09-02T01:01:06.378681Z"}