SSRF via flawed request parsing
Task
This lab is vulnerable to routing-based SSRF due to its flawed parsing of the request’s intended host. You can exploit this to access an insecure intranet admin panel located at an internal IP address.
To solve the lab, access the internal admin panel located in the 192.168.0.0/24 range, then delete the user carlos.
Attempt
The website rejects access when you modify a HOST header. But you can circumvent this by using an absolute URL in the request line.
Something like this will be accepted:
GET https://0a0a009303f52b4f80cf4ef500be00c1.web-security-academy.net/admin HTTP/2
Host: 192.168.0.1
Use Intruder to find out a correct internal IP address where the admin panel is located.
Once you successfully find it out, delete carlos. Note that you need to get a CSRF token from a response and add it as a URL query parameter:
https://0a0a009303f52b4f80cf4ef500be00c1.web-security-academy.net/admin/delete?username=carlos&csrf=Yy5rYC3CgWegxhXfAxaVMpVu6fW5xLYI
Notes
I usually set ‘Drop all out-of-scope requests’ to true to make my personal Burp setup closer to my work environment. But this time it caused quite an annoying problem. Thought requests were sent to https://0a0a009303f52b4f80cf4ef500be00c1.web-security-academy.net and I allowed any subdomain under .web-security-academy.net, when I changed the HOST header to 192.168.0.0/24 (note that you can’t actually use the CIDR notation in the HOST header, it should be like 192.168.0.1 for example), requests got blocked due to dropping out-of-scope settings. Oddly enough this only happens for Repeater but not for Intruder.
A takeaway is if you send a request and nothing happens, like absolutely no response is shown, check the event log and see what happens.