HTTP Desync Attacks: Request Smuggling Reborn

In a newly-confirmed Black Hat USA Briefing on HTTP Desync Attacks: Smashing into the Cell Next Door, security researcher James Kettle introduce techniques remote, unauthenticated attackers can use to splice their HTTP requests into others.

DSYNC is a cloud integration platform used to connect disparate systems together. DSYNC is data integration, transformation and mapping engine for pulling and pushing data.

HTTP request smuggling

HTTP Request Smuggling was first documented back in 2005 by Watch-fire, but a fearsome reputation for difficulty and collateral damage left it mostly ignored for years while the web’s susceptibility grew.

HTTP request smuggling is a technique for interfering with the way a web site processes sequences of HTTP requests that are received from one or more users. Request smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users.

Core Concepts

Since HTTP/1.1 there’s been widespread support for sending multiple HTTP requests over a single underlying TCP or SSL/TLS socket. The protocol is extremely simple – HTTP requests are simply placed back to back, and the server parses headers to work out where each one ends and the next one starts.

This is harmless. However, modern websites are composed of chains of systems, all talking over HTTP. This multi-tiered architecture takes HTTP requests from multiple different users and routes them over a single CP/TLS connection.

This means that suddenly, it’s crucial that the back-end agrees with the front-end about where each message ends. Otherwise, an attacker might be able to send an ambiguous message which gets interpreted as two distinct HTTP requests by the back-end.

This gives the attacker the ability to prepend arbitrary content at the start of the next legitimate user’s request. Throughout this paper, the smuggled content will be referred to as the ‘prefix’ and highlighted in orange.

Example:

That the front-end prioritizes the first content-length header, and the back-end prioritizes the second. From the back-end’s perspective, the TCP stream might look something like.

Post / HTTP/1.1

Host: example.com

Content-Length: 6

Content-Length: 5

 

1234GPOST / HTTP/1.1

Host: example.com

The front-end forwards the blue and orange data on to the back-end, which only reads the blue content before issuing a response. This leaves the back-end socket poisoned with the orange data. When the legitimate green request arrives, it ends up appended onto the orange content, causing an unexpected response.

In this example, the injected ‘G’ will corrupt the green user’s request and they will probably get a response along the lines of “Unknown method GPOST”.

Since the HTTP specification provides two different methods for specifying the length of HTTP messages, it is possible for a single message to use both methods at once, such that they conflict with each other. The HTTP specification attempts to prevent this problem by stating that if both the Content-Length and Transfer-Encoding headers are present, then the Content-Length-header should be ignored. This might be sufficient to avoid ambiguity when only a single server is in play, but not when two or more servers are chained together. In this situation, problems can arise for two reasons:

  • Some servers do not support the Transfer-Encoding header in requests.
  • Some servers that do support the Transfer-Encoding header can be induced not to process it if the header is obfuscated in some way.

If the front-end and back-end servers behave differently in relation to the (possibly obfuscated) Transfer-Encoding header, then they might disagree about the boundaries between successive requests, leading to request smuggling vulnerabilities.

How to Perform an HTTP request smuggling attack

Request smuggling attacks involve placing both the Content-Length header and the Transfer-Encoding header into a single HTTP request and manipulating these so that the front-end and back-end servers process the request differently. The exact way in which this is done depends on the behavior of the two servers:

  • CL.TE: the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header.
  • TE.CL: the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header.
  • TE.TE: the front-end and back-end servers both support the Transfer-Encoding header, but one of the servers can be induced not to process it by obfuscating the header in some way.

How to Prevent HTTP request smuggling vulnerabilities

HTTP request smuggling vulnerabilities arise in situations where a front-end server forwards multiple requests to a back-end server over the same network connection, and the protocol used for the back-end connections carries the risk that the two servers disagree about the boundaries between requests. Some generic ways to prevent HTTP request smuggling vulnerabilities arising are as follows:

  • Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection.
  • Use HTTP/2 for back-end connections, as this protocol prevents ambiguity about the boundaries between requests.
  • Use exactly the same web server software for the front-end and back-end servers, so that they agree about the boundaries between requests.

In some cases, vulnerabilities can be avoided by making the front-end server normalize ambiguous requests or making the back-end server reject ambiguous requests and close the network connection.

Leave a Comment

Your email address will not be published. Required fields are marked *

10 − eight =