Freely subscribe to our NEWSLETTER

Analysis

HTTP/2 is a seldom-used, essentially legacy application-layer protocol which implemented some of the performance- and scalability-related functionality later incorporated into QUIC, and which will be finalized in the upcoming HTTP/3 standard. As with HTTP/1.1, HTTP/2 client traffic is typically sourced from TCP/1024-65535 and destined for servers, services, and applications listening on TCP/80 and/or TCP/443. While encryption is not mandatory for HTTP/2 communications, all known web browser implementations require HTTP/2 requests and responses to be encapsulated in encrypted HTTPS communications sessions. From a network perspective, HTTP/2 traffic is virtually indistinguishable from HTTPS traffic.

While it is estimated that up to one-third of well-known websites may support HTTP/2 connections, its actual use on the production internet is so infrequent that it isn’t considered to be a mainstream internet protocol. Most web servers supporting HTTP/2 do so either inadvertently due to outmoded default configuration parameters, errors in configuration choices, or its default presence on shared service delivery infrastructure such as CDNs and SaaS providers. It was deliberately enabled on a relatively small number servers likely in the unrealized hope that HTTP/2 would prove to be a valid successor to HTTP/1.1.

To this last point, other HTTP/2 DDoS attack methodologies have been reported in the past, yet have not been widely employed by attackers due to the lack of widespread HTTP/2 support on most websites and web-enabled applications.
Collateral Impact

However, multiple well-known cloud computing, SaaS, and CDN providers such as those involved in this disclosure have been specifically targeted with this DDoS attack vector, apparently selected by attackers precisely because they broadly support HTTP/2 across their respective service delivery infrastructures by default. It is likely that many (or even most) of their customers (and the end-users of those customers) do not actively and consciously utilize HTTP/2. Even so, collateral impact often occurs to users of shared infrastructure whether or not they themselves specifically make use of shared protocols and service delivery elements which are successfully attacked.

Recommended Actions

From a DDoS defense perspective, HTTP/2 application-layer DDoS attack vectors should generally be mitigated utilizing the same NETSCOUT Sightline/TMS and AED techniques, countermeasures, and ATLAS Intelligence Feed (AIF) DDoS threat intelligence elements as HTTPS DDoS attacks. The specific recommendations made in our customer-facing ASERT Killnet Threat Advisory with regards to defending against HTTP and HTTPS application-layer DDoS attacks are also applicable in the context of HTTP/2 application-layer DDoS attacks.

Organizations operating HTTP/2-enabled web servers should follow the remediation steps outlined in the joint disclosure, including deploying relevant patched software versions and making recommended configuration changes.

It should also be noted that the majority of Web servers and applications supporting HTTP/2 likely do so either wholly inadvertently or on a legacy basis. While any changes to production applications and services should only take place after extensive consultation, testing, and coordination with the relevant parties, consideration should be given to the possibility of disabling HTTP/2 support entirely for sites and applications which are not deliberately utilizing it. In many cases, this would have the benefit of significantly reducing the DDoS attack surface, while having little or no negative impact on production services.

Such an effort may include requesting that any relevant cloud, SaaS, and/or CDN vendors disable HTTP/2 support for specific hosted applications/services/content. Again, any changes to production service delivery chains should only take place after appropriate consultation, testing, and coordination.

Organizations which are unsure whether a given web-based server, service, or application supports HTTP/2, and which do not have direct administrative access to the infrastructure in question, can use common network tools in order to determine whether HTTP/2 is enabled. The following is an example of using the curl utility to probe an HTTPS-enabled webserver in order to test for HTTP/2 support:

curl —http2 —http2-prior-knowledge https://www.example.com

Note that all relevant rules, regulations, laws, and policies should be followed with regards to such activities. Also, care should be taken to avoid imposing excessive load on production applications, servers, and services. The above curl command is only provided as an example, and we strongly urge organizations to exercise due diligence and take appropriate precautions when utilizing traffic-generation utilities and systems.

Conclusion

Post-disclosure, organizations may experience aggressive HTTP and/or HTTPS scanning targeting TCP/80 and TCP/443 as attackers attempt to identify HTTP/2-enabled websites and applications. Such scanning activity can actually constitute inadvertent DDoS attacks against resource- and defense-constrained servers, applications, and services. All relevant best current practices (BCPs) and recommendations included in our Killnet Threat Advisory (published internally to our customers) should be implemented on a situationally-appropriate basis.
Reference:

How it works: The novel HTTP/2 ’Rapid Reset’ DDoS attack