SSRF
Notes about the walkthrough below:
Last updated
Notes about the walkthrough below:
Last updated
An SSRF vulnerability can arise when user-provided data is used to construct a request, such as forming a URL.
The typical situation of a web server using an external server to fetch resources:
So the goal is to use the web server to get resources we want from the victim server.
To execute an SSRF attack, an attacker can manipulate a parameter value within the vulnerable software, effectively creating or controlling requests from that software and directing them towards other servers or even the same server.
A basic SSRF can be employed against a local or an internal server. We will discuss both scenarios in detail.
The vulnerability can be like this: http://hrms.thm?url=localhost/copyright
. You can see inside the url the localhost/copyright
which is the internal server to get resources (PHP file in this case).
So, if we change what the server will fetch, we can maybe perfomr some unintended actions like read private files (config.php
for example).
Here the contents of the config.php
file by performing the SSRF:
We can now login with the admin credentials and do whatever we want!
This one is target web application which use internal server (192.168.x.x
or 10.x.x.x
for IPv4 or domain names (e.g., internal-database.hrms.thm
)).
To access to the admin panel (http://192.168.2.10/admin.php
) we get inside the config.php
, we can change the values of the filters as you can see below:
After that, we choose the filter with the modified value and BINGO! We have the admin login panel. To easily do it, go to BurpSuite and we juste need to put these values inside the request (don't forget the category
value to target the admin panel):
Out-of-band SSRF is a technique where the attacker leverages a separate, out-of-band communication channel instead of directly receiving responses from the target server to receive information or control the exploited server. This approach is practical when the server's responses are not directly accessible to the attacker.
For this challenge, the profile.php
page send information to the external page getInfo.php
. Because of that, we can't read what informations the page send to the external page. That's why this is a potential Blind SSRF.
The idea is to host our server with a script to get this data instead of getInfo.php
. Below, you have this script:
After running the script and put our IP server, we get a data.html
file with all the PHP info inside.
This is the same method. By observing how long it takes for the application to respond, the attacker can make educated guesses about whether their SSRF attack was successful.