DeSync Attack – Browser powered HTTP Request Smuggling

A new class of HTTP request smuggling attack made a researcher to compromise multiple popular websites including Amazon and Akamai, break TLS, and exploit Apache servers.

The research that opens the new frontier in HTTP request smuggling browser-powered desync attacks.

Traditional desync attacks poison the connection between a front-end and back-end server and are therefore impossible on websites that don’t use a front-end/back-end architecture.

This new technique causes a desync between the front-end and the browser, allowing an attacker to craft high-severity exploits without relying on malformed requests that browsers will never send.

This can expose a whole new range of websites to server-side request smuggling and enables an attacker to perform client-side variations of these attacks by inducing a victim’s browser to poison its own connection to a vulnerable web server.

Researcher was able to turn a victim’s web browser into a desync delivery platform, shifting the request smuggling frontier by exposing single server websites and internal networks.

Combines cross-domain requests with server flaws to poison browser connection pools, install backdoors, and release desync worms in turn compromising targets including Amazon, Apache, Akamai, Varnish, and multiple web VPNs.

The four separate vulnerabilities led to the discovery of browser-powered desync attacks.

The first, involving request validation, leverages a technique in which an attacker can use two requests down the same connection with a valid host header in order to gain access to the host in the second request, because the reverse proxy only validates the first host.

The second, first-request routing, is a closely related flaw which occurs when the front-end uses the first request’s Host header to decide which back-end to route the request to, and then routes all subsequent requests from the same client connection down the same back-end connection.

The third technique to detect connection-locked request smuggling by using a delay and reading the data early to decide if the front-end is using the Content length header and it will time out, which will signify the difference between connection locked HTTP/1 request smuggling and harmless HTTP pipelining.

A fourth vulnerability caused a desync known as CL.0/H2.0. Researcher was able to use this to compromise Amazon users’ accounts, enabling him to steal users’ requests and add them to his shopping list. He could capture all their requests, including tokens which could have enabled him to impersonate those users.

Most server-side desyncs can only be triggered by a custom HTTP client issuing a malformed request, but as proved with Amazon, it is possible to create a browser-powered server-side desync.

The full detsils of the research a available in the whitepaper and available here.