SSRF with Filter Bypass via Open Redirection
Cybersec Café #9 - 04/15/24
Welcome back to Tuesday Long Form at the Cybersec Cafe with a deep dive into the hacker's realm this week. Join us every Tuesday morning as we unravel the different complex cybsersecurity topics and walkthrough different hacking techniques.
Objective
Utilize SSRF techniques to access the admin interface located at the local IP address http://192.169.0.12:8080/admin and delete the user carlos.
What is Server-Side Request Forgery?
Server-Side Request Forgery (SSRF) is a vulnerability that manipulates a web application to send unauthorized requests from the server's perspective. By exploiting vulnerabilities in the application's input mechanisms, an attacker can coerce the server into making requests to internal or external resources. SSRF poses a significant risk as it enables attackers to bypass traditional security measures and gain unauthorized access to sensitive resources.
Methodology
The Recon
We’ll start the Methodology with the Recon phase in an attempt to gain an understanding of the application and all of it’s features.
What we know going into this lab is that there is an administrator interface used to delete users located at http://192.169.0.12:8080/admin.
Based on the name of the lab, we’ll want to utilize an open redirection to take advantage of this vulnerability.
An open redirect is a vulnerability that occurs when a web page redirects a user to a URL without properly validating or sanitizing the target URL. Thus, an attacker can manipulate the redirection to either redirect themselves, or to utilize in attacks such as phishing.
Taking a look through the application, it looks like we have a store application filled with products, each linking to a details page:
There is also a login page, but we have no credentials to authenticate to the instance.
Delving deeper into the product pages, it looks like we may have some features of interest:
Check Stock: A POST request that checks the stock of a given product ID
Next Product: Navigates the the ID of a product passed into a path variable
We can see a rounded out Site Map here:
Both of these have peaked my interest, as the Stock Check seems like it would be vulnerable to SSRF given that it takes an API parameter, and the Next Product takes a path parameter, pointing to open redirection.
As we normally do to complete the Recon phase, let’s kick off some active scans on these two endpoints and start inspecting the requests.
Testing
As the scans run, we can kick off some manual testing by sending the Stock Check POST request over to the Repeater.
If we replace the stockAPI value with the location of the admin panel and encode key characters, we can test if the endpoint is vulnerable to SSRF.
Based on the response, it looks like this triggers an Invalid URL error.
It doesn’t look like this works as simply as we thought it would, so let’s turn our attention to the Next Product endpoint and experiment with the Open Redirection.
Send the Next Product GET request over to the Repeater and try injecting the location of the admin panel into the path parameter:
We can see this returns a 302 - very interesting…
It also pops up a Follow Redirection button.
Let’s go ahead and click it.
It looks like it points us to a GET /admin endpoint.
It doesn’t allow us to send this request in the Repeater, nor does it allow us to copy the URL and paste it in the browser.
Even attempting to copy and paste the original URL in the browser doesn’t work.
But there must be something here…
Let’s take a step back and try again with a combination of both endpoints we’ve explored so far.
Exploitation
Let’s consider what we know about the Stock Check Feature: It takes the endpoint of the application and calls that endpoint.
The Next Product endpoint is also an endpoint of the application.
So, what if we take the nextEndpoint along with the path parameter and inject it into our stockAPI parameter in the Stock Check?
First, shorten down the request to only include the necessary parameters. For this use case, it will be the path parameter:
GET /product/nextProduct?path=http://192.168.0.12:8080/admin HTTP/2
Now take this endpoint and inject it into the stockAPI parameter in the Stock Check request setup in Repeater:
Clicking Send shows that we get a response. Looking through, you can now see that the administrator panel is being displayed, and inside are some operations you can take as the administrator.
Searching through, we can see that there is an endpoint listed in the response to delete the user carlos.
We can take /delete?username=carlosand append it to the stockAPI parameter in the request we just sent.
We’re met with a 200 response - Lab solved!
What We’ve Learned
In this walkthrough, we’ve demonstrated the dangers of SSRF vulnerabilities in the absence of robust access controls. The Recon and Testing phases emphasized the importance of avoiding tunnel vision and adopting a holistic view of the appliction - don’t just fixate on one specific feature. Hacking takes some creative thinking - real life scenarios require outside-the-box thinking, and this lab serves as a great example of that.
Want to give the lab a try yourself? You can check it out on PortSwigger’s website here.
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!