A specifically crafted HTTP request may lead the BIG-IP system to pass malformed HTTP requests to a target pool member web server (HTTP Desync Attack)

2019-08-29T05:50:00
ID F5:K50375550
Type f5
Reporter f5
Modified 2020-03-05T13:05:00

Description

F5 Product Development has assigned ID 761185 to this issue. F5 has confirmed that this issue exists in the products listed in the Applies to (see versions) box, located in the upper-right corner of this article. For information about releases, point releases, or hotfixes that resolve this issue, refer to the following table.

Type of fix | Fixes introduced in | Related articles
---|---|---
Release | 15.1.0 | K2200: Most recent versions of F5 software
Point release/hotfix | 15.0.1.1 | K9502: BIG-IP hotfix and point release matrix

Workaround

Depending on your BIG-IP configuration and features available, you may consider using one of the following mitigation methods:

Modifying or disabling the OneConnect profile

If the affected virtual server is configured with the OneConnect profile, you should consider adjusting the Source Prefix Length or Source Mask (11.x) setting of the OneConnect profile to prevent aggregation of HTTP requests from separate client-side TCP streams into the same server-side connection. Alternatively, you may consider disabling OneConnect for specific connections using an iRule or removing it entirely on the affected virtual server if your application environment permits. For information about using an iRule to disable OneConnect, refer to the ONECONNECT iRule command on DevCentral.

Impact of workaround: Depending on your application environment, adjusting the value of the Source Prefix Length or Source Mask setting of the OneConnect profile may impact optimal connection re-use, while disabling OneConnect may impact performance. For additional information, refer to K7208: Overview of the OneConnect profile.

Performing these actions on the OneConnect profile prevents the HTTP requests aggregation thus mitigating the risk of an attacker interacting with a legitimate client; however it does not prevent the target pool member web server from being subjected to potential HTTP Request Smuggling attacks. As a result, this may not be a complete mitigation and you may need to apply HTTP RFC compliancy checks using BIG-IP ASM / Advanced WAF (AWAF) in addition to this step.

Blocking malformed HTTP requests using BIG-IP ASM / Advanced WAF

If the affected BIG-IP system is licensed and provisioned with BIG-IP ASM / AWAF, you should consider configuring an appropriate BIG-IP ASM / AWAF security policy to block malformed HTTP requests. To do so, ensure that you have configured the following for your BIG-IP ASM / AWAF security policy:

Impact of workaround: Performing the following procedure should not have a negative impact on your system.

  1. Ensure the HTTP protocol compliance failed violation is set to Block with the following subviolations enabled:
    • Several Content-Length headers
    • Chunked request with Content-Length header
    • Unparsable request content

For more information about viewing and enabling these subviolations, refer to K10280: Overview of BIG-IP ASM HTTP protocol compliance.

  1. Ensure the following BIG-IP ASM / AWAF signatures are enabled:
    • HTTP Desync Attack Attempt, ID 200018061

Note: You must perform a signature update to the latest signature file (ASM-SignatureFile_20190906_010932.im) for this signature to be available on your system.

* HTTP Response Splitting (1)(Parameter), ID 200023001
* HTTP Response Splitting (2)(Parameter), ID 200023002
* HTTP Response Splitting (3)(Parameter), ID 200023003
* HTTP Response Splitting (4)(Parameter), ID 200023004
* Non-standard Transfer-Encoding header value, ID 200200002

For information about working with attack signatures, refer to K12885: Working with BIG-IP ASM attack signatures.

Note: This blog post link takes you to a resource outside of AskF5, and it is possible that the document may be removed without our knowledge.