Introduction to HTTP Pipelining Abuse

What is HTTP Pipelining?

According to Wikipedia, HTTP pipelining “(…) is a feature of HTTP/1.1 that allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. HTTP/1.1 requires servers to respond correctly to pipelined requests, with valid responses even if not pipelined, even if the server does not support HTTP pipelining. Despite this requirement, many legacy HTTP/1.1 servers do not correctly support pipelining, forcing most HTTP clients to not use it. (…)”.

More complementary or relevant information:

• https://datatracker.ietf.org/doc/html/rfc2616
• https://developer.mozilla.org/es/docs/Web/HTTP/Connection_management_in_HTTP_1.x

Therefore, we could say that HTTP pipelining is a feature of the HTTP protocol in its 1.1 version, which allows processing (sending and receiving) multiple HTTP requests at the same time.

HTTP Pipelining Abuse

In this sense, after conducting many tests in bug bounty programs, pentesting, or ethical hacking engagements, I have finally come to the conclusion that YES is possible abuse HTTP pipelining to exploit potential security bugs (something that I questioned for a long time, so here it is and hopefully it will be useful to you).

Most, if not all, computer vulnerabilities are based on programming errors, lack of configuration (architecture), and/or abuse of default features.

What happens in an Abuse of HTTP Pipelining?

In modern computer system architectures, there are multiple components whose presence has become extremely important: API gateway, Proxy, WAF, Firewall, and many others; all of them, forming part of a complex management and processing of HTTP requests (receiving, validating, forwarding, filtering…)

It is in this context that it is possible to look for some strange behavior by abusing the process carried out by HTTP pipelining, and in this example case, use a 301 redirection to force an unknown component of the architecture to provide technical information about the host.

Real Case of HTTP Pipelining Abuse

Like most vulnerabilities, it is often necessary to chain several security issues together in order to demonstrate the impact or the exploitation itself.

In this example, I will demonstrate how to abuse HTTP pipelining by processing a standard permanent redirect of type 301, using a Host Header Injection (HHI) vulnerability for this purpose, to achieve a strange behavior in the architecture, resulting in a port discovery or scanning, or using HTTP pipelining as a calculator (😂).

As a side note, I identified this vulnerability in a digital asset owned by Google that is part of the bug bounty hunting scope.

The permanent redirect 301

As shown in the image, the domain *****.net redirects to the domain *****.com in a mandatory and permanent manner.

Host Header Injection (HHI)

For this particular HHI case, it is only exploitable by adding a letter /a as a GET parameter (I tried with other letters, and only this one worked -weird-), allowing the redirection of the domain *****.net to evil.com.

Verification of HTTP Pipelining Abuse

After trying some conventional methods for HTTP desync, I verify that the POST method is indeed enabled, and that HTTP pipelining maintains and processes the HHI vulnerability by forcing it in the first value of the Host header, using the routine *****.net-a, respecting the permanent redirect status 301, giving me a double HTTP response.

HTTP Pipelining Abuse

When exploring the chaining of HHI with the 301 redirection processed by HTTP pipelining, I obtained a rather strange response, in which the total number of existing ports is shown (65535), when using a crafted combination at the end:

In this way, it is possible to verify that during the processing of HTTP requests, using HTTP pipelining, there is a component in the system architecture that validates the number of characters as an int value for the specification of host ports. So:

11 characteres 1 = 65535

And by progressively decreasing the number of characters, HTTP pipelining starts acting like a calculator, listing and discovering other possible ports:

10 characteres 1 = 13767

Conclusion

To complement this idea of abusing HTTP Pipelining, not only does decreasing characters by 1 provide technical information, but changing from 1 to 2 and even combining different numbers also provides similar technical information.

It’s important to note that the abuse of HTTP Pipelining is commonly used in HTTP Request Smuggling attacks by default, but technically speaking, they are not the same.

The case demonstrated here is just an example of the potential behaviors that can be identified, depending on the computer architectures you have in front of you for security testing. Therefore, I recommend using HTTP headers to identify possible additional attack vectors.

Finally, it is possible to see how HTTP pipelining uses 301 redirection to force an unknown component of the architecture to provide technical information, such as host ports, or mathematical calculations such as addition or subtraction.