What is Detectify?

How to set up Docker for Varnish HTTP/2 request smuggling

August 26, 2021

If you don’t know about HTTP/2 request smuggling then what are you hacking? Alfred Berg, Security Researcher at Detectify, shows you how to set up an environment to test out HTTP/2 request smuggling.

One of the highlights from Black Hat USA 2021 and DEFCON 29 has been James Kettle’s presentation about H2 (HTTP/2) request smuggling. Inspired by this, I’ll show you how to set up a local environment that is vulnerable to HTTP/2 request smuggling CVE-2021-36740. I’ll also explain how it works with a PoC for the vulnerability. The git repository to follow along with this blog post can be found on Detectify’s Github page.

What is H2 request smuggling?

H2 request smuggling is essentially a variant of request smuggling, but instead of a confusion about the headers Content-Length and chunked encoding, H2 request smuggling takes advantage of H2 compatible proxies rewriting H2 requests into HTTP/1.1. 

One of the things that can go wrong in this conversion is that the content length is not required in HTTP/2 [rfc7540] due to H2’s frame structure. However, if an incorrect content length is specified in the H2 request and written to the new HTTP/1.1 request without any checks, a confusion can arise between the server where a request starts and ends. This can, for example,  make it possible to add prefixes to other users’ requests. James Kettle’s article goes more in- depth and covers more techniques.

Varnish cache was vulnerable to H2 request smuggling. This vulnerability was discovered internally by Martin Blix Grydeland, and there is now a patch and workaround out to fix it.

Setup

diagram http2

All that is needed to set up your own vulnerable environment is to clone the repository, cd into the folder and run docker-compose up. The environment mainly consists of four different web servers; a varnish server running a vulnerable version, a hitch server to terminate TLS since the open source version of varnish can’t handle TLS, and two origin servers. The origin servers consist of one default HTTPd server and one ncat listener that varnish sends requests to if the authority header (similar to the Host header in HTTP/1.1).

The ncat listener makes it easy to inspect what varnish sends to the TCP socket since it echos out all data it receives. Note however that docker-compose logs -t and docker-compose up will only output complete lines, so the last line of a request will be seen only after a new request comes in.

Let’s send some requests

When the environment set up, let’s send some requests. Open Burp and a browser that uses Burp as a proxy, and visit https://localhost/. Get a request similar to this into the repeater, and make sure that the protocol in the inspector is HTTP/2 and that Update Content-Length is unchecked in the Repeater settings.

See the request and responses in BURP

After sending that request followed by a normal request, this is what the ncat origin receives:

see the response in ncat origin

POST / HTTP/1.1
scheme: https
host: ncat
content-type: application/x-www-form-urlencoded
content-length: 1
X-Forwarded-For: 192.168.0.1
X-Varnish: 32769

aSMUGGLEDGET / HTTP/1.1
Host: ncat
X-Forwarded-For: 192.168.0.1
Accept-Encoding: gzip
X-Varnish: 32772

Due to the content length on the first request being 1, only the first byte in the body will be regarded as coming from the first request; the word SMUGGLED will instead be appended to the next request. This happens because the varnish server receives the HTTP/2 request and reads the whole body since content-length is not required in HTTP/2 [rfc7540] due to that H2’s frame structure. But when rewriting the request to HTTP/1.1, the incorrect content-length value is used.

When Changing the authority/host to localhost on the requests to make varnish send them to HTTPd, we can see that this is indeed the case. Note the cachebuster nocache=1 here to make sure that the request gets sent to the origin.

When Changing the authority/host to localhost on the requests to make varnish send them to HTTPd

This is just the beginning

This new research opens up the web app landscape and we’re expecting to see new web vulnerabilities stemming from this research.

Resources on web browser security and secure headers:


Written by:

Alfred Berg
Security Researcher at Detectify

How can Detectify help?

Detectify users are notified when web vulnerabilities are exploitable with real hacker payloads

Detectify web application vuln scanner UI

image: Detectify UI. Detectify collaborates with Crowdsource ethical hackers to bring you more than a DAST.

Detectify is a crowd-based web vulnerability scanner that goes beyond version and signature-testing. The testbed is payload-based and checks for actively exploited web vulnerabilities like HTTP request smuggling, OWASP Top 10, undocumented vulns, CORS misconfigurations and more. Curious to see what Detectify will find in your web apps? Sign up for a 2-week free trial today.