Host validation bypass via connection state attack
Description
This lab is vulnerable to routing-based SSRF via the Host header. Although the front-end server may initially appear to perform robust validation of the Host header, it makes assumptions about all requests on a connection based on the first request it receives. Also see Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling: Connection state attacks.
Reproduction
Send the
GET /
request to Burp Repeater.Make the following adjustments:
Change the path to
/admin
.Change Host header to
192.168.0.1
.
Send the request. Observe that you are simply redirected to the homepage.
Duplicate the tab, then add both tabs to a new group.
Select the first tab and make the following adjustments:
Change the path back to
/
.Change the
Host
header back tolab-id.web-security-academy.net
.
Using the drop-down menu next to the Send button, change the send mode to Send group in sequence (single connection).
Change the
Connection
header tokeep-alive
.Send the sequence and check the responses. Observe that the second request has successfully accessed the admin panel.
Study the response and observe that the admin panel contains an HTML form for deleting a given user. Make a note of the following details:
The
action
attribute (/admin/delete
)The
name
of the input (username
)The
csrf
token.
On the second tab in your group, use these details to replicate the request that would be issued when submitting the form. The result should look something like this:
POST /admin/delete HTTP/1.1
Host: 192.168.0.1
Cookie: _lab=YOUR-LAB-COOKIE; session=YOUR-SESSION-COOKIE
Content-Type: x-www-form-urlencoded
Content-Length: CORRECT
csrf=YOUR-CSRF-TOKEN&username=carlos
Send the requests in sequence down a single connection to solve the lab.
PoC
Exploitability
An attacker will need to exploit the lab’s behaviour to access an internal admin panel located at 192.168.0.1/admin
, then delete the user carlos.