Server Side Request Forgery

• 12 March, 2024
• No Comments

Server Side Request Forgery (What and Why)

SSRF a.k.a. Server Side Request Forgery is a web security vulnerability in web applications in which the user can forge server request to access unintended location usually these are request made to internal-only services within the organization’s infrastructure.

But in most of rare scenario requests may be crafted to connect external services to external systems leading to disclosure of sensitive authorization information. OWASP’s top ten web application vulnerabilities popularized Server Side Request Forgery in the year 2021.

Here’s a common example of SSRF attack scenario uploading file through URL. The application ultimately leads to a SSRF attack by parsing the URL.

POST /profPic/update HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

url=http://site.com/path-to-resource

This causes the server to make a request to the specified URL, retrieve the image, and update users profile picture.
In this example, an attacker can craft the request to specify a URL local to the server and try to access any internal service or resource on the server as shown below.

POST /profPic/update HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

url=http://localhost:3000/internal-service/admin

The server fetches the contents of the /admin URL and returns it to the user. An attacker can visit the /admin URL, but the administrative functionality is normally only accessible to authenticated users.The application grants full access to the administrative functionality, because the request appears to originate from a trusted location.

It might also be the case in some scenarios when users try to access static files on the server-side file system. For example, a user might try to access chat transcripts, images and documents saved in the application’s file system.

Impact of Server Side Request Forgery

A SSRF attack is difficult to find but its implication has a wide range from unauthorized access to remote code execution.

Listed below are a few of its impacts:

• Unauthorized Access.
• Information Disclosure.
• Data Theft.
• Arbitrary Command Execution.
• Decoy Issues.

Best Practices for Server Side Request Forgery:

Server Side Request Forgery is an attack vector that abuses an application to interact with the internal/external network or services or the machine itself. One mitigate this vector is by proper handling of URLs.
A few effective examples are shown here for preventing Server Side Request Forgery attacks.

• Proper handling of URLs meant to upload user pictures and files.
• Custom Web-hooks to handle web-hook handlers and callback URLs..
• Properly processing data while interacting with internal services cause most of data for interacting with these services is poorly handled.
• Blacklisting host-names like 127.0.0.1 and localhost or sensitive URLs like /admin or any such alternative representation like 2130706433, 017700000001, or 127.1.
• URL-encoded characters differently than the code that performs the back-end HTTP request.

The Challenge:

SecurityBoat hosted a CTF challenge in march, this time the application was same with some new features added and updating existing feature as per new vulnerability.

Overview and Initial Recon:

Most of the rules under the Rules section were same except few changes were there.
After a quick analysis of application we found some newly added feature in application like searching through the products on product list page, generate invoice of past orders in PDF format and update profile picture using URL.
URL for the challenge.

After visiting the challenge URL we will be landing on a webpage showed in following image.

Rules section can be seen as in following image.

Following the link we are taken to the rules page with a set of rules regarding the challenge, going through it we have in depth details of the challenge. After going through rules we didn’t got hint or any idea about the challenge but after checking the new changes or updates in application it was hinting towards or some sort Server Side Request Forgery challenge.

Challenge to find the flag

So with no further delay we started login to store using the registered credentials and moved to the very first new add-on or update feature which was updating profile picture entering user mentioned image URL.

The tool which we are using in this challenge to make things easy and we are comfortable with is Burp Suite. You can choose your own tool. Before providing update URL let us set our proxy and turn our intercept on in Burp Suite. In this way we will be able to know what all parameters are passed.

After submitting form and intercepting the request in Burp Suite the post request was shown in following screen.

After intercept the intercepted request we can clearly see that the URL which we provided is passed to back-end post API server/user.php and the parameter passed were named url and operation. Since the URL was passed to back-end for upcoming working task of downloading and fetch resource and then updating profile. Lets start with check how server side implementation is handling the request by crafting few payloads as follow.

• localhost
• http://localhost
• http://127.0.0.1 and so on.

After putting these payloads we got response from server shown in following images like only HTTP or HTTPS request were allowed and any internal request like localhost, 127.0.0.1 were also filtered and not allowed to pass and make request.

So now the task it find suitable HTTP request which will bypass the host-name and the second task to find the port number where the services running which is most suited location to get the flag since the challenge is for Server Side Request Forgery. So came across Server Side Request Forgery cheat sheet by Hactrix and using intruder of burp suite tried to craft the payload by passing host-name and port number.

At first kept the port range from 0-100 and then thought of increasing the range and attack payload range. At end came up with a payload using which we were able to bypass the filtration and also found an internal service running on port 81 and luckily the flag as well which was
{$$RF__!$__FUN} and payload to get the same was: http://0

In browser the flag was as shown below.

In the Search for next:

So from past experience of challenges hosted we will get back and try finding if we can find some other. Since 1st flag was found using Server Side Request Forgery which increases our chances of getting the flag in the new add-on of generating invoice of past orders.

As we can see whatever we enter in prompt is directly reflected in the report generated. Since our first flag we got our flag using which increases our chance of trying or checking what if we try passing HTTP request to internal server.

So why not trying the payload which we used the previous URL which we used to get the previous flag. So we did so and easy-peasy kaboom we got lucky got our next flag. The flag this time we got was in as shown in image below in PDF format.

After submitting the flag the with proper POC the moderator replied that this time they have came up with an extra hidden flag and which captured will increase the probability of winning the challenge. Sounded a bit off but adventurous as well.

Catch me if You Can Flag

So as the heading of this section is this flag was bit tricky. Not only it was in some unexpected location but also it required a effort to bypass the filtration. So since we were having knowing one search box was provided in product listing page.

Its normal mechanism was we have to enter name and click search button and the result was shown on same page by making an Ajax request to back-end API with reloading page. The matches it showed was based on even if any of term was present in the product title.

So we began attacking with our burp-suite intruder by uploading the list of payloads which consist of alternate representation of local host cause we already got an open port in our last flags and various various IP some of payloads we tried are list below and as in first flag only HTTP request were allowed.

• http://localhost:81
• http://127.0.0.1:81
• http://[::]:81
• http://0:81

Few response we got when we tried above payloads are as shown below.

So increased our attack payload list and finally found the way to bypass for filtration which was the decimal IP representation of payload in the blog written by one of the medium blog written by a security research on medium site whose link is provided in the reference section.
The payload which helped us getting the flag.
http://2130706433:81

Conclusion

This is how we got all the flags, thank you SecurityBoat for continuing the streak for hosting CTF challenge which is very rare in the community and giving us an opportunity to sharpen and letting us test our skill set. For this particular challenge I would like to mention Vickie Li’s Blog ‘SSRF in wild’ which came in handy for narrowing the scope of finding the vulnerability link for same i have mentioned in reference section.

For more such challenges

At SecurityBoat, we post various challenges and extend recognition, including rewards and shout outs, to the successful participants of these challenges. To participate in such challenges, follow us on LinkedIn,  Twitter, Facebook and Instagram. 

Our latest blogs and solutions to challenges are available here.

References

• OWASP
• PortSwigger
• Server Side Request Forgery Payloads
• Exploiting Server Side Request Forgery
• Server Side Request Forgery Workbook