On 1 June 2022, a Google Cloud Armor customer was hit with a Distributed denial-of-service (DDoS) attack over the Hypertext Transfer Protocol Secure (HTTPS) protocol that reached 46 million requests per second (RPS), making it one of the largest ever recorded Layer 7 DDoS attacks reported this year.
DDoS attacks target certain networks, flooding them with unwanted traffic from many different sources and causing interruptions to online services for legitimate users.
Google’s researchers said that the June attack was the equivalent of getting all the daily requests to Wikipedia in just 10 seconds and the attack continued for 69 minutes. The attack traffic came from 5,256 IP addresses located across 132 economies and leveraged encrypted requests (HTTPS), indicating that the devices sending the requests have strong computing resources.
In this post, I will review the different forms of this kind of DDoS attack, including HTTP/HTTPS flood DDoS, HTTP pipelining, and SSL renegotiation attack vectors, and share the best current practices for defending against them.
HTTP flood DDoS attack
HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web and is commonly used to send form contents over the Internet or to load webpages. HTTP flood is a layer 7 (OSI model application layer) DDoS attack method used by malicious actors to attack web servers and applications.
HTTP floods consist of a continuous legitimate session of HTTP GET or HTTP POST that GET and POST requests to a targeted web server. These requests are specifically designed to consume a significant amount of the server’s resources. To achieve maximum impact, malicious actors usually employ botnets — many devices infected with malware. Malicious actors may also use other HTTP methods such as PUT and DELETE to make the attack more complex.
In an HTTP GET flood attack, the GET request is used to retrieve static content such as image files, or some other asset from a targeted server. Typically, this induces a relatively low load on the server per request. But if the server’s limit of concurrent connections is reached, the server can no longer respond to legitimate requests from other clients attempting to connect, causing a denial of service. Figure 1 shows an example of a typical HTTP GET flood attack.
The POST request method requests that a web server accept the data enclosed in the body of the request message, most likely for storing it in a database. It is often used when uploading a file or when submitting a completed web form. If an HTTP POST handles data from the form and if it interacts with a database (for example, storing a file in a database) then it consumes more computing processing power and bandwidth compared with an HTTP GET. For this reason, HTTP POST flood attacks (Figure 2) are considered the most effective resource from an attacker’s perspective as it directly uses server-side complex processing.
How to analyse for HTTP flood attacks
Network protocol analyser tools such as Wireshark’s HTTP filter will show all HTTP-related packets.
http.request.method == GET or http.request.method == POST will show HTTP GETs or POSTs respectively. The user agent, other HTTP header structures, and the timing of each request are also reviewed to detect whether any attack is underway or not.
Recommendation
Because HTTP flood attacks use standard URL requests, it is challenging to differentiate from normal valid data traffic. Also, attackers can manipulate and forge senders’ IP addresses or user agent identifiers, which makes identifying attacks even more difficult.
One effective mitigation method is to use a combination of traffic profiling methods, including identifying IP reputation, keeping track of abnormal activity, and employing progressive security challenges. Using a verification process, such as resolving a CAPTCHA, is also useful to ensure legitimate requests are coming to the server. Finally, a Web Application Firewall (WAF) can also help protect from abnormal flooding of calls.
HTTP pipelining attack
The Google Layer 7 DDoS attack analysis notes that the attack matches the Mēris family of attacks, which uses the HTTP pipelining method to generate the DDoS activity.
Meris botnet was first detected in late June 2021 by QRator and Yandex. To launch volumetric attacks, the botnet uses SOCKS4 proxy on the infected device and then HTTP pipelining, which allows the botnet to send multiple requests over a single connection, increasing its total attack throughput.
HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. This avoids many round-trip delays and improves performance. The technique was superseded by multiplexing via HTTP/2.
Internet security company Imperva, recently announced it mitigated a single attack with over 25.3 billion requests where attackers used HTTP/2 multiplexing (combining multiple packets into one) to send multiple requests at once over individual connections.
When using HTTP pipelining, responses must be returned in the same order as the requests, so the server performs some extra processing to ensure this compliance. If an attacker sends a request that needs lengthy processing, for example, a database query, all proceeding requests/responses have to wait until this query finishes.
How to analyse HTTP pipelining
Figure 3 shows a typical packet capture of the HTTP pipelining method where frame eight shows a single TCP connection established with the server and multiple HTTP GET requests:
The server performs a lengthy response in the same order as the requests placed (Figure 4).
Recommendation
The ‘Connection‘ general header controls whether the network connection stays open after the current transaction finishes. If the value sent is set at keep-alive, the connection is persistent and not closed, allowing for subsequent requests to the same server. One of the mitigation actions that the system can choose to use is the ‘Connection close’ action, which eliminates the risk of HTTP pipelining and helps slow down attackers.
Most browsers (except one) don’t use pipelining, so this will be easy to recognize and mitigate because the TCP sequence is request-response and not request-request-request-response.
SSL renegotiation and HTTPS flood DDoS attack
HTTPS is a widely used extension to secure HTTP communication over a computer network. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS), formerly Secure Sockets Layer (SSL). IP-based protocols such as HTTPS, SMTP, POP3, and FTP, all support TLS for encryption.
How HTTPS works
HTTPS uses an encryption protocol to encrypt communications. It has an asymmetric public key infrastructure that uses:
- Private keys that may not be known by anyone except the owner. For example, web servers use it to decrypt information encrypted by the public key.
- Public keys that may be known to others. For example, anyone who wants to interact with the server.
The TLS handshake is the most computationally intense part of the process. The TLS 1.3 handshake starts with a Client Hello message after the completion of a successful TCP three-way handshake (Figure 5).
The client sends a Client Hello message to the server that contains a list of supported ciphers in order of the client’s preference (Figure 6).
After receiving the Client Hello, the server sends a Server Hello with its key, a certificate, the chosen cipher suite, and the finished message (Figure 7).
Once the client receives the server’s ‘finished’ message, it knows which cipher suite to use. At this point, the handshake is complete and the application protocol is enabled. Now both the client and the server communicate with encrypting messages.
SSL/TLS renegotiation
Starting a new handshake negotiation inside of an existing secure session is called renegotiation. Renegotiation takes place in the same TCP connection. If a client can initiate a renegotiation process, then the SSL/TLS renegotiation vulnerability should be considered a potential cyber threat because the renegotiation process consumes more resources on the server, around 15 times more than on the client.
Note: The renegotiation mechanism in SSL and TLS versions lower than TLS 1.2 is vulnerable.
The THC group demonstrated a DoS attack using this method and released a tool, thc-ssl-dos, as a proof of concept. This tool initiates a regular SSL handshake, and then immediately requests a renegotiation of the encryption key. The tool repeats this renegotiation request until all server resources have been exhausted. This attack further exploits the SSL secure renegotiation feature to trigger thousands of renegotiations via a single TCP connection.
How to analyse for thc-ssl-flood attacks
Figure 10 shows how an attacker opens numerous concurrent connections that contain the request cipher changes using the renegotiation process.
You can analyse for potential attacks by filtering for single IPs that send a huge number of new requests (such as Client Hello Wireshark filter tls.record.content_type == 22 or Change Cipher Spec Wireshark filter tls.record.content_type == 20).
Recommendation
Renegotiation is not possible in a TLSv1.3 connection so make sure you use the updated TLS version.
If renegotiation is not required, disable TLS/SSL renegotiation support on the server. If disabling renegotiation is not possible because of business needs, then allow only secure renegotiation and limit the number of TLS/SSL handshakes. Insecure renegotiation should not be supported. Vincent Bernat provides some useful information on how to limit the number of TLS/SSL handshakes.
Another mitigation technique is to upgrade server resources by adding products such as TLS acceleration. TLS accelerators may use off-the-shelf CPUs, but most use custom ASICs and RISC chips to do most of the difficult computational work.
HTTPS flood DDoS attack
An HTTPS flood is similar to an HTTP flood. It consists of legitimate sets of HTTPS GET or POST requests or combined GET and POST requests.
An HTTPS flood can overwhelm and saturate an SSL daemon and cause degraded server services due to the resources required to perform asymmetric encryption. The most common attack method involves creating a huge amount of HTTPS connections simultaneously directed at the target server to overwhelm its capabilities, therefore preventing legitimate clients from using the service.
How to analyse for HTTPS flooding
In Wireshark, tls.handshake.type == 1 will show all instances of Client Hello. If there are too many of these packets coming from the same source IPs, this could be an attack, as shown in Figure 11.
Recommendation
The general recommendation is the same as HTTP flood attacks — common DDoS attacks require traffic to come from many sources, but HTTPS DDoS attacks can originate from a small number of sources because such attacks require a secure TLS/SSL connection that directly uses server/victim computational resources.
As always, the recommended approach to preventing these types of DDoS attacks is to implement countermeasures that employ multi-layer detection control so targeted organizations can detect, identify, and mitigate DDoS attacks before the attacker reaches its target.
Debashis Pal is an Information Security Specialist from Bangladesh.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Effective
Excellent and Very informative For Data Center Administrator.