The world of cyberattacks and threats is a frantic uphill battle. On one side, there are the attackers who find new loopholes and ways to take advantage of them on a daily basis. On the other side, we have the experts who try to put a stop to the abuse and close all the “holes”. Recently, Google released more data about the largest Distributed Denial-of-Service (DDoS) ever, which tested the capabilities of Google’s security team. The service and the DDoS defense team managed to stop the attackers and their plans, but it was not easy…
What was most impressive about the attack was its size, but also the method that was used. The attack peaked at 398 million calls per second. During the attacks, the number of calls made in two minutes exceeded the number of Wikipedia articles viewed during the entire month of September, Google experts explain. For comparison, the largest DDoS attack last year had 46 million calls per second.
The attack first used a new technique that Google called HTTP/2 “Rapid Reset”. The method is based on stream multiplexing and has been used by several companies.
In the latest attacks from August, which continue to this day, various service providers are targeted, including Google services, Cloud infrastructure, and the company’s customers. Thanks to the ability to distribute the load and the infrastructure to defend against DDoS attacks, Google manages to defend itself against attacks without interruption.
Defending against attacks is the collective success of the entire industry, from cloud service providers to software maintenance. Google in collaboration with the entire sector implemented various defense strategies and a coordinated response to attacks. The collaboration resulted with various security patches and defense techniques that have been already implemented in the sector.
Distributed Denial-of-Service (DDoS) attacks are malicious attempts to disrupt the normal operation of servers, websites, computer networks, services by flooding them with Internet traffic. Attacks use compromised computers that flood systems with huge volumes of traffic. Attacked platforms cannot distinguish between real users and the network being used for the attack. Due to the lack of capacity, the systems lose the ability to process all the incoming calls. Attacks can result in victims losing customers or access to critical applications, ultimately costing them time and money.
Coordinated response for the CVE-2023-44487 vulnerability
The vulnerability CVE-2023-44487, which enables the HTTP/2 “Rapid Reset” attack, was discovered in August. Google immediately designed a strategy to reduce the risks and began coordinating with providers that implement the HTTP/2 protocol.
Security patches were soon issued and techniques developed, which were then used by many of the providers. Thanks to this, it is now known what the attack methodology is and the potential weaknesses that could contribute to new problems.
The spectrum of potential victims of the attack is quite wide. Web applications, services, server APIs or proxies that communicate over HTTP/2 are vulnerable to the attacks. One solution is to ensure that servers that support HTTP/2 are not vulnerable, and the second is to install patches that will limit the attack.
What is HTTP/2 Rapid Reset attack?
The HTTP/2 protocol allows clients to notify the server that the previous stream should be canceled by sending an RST_STREAM frame. The termination of communication is not coordinated and can be done unilaterally. The client can then continue as if the interrupt had occurred immediately, at the same time that the RST_STREAM frame was sent.
This allows the end users in the communication to send RST_STREAM frame immediately after the call. The other point in the communication in this case can start working and quickly reset the call. In this case, the HTTP/2 connection remains open.
The technique used for the attack is quite simple. As with a standard HTTP/2 attack, the attacker opens many streams at once, but instead of waiting for a response, he immediately sends an RST_STREAM. Thanks to closing channels, the attacker does not exceed the maximum number of open calls. The number of attacks does not depend on the round-trip time (RTT), but only on the network capacity.
The attack is further enhanced by the load asymmetry. The server will still need to complete operations for canceled calls, allocate stream data structures, parse the call and decompress the header, and on the other hand, almost no resources are needed for RST_STREAM, Google writes on its blog.
Although this is the most effective way of attacking, there are already several variants. One variant does not close streams immediately. Instead it opens multiple streams at once, leaves it for a while and then closes them all. This variant is not as effective as the first one, but it serves a certain role in the grand scheme of things.
The second variant doesn’t close streams at all, instead it tries to open more streams than the server reports. This allows the attacker to keep the entire capacity loaded at all times.
Photo by pixelcreatures, pexels.com
Hazard removal takes several forms. Most are focused on tracking statistics and various signals to determine how useful links are. For example, if the connection has 100 calls and 50% reset requests, then maybe closing will be a good solution. Some of the attack responses are different, from sending GOAWAY closure frames, to closing the TCP connection.
