Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

HTTP Smuggling is an attack that attempts to smuggle in HTTP requests to bypass security controls. Most of the time, this comes down to a misunderstanding of the HTTP protocol between two endpoints. However, this can come down to abnormalities in an implementation as well. This is going to be a plethora of things that don't feel like that go together lolz.

A connection can be reused in HTTP. The author found that the HOST header was only validated in the first of the connections but not future ones.

Another trick was that the Amazon Application Load Balancer was automatically forwarding the Transfer-Encoding: chunked header if the CL header wasn't there in HTTP. Since browsers automatically add this header with HTTP/2 anyway (even if it's not required) this caused a trivial desync. The surprise on this is unreal!

In some cases, the server completely ignores some headers. While testing a site for this (CL.0 smuggling), the front-end will use the CL but the back-end doesn't care. This led to a very simple attack where the back-end would see the second request from a server as the body of the first request. What's freaky, is that this could be done via a browser!

The above attack was possible because the service wasn't expecting a POST request at all. The author decided to check in other locations where this desync could be possible. They found that amazon.com/b was vulnerable to this attack, leading to the response queue getting poisoned. This allowed them to get authentication tokens by receiving the wrong response.

Client-side smuggling had been born - a request to a single server (with nothing else running) to make something bad happen. Even worse, some of these can be called from the browser, making a drive-by CSRF attack possible with this.

A CSD vector is a HTTP request with two key properties. First, the CL must be ignored. THis can happen with errors (long URLs, weird encoding, etc.) or a POST request that wasn't expected. Secondly, a web browser must be enable to trigger this cross-domain, which is limited by the amount of things we have access to in the browser.

The trick to determining if the CL is not being used is to use an overlong Content Length. If this returns fine, then you may have an issue. To further determine if you have found a bug, send multiple HTTP requests down this pipeline to send multiple requests at once. The article includes a nice script for the Chrome dev tools to see if you have found a problem via Connection Id tracking.

With the Connection pool poisoned on a cross-origin request, what can we do? If the website has user storage, then using the end of one request to save a victims request would allow for the saving of cookies and other things. Because we can poison the response queue, we can launch things like header XSS and other things.

A real world case study was Akamai ignores CL headers on a redirect. By making a POST request to this endpoint, the queue is poisoned, since the BODY of the message is ignored. The first complication is the redirect getting followed; this can be stopped by disabling CORS to resolve an error. The second problem is that browsers will discard the connection if too much data is received. To get around this, make the request take more time by adding a cache buster in it.

Another case study shows a client side cache poisoning using the smuggling method for JavaScript files. By sending back the poisoned file once and then navigating to this page, we can add our own JavaScript to the page.

The author found another form of desync by pausing connections as well by abusing misguided request-timeout implementations.

There are tons of way to desync HTTP servers, with this being explored from previous posts. There are many other ways to cause these issues and exploit them in the future. Absolutely amazing research!