The web systems where the frontend accepts connections via HTTP / 2 and passes them to the backend via HTTP / 1.1 hhave been exposed to a new version of the "HTTP Request Smuggling" attack, It allows by sending specially designed client requests, to divide in the content of the requests of other users processed in the same flow between the frontend and the backend.
El ataque can be used to inject malicious JavaScript code in a session with a legitimate site, bypass access restriction systems and intercept authentication parameters.
The author of the study demonstrated the possibility of attacking Netflix, Verizon, Bitbucket, Netlify CDN and Atlassian systems, and received $ 56.000 in reward programs for identifying vulnerabilities. The problem has also been confirmed in F5 Networks products.
The problem partially affects mod_proxy on Apache http server (CVE-2021-33193), fixes expected in version 2.4.49 (developers were notified of the problem in early May and given 3 months to fix it). In nginx, the ability to simultaneously specify the "Content-Length" and "Transfer-Encoding" headers was blocked in the previous version (1.21.1).
The principle of operation of the new method of matching requests in traffic is similar to the vulnerability discovered by the same researcher two years ago, but it is limited to interfaces that accept requests over HTTP / 1.1.
The classic "HTTP Request Smuggling" attack was based on the fact that frontends and backends interpret the use of HTTP "Content-Length" headers differently (determines the total size of the data in the request) and "Transfer-Encoding: chunked" (allows you to transfer data in chunks) ...
For example, if the interface only supports "Content-Length" but ignores "Transfer-Encoding: Fragmented", an attacker can send a request that contains the headers "Content-Length" and "Transfer-Encoding: Fragmented", but the size en The "Length of content" does not match the size of the chunked string. In this case, the frontend will process and redirect the request according to the "Content length", and the backend will wait for the block to complete based on the "Transfer encoding: chunked".
Unlike the textual HTTP / 1.1 protocol, which is parsed at the line level, HTTP / 2 is a binary protocol and manipulates blocks data of a predetermined size. However, HTTP / 2 use pseudo-headers which correspond to normal HTTP headers. When interacting with the backend using the HTTP / 1.1 protocol, the frontend translates these pseudo-headers in similar HTTP / 1.1 HTTP headers. The problem is that the backend makes decisions about the analysis of the transmission based on the HTTP headers set by the frontend, without knowing the parameters of the original request.
Even in the form of pseudo-headers, the values "Content-length" and "transfer-encoding" they can be streamed, although they are not used in HTTP / 2, since the size of all data is determined in a separate field. However, when converting an HTTP / 2 request to HTTP / 1.1, these headers pass through and can be confusing to the backend.
There are two main attack options: H2.TE and H2.CL, in which the backend is fooled by an incorrect transfer encoding or a content length value that does not correspond to the actual size of the request body received by the frontend through the HTTP / 2 Protocol.
As an example of the H2.CL attack, the wrong size is specified in the pseudo-header content length when submitting a request HTTP / 2 to Netflix. This request leads to the addition of a header HTTP Content-Length similar when accessing the backend via HTTP / 1.1, but since the size in Content-Length is less than the actual, a part of the data in the queue is processed as the beginning of the next request.
Attack Tools have already been added to Burp's Toolkit and are available as a Turbo Intruder extension. Web proxies, load balancers, web accelerators, content delivery systems, and other configurations where requests are redirected in a frontend-backend scheme are susceptible to the problem.
Source: https://portswigger.net