Mitigating recent HTTP/2 DoS vulnerabilities with BIG-IP

F5 Networks Threat Research team have been looking into the HTTP/2 protocol in order to assess the potential risks and possible attack vectors. During the research two previously unknown attack vectors that affect multiple implementations of the protocol were discovered.

SETTINGS frame abuse DoS 

In our research we found out that attackers can abuse the HTTP/2 SETTINGS frame by continually sending large SETTINGS frames that contain repeating settings parameters with changing values. Although the HTTP/2 RFC explicitly warns implementations from this possible DoS vector none of the implementations that were tested took this into consideration while implementing the protocol.

This attack is mitigated by BIG-IP as BIG-IP acts as a full-proxy and opens a new HTTP/2 connection to the application server and therefor SETTINGS frames received from the client will not be forwarded to the application server. Moreover, BIG-IP terminates idle connections when the connection idle timeout as configured in the HTTP/2 profile connection has reached.

Figure 1: Connection idle timeout setting in BIG-IP HTTP/2 profile

Additional References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11763

https://nvd.nist.gov/vuln/detail/CVE-2018-16844

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190005

https://nvd.nist.gov/vuln/detail/CVE-2018-12545

DoS via Slow POST (Slowloris)

Although Apache http server has a module named “mod_reqtimeout” which is enabled by default since Apache httpd 2.2.15 and supposed to stop all the variants of the Slowloris attack, we decided to check how well it mitigates the same attack vector over HTTP/2. Surprisingly, it turned out that the attack slips under the radar of “mod_reqtimeout” and makes the Apache server unavailable to serve new requests.

All Slowloris DoS variants are mitigated by BIG-IP as BIG-IP will only open connections and forward the request to pool members once a complete and valid HTTP request has been received. Since the requests transmitted during a Slowloris attack will never complete, no connections will be opened to the pool members. BIG-IP has also a possibility to mitigate Slowloris attacks by configuring “Slow Flow Monitoring” in its eviction policy.

Figure 2: Mitigating Slowloris attacks via BIG-IP eviction policy

Additional References

https://nvd.nist.gov/vuln/detail/CVE-2018-17189

 

Published Apr 22, 2019
Version 1.0
  • Do you have any example messages that are logged when the slow flow thresholds are breached?