Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
Gal_Goldshtein
F5 Employee
F5 Employee

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.

0151T000003d7ejQAA.png

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.

0151T000003d7ekQAA.png

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

Additional References

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

 

Comments
Walter_Kacynski
Cirrostratus
Cirrostratus

Do you have any example messages that are logged when the slow flow thresholds are breached?

Version history
Last update:
‎22-Apr-2019 04:07
Updated by:
Contributors