HAProxy is a free to use server load balancing application or software addon. JFrog Security reported on September 7 2021, that a vulnerability in an Integer Overflow existed in versions 2.0 through 2.5 in the htx_add_header() and htx_add_trailer() due to a missing length check on the header name that makes it possible for an attacker to bypass all configured http-request HAProxy ACLs, and possibly other ACLs, to conduct an HTTP Request Smuggling attack. This attack allows an adversary to “smuggle” HTTP requests to the backend server, without the proxy server being aware of it.

The smuggled requests have various impacts, depending on HAProxy’s configuration and the backend web server configuration. It is reported that the execution of the vulnerability can or may:

• Bypass security controls, including any ACLs defined in HAProxy
• Gain unauthorized access to sensitive data
• Execute unauthorized commands or modifying data
• Hijack user sessions
• Exploit a reflected XSS vulnerability without user interaction

HTTP Request smuggling is based on interfering with the processing of HTTP requests between the frontend (i.e. HAProxy on a router) and the backend (being the server hosting the destination). An attacker typically exploits this technique by sending a specially crafted request that includes an additional request in its body. During a successful attack, the inner request is smuggled through the frontend, that considers it as only the request’s body, but in fact consist of an additional function hidden to the HAproxy frontend and is executed as a normal request by the backend.

In most cases, the smuggling technique is done by supplying both the Content-Length and Transfer-Encoding headers with contradicting lengths in the same request and aiming for parsing inconsistencies between the frontend and backend servers. In the original authors case, however, the attack was made possible by utilizing an integer overflow vulnerability that allowed reaching an unexpected state in HAProxy while parsing an HTTP request – specifically – in the logic that deals with Content-Length headers.

An important enabler condition that makes this class of attacks possible is that when the frontend server forwards HTTP requests to the backend, it uses the same established TCP connection instead of wasting time on opening and closing sockets. The requests are sent "back to back" and it is up to the backend server to decide where a request ends and the next one begins.

In our testing, the function can be protected against if the parse then reaches a server properly configured. However, where the server is a direct connection, ie no properly configured Apache or NGNIX, a direct Microsoft server port, then the execution is still possible.

As advised by HAProxy, the best solution is to upgrade to version 2.0.25, 2.2.17, 2.3.14 or 2.4.4 CVE-2021-40346, which provides a patch for such activity by adding size checks for the name and value lengths.

However, for security reasons HTTP traffic should by default be redirected to HTTPS, even if that needs to be done on the end server. This redirect will assist to remove the hidden execution where the patch above cannot be applied.

Recommendations If HAproxy cannot be immediately upgraded, HAProxy should have port 80 added as a https-redirect to rule "scheme https", or in the alternative, when accessing the end server, Apache or NGNIX redirect to HTTPS.

Where HAproxy cannot be upgraded at all, and a Https redirect is also not possible, due to say, vender firmware, the end server should be removed from HAProxy and the port dedicated in its connection to the end server until the hardware containing the firmware can be replaced. Even if this means web redetecting for clients.