Simple Analysis of HTTP Request Smuggling Vulnerabilities

---

Generation of HTTP request smuggling vulnerability

In HTTP/1.1, the HTTP request smuggling vulnerability occurs because the HTTP specification provides two different methods to specify the end of the request location, namely the Content-Length and Transfer-Encoding headers, which respectively indicate the length of the body content and whether Blocking, when using these two methods at the same time, if there is ambiguity when the front-end and back-end servers process the header, the processing will be different, which will lead to request smuggling vulnerabilities, for example:

In the figure, since the front-end server does not support Transfer-Encoding blocks, all the data in the text is transferred to the back-end server due to Content-Length, and because the back-end server supports Transfer-Encoding, when it encounters 0, it stops receiving , the subsequent admin request is considered a new request, and the ambiguity between the two servers leads to the HTTP request smuggling vulnerability.

Classification of HTTP Request Smuggling Vulnerabilities

1. CL.TE: Front-end servers use Content-Lengthheaders and back-end servers use Transfer-Encodingheaders
2. TE.CL: Front-end servers use Transfer-Encodingheaders and back-end servers use Content-Lengthheaders
3. TE.TE: Both the front-end and back-end servers support Transfer-Encodingthe header, but the two servers handle Transfer-Encoding ambiguously

Harm of HTTP request smuggling attack

Since most of today's web applications use the form of HTTP server chains, sometimes for various reasons such as load balancing, multiple proxies or balancers are set up, and finally these server requests are forwarded to one or more back-end servers. These types of architectures can do great harm if they create ambiguities in how the server handles HTTP requests.

1. Session hijacking: Attackers can use HTTP request smuggling attacks to hijack user sessions and obtain sensitive user information, such as login credentials, session identifiers, etc. Attackers can use this information to impersonate users and perform unauthorized operations.
2. Identity masquerade: Attackers can pretend to be legitimate users through HTTP request smuggling attacks, bypassing some security mechanisms and protection measures. This could allow an attacker to gain unauthorized access, such as accessing restricted resources or performing privileged operations.
3. Sensitive information disclosure: Attackers can exploit the HTTP request smuggling vulnerability to leak sensitive information to third parties by injecting malicious requests. This information may include the user's personally identifiable information, financial data, business logic, system configuration, etc.
4. Business disruption: Attackers can use HTTP request smuggling attacks to disrupt normal business processes. For example, they can tamper or delete HTTP request headers, manipulate response content, hijack sessions, etc., causing applications to fail to work properly and affecting user experience and business processes.
5. Exploitation of Security Vulnerabilities: HTTP request smuggling attacks can be combined with other security vulnerabilities to cause more serious security issues. An attacker could exploit this vulnerability to perform other attacks such as cross-site scripting (XSS), cross-site request forgery (CSRF), server-side request forgery (SSRF), etc.

Confirm HTTP Request Smuggling Vulnerability

Confirmation of CL Vulnerabilities by Time Delay Technique

Since the front-end server uses the Content-Length header, and the back-end server uses Transfer-Encoding, the front-end server will only forward a part, and the back-end server has processed the first block, because there is no end character, so it will wait There can be a significant time delay in the arrival of the next block.

POST / HTTP/1.1 
Host: aiwin.com
Transfer-Encoding: chunked 
Content-Length: 3

1 
X

Take the above data packet as an example, the front-end uses Content-length, only 3 lengths of data are sent, and it is sent to 1, while the back-end uses chunked, which will always wait for the arrival of the next block, or the arrival of the terminator 0 .

Finding TE.CL Vulnerabilities by Time Delay Technology

Since the front-end server uses the Transfer-Encoding header and only forwards a part of the request, the back-end server uses the Content-Length header and waits for the arrival of the remaining content, and a time delay can also be observed

POST / HTTP/1.1 
Host: aiwin.com
Transfer-Encoding: chunked 
Content-Length: 6

0

X

For the above data packet, the front-end server uses chunked, which will forward to the text before 0, but the back-end server uses Content-Length, with a length of 6, and forwards to 0, with a length of only 3, so it will wait for the next 3 The length of the body arrives, causing a time delay

Confirm Vulnerabilities Using Differential Response Content

By smuggling the vulnerability, it is possible to interfere with the response packet of the correct request, and confirm the vulnerability through the response of the normal request.

CL.TE Vulnerability Confirmed by Differential Responses

