Biggest DDoSes Of All Time Generated By Protocol 0-Day In HTTP/2
In August and September, threat actors unleashed the biggest distributed denial-of-service attacks in Internet history by exploiting a previously unknown vulnerability in a key technical protocol. Unlike other high-severity zerodays in recent years—Heartbleed or log4j, for example—which caused chaos from a torrent of indiscriminate exploits, the more recent attacks, dubbed HTTP/2 Rapid Reset, were barely noticeable to all but a select few engineers.
HTTP2/Rapid Reset is a novel technique for waging DDoS, or distributed denial-of-service attacks, of an unprecedented magnitude. It wasn’t discovered until after it was already being exploited to deliver record-breaking DDoSes. One attack on a customer using the Cloudflare content delivery network peaked at 201 million requests per second, almost triple the previous record Cloudflare had seen of 71 million rps. An attack on a site using Google’s cloud infrastructure topped out at 398 million rps, more than 7.5 times bigger than the previous record Google recorded of 46 million rps.
Doing more with less
The DDoSes hitting Cloudflare came from a network of roughly 20,000 malicious machines, a relatively small number compared with many so-called botnets. The attack was all the more impressive because, unlike many DDoSes directed at Cloudflare customers, this one resulted in intermittent 4xx and 5xx errors when legitimate users attempted to connect to some websites.
“Cloudflare regularly detects botnets that are orders of magnitude larger than this—comprising hundreds of thousands and even millions of machines,” Cloudflare Chief Security Officer Grant Bourzikas wrote. “For a relatively small botnet to output such a large volume of requests, with the potential to incapacitate nearly any server or application supporting HTTP/2, underscores how menacing this vulnerability is for unprotected networks.”
The vulnerability that HTTP/2 Rapid Reset exploits resides in HTTP/2, which went into effect in 2015 and has undergone several overhauls since then. Compared to the HTTP/1 and HTTP/1.1 protocols that predated it, HTTP/2 provided the ability for a single HTTP request to carry 100 or more “streams” that a server can receive all at once. The resulting throughput can lead to almost 100 times higher utilization of each connection, compared with the earlier HTTP protocols.
The increased efficiency wasn’t just useful for distributing video, audio, and other sorts of benign content. DDoSers began leveraging HTTP/2 to deliver attacks that were orders of magnitude larger. There are two properties in the protocol allowing for these new efficient DDoSes. Before discussing them, it’s useful to review how DDoS attacks work in general and then move on to the way HTTP protocols prior to 2.0 worked.
There are several types of DDoS attacks. The best known forms are volumetric and network protocol attacks. Volumetric attacks stuff incoming connections to a targeted site with more bits than the connection can carry. This is akin to routing more vehicles onto a highway than it can accommodate. Eventually, the traffic comes to a standstill. As of last year, the biggest recorded volumetric DDoS was 3.47 terabits per second.
Network protocol DDoSes work to overwhelm routers and other devices found in layers 3 and 4 of the network stack. Because they work on these network layers they’re measured in packets per second. One of the largest protocol attacks was one blocked by security firm Imperva that peaked at 500 million packets per second.
The type of attack carried out by HTTP/2 Rapid Reset falls into a third form of DDoS known as Application Layer attacks. Rather than trying to overwhelm the incoming connection (volumetric) or exhaust the routing infrastructure (network protocol), application-level DDOSes attempt to exhaust the computing resources available in layer 7 of a target’s infrastructure. Floods to server applications for HTTP, HTTPS, and SIP voice are among the most common means for exhausting a target’s computing resources.
READ MORE HERE
