HTTP request smuggling: HTTP/2 opens a new attack tunnel

Technique dubbed ‘h2c smuggling’ takes advantage of HTTP/1.1 upgrades to bypass proxy access controls

Researchers have demonstrated an alternative to traditional HTTP request smuggling with an attack method to bypass proxy controls and access private endpoints.

First emerging on the web security scene in 2005, HTTP request smuggling has expanded to include variations of attack such as desynchronizing message processing and the abuse of both reverse proxies and proxy-proxy setups.

Upgrading vulnerable HTTP/1.1 connections to HTTP/2 or HTTP/3 can mitigate the risk of HTTP request smuggling. However, Bishop Fox lead researcher Jake Miller has explained that upgrade methods can also be abused.

In a blog post on Tuesday, Miller said the new method, dubbed ‘h2c smuggling’, impacts HTTP/2 over cleartext (h2c) connections.

According to the researcher, h2c smuggling can bypass reverse proxy access controls and feed “unrestricted HTTP traffic directly to back-end servers”.

HTTP/2 usage can be negotiated via TLS (TLS-ALPN) and is identified over the string h2. However, when HTTP/1.1 undergoes an upgrade to HTTP/2, an upgrade request can also be initiated under the Upgrade header over cleartext connections, identified by a string called ‘h2c’.

This h2c smuggling method allows attackers to bypass proxy controls by transmitting HTTP/1.1 upgrade requests via TLS, which goes directly to back-end servers (h2c upgrades made over TLS violate the protocol’s specification).

TCP tunnels

Miller configured an Nginx server with TLS termination on port 443 with a WebSocket-similar proxy_pass feature on the / endpoint to a back-end server supporting h2c upgrades. Access controls were set to block all requests to the /flag endpoint.

For the back-end, the researcher created an h2c-supporting Golang server.

Using a custom client – h2cSmuggler – made it possible to initiate an upgrade request over TLS rather than the Upgrade header and send to the NGINX reverse proxy.

“The proxy forwards the Upgrade and Connection headers to the back end, which responds with ‘101 Switching Protocols’ and prepares to receive HTTP2 communications,” Miller explained.

“Upon receiving the 101 response from the back end, the proxy ‘upgrades’ the connection to an unmanaged TCP tunnel.”

The h2cSmuggler client can use HTTP/2 multiplexing to send a further request for the restricted /flag. The proxy is not managing TCP tunnel communications at this stage, and so the request is sent to the back-end server without any barrier, leading to a response with the flag.

The researcher was then able to access the private endpoint – but it is worth noting that h2c smuggling does not allow for HTTP desynchronization, also known as socket poisoning attacks.

Trigger point

Two requirements are needed to trigger this form of attack – misconfiguration and a back-end that supports h2c upgrades.

Miller found that default configurations set by HAProxy, Traefik, and Nuster, for example, forward the required h2c headers by default – and therefore could be susceptible to attack.

It was also possible to perform the attack over some cleartext channels and multiple proxy layers. The only requirement is that the target proxy does not support h2c upgrade requests and will simply forward it on – therefore, the researcher says this attack “will likely succeed on non-encrypted channels as well”.

Bishop Fox has provided tools and demos for the attack technique on GitHub.

“Request smuggling and other proxy bypass vulnerabilities highlight a growing issue affecting modern web application architecture: an overreliance on edge-sever access controls for security guarantees,” Miller says.

“In many ways, arbitrary user-controlled requests through request smuggling or request forgery attacks have become the ‘hijacking the instruction pointer’ of modern, RPC-driven microservice architectures.”

Discussing the potential impact of this new technique, Miller told The Daily Swig: “For organizations that rely on proxies to enforce access controls, a bypass of these controls could lead to significant business impact.

“Bypassing these controls may lead to access to internal management endpoints, arbitrary request routing, IP spoofing, and a variety of other privilege escalation opportunities.

“By contrast, for organizations where an unfiltered request routed directly to the application has no more capability than a request processed by the edge-proxy, this would no longer present business risk. It’s contextual.”