For the following data packet, since the front-end server uses Content-Length, all the data is sent to the back-end server, and the back-end server uses Transfer-Encoding, the data stops after receiving 0, and the following GET request is received Thinking it was a new request processing, 404 Not Found was returned.

TE.CL Vulnerability Confirmed by Differential Response

The following HTTP request packet, since the front-end server uses TE, all data is sent to the back-end server without any problem, while the back-end server uses CL, only received 5e data, the following POST data is considered as a new one The request was processed by the backend server and returned 404.

Exploitation of Request Smuggling Vulnerability

Bypass URL access restrictions through request vulnerabilities

The following data packets are dropped by 403 when accessing the /admin page

Because there is a request smuggling vulnerability and a CL-TE vulnerability, the front end transfers all the data to the back end, and the back end uses TE. It stops after receiving 0, and the next request /admin is considered a new request. The host of this request is local, so 403 can be bypassed

Bypass client authentication through request smuggling vulnerability

Generally in https, as part of the TLS handshake, the server needs to provide a certificate to authenticate the client. The certificate contains a common name, which needs to match the registered hostname, and the client can use it to verify whether it is communicating with a legitimate server. .

GET /admin HTTP/1.1
Host: aiwin.com
X-SSL-CLIENT-CN: aiwin

Generally these CN headers are hidden from the user, if you can send the correct CN header and value, you may be able to bypass the access control even, in the frontend, if these headers already exist, the frontend server will overwrite them, so it is not very exploitable , and the smuggled request can bypass the front end and send it to the back end intact, bypassing the verification.

POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 64
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
X-SSL-CLIENT-CN: administrator
Foo: x

Trigger Reflection Model XSS

Check the page and find that the User-agent is inserted into the page, and verify that the reflected XSS can be triggered by modifying the User-Agent.

Generally, reflective XSS is not harmful to users. It can only be triggered in the websites you visit or through interaction with users. Adding the joint request smuggling vulnerability can cause other users to trigger reflective XSS when accessing any interface, without requiring any interaction with users. Interaction can easily cause a certain impact. The principle is that the use of a certain request header in the front-end page can trigger reflective XSS, and there is a request smuggling vulnerability of the CL-TE type. This form can be used.

Here, because the front-end does not support chunked, it receives Content-length, so the whole block of data is passed to the back-end server without any problem, and the back-end server receives TE, and stops receiving after receiving 0, and the following has not yet received , considered as an independent request, is cached in the server, and when a user makes a request, XSS will be triggered.

Web cache poisoning

Web page caching means that in order to reduce the load on the server, the server will cache some files such as CSS\JS, etc., so that they can be read during the next visit, without requesting the server again, but when a user sends some malicious requests to the server , the server will return the malicious server to the cache server. Therefore, in the cache mechanism, when other users access this interface, the malicious cache will be loaded, and there is a possibility of being poisoned.

Because the server has a CL-TE request smuggling vulnerability, it is possible to attack the server so that the CL-TE request smuggling specifies the POST path of the attack server for the next request.

Access the JS file, you can see that the malicious XSS statement constructed by redirection, the malicious redirection of the JS file to XSS is cached in the server.

Visit the shooting range page again, because of the caching mechanism, the server will request the JS file every time it enters the main page, and because the JS has been poisoned, it will request the redirected malicious JS file from the cache server, triggering XSS.

Apache mod_proxy configuration request smuggling attack

Certain mod_proxy configurations in Apache HTTP Server versions 2.4.0-2.4.55 can cause HTTP request smuggling attacks. When mod_proxy is enabled and a specific configuration of the RewriteRule or ProxyPassMatch module is enabled, when the rule matches certain parts of the URL provided by the user, Proxy request target error will be caused due to variable substitution.

For example, the following configuration

RewriteEngine on
RewriteRule "^/nssctf/(.*)" "http://example.com:8080/index.php?id=$1"; [P]
ProxyPassReverse "/nssctf/" "http://example.com:8080/"

The id here is set to $1. When the url we visit matches the regular one, the RewriteRule rule will be replaced, and a new request will be sent to the mod_proxy module, so that apache will generate a backend server for the request target.

The url characters here will be decoded, and CRLF injection can be performed. The id=0 and GET /flag.txt will be directly spliced ​​into the request message and sent to the backend server, resulting in request smuggling.

For specific analysis, see: Apache Request Smuggling Vulnerability