Hello everyone!
Hope you’re doing well
I’m gonna explain one of my latest findings on a Web Site’s API

About the Site:

The site that I was testing is a web-application that hosted on a linux server and Receives and processes a file as input using an API called “/files/input”

When the user sends the file to that API, the App will save the file in a temp directory on the server and assign a unique GUID to the file for tracking the state of the file on the server:

Using another API called: “/files/status/{guid}” the user can see the status of the process.

During the test I found out when I (as a user) send the GUID of my file to the API: “/files/status/{guid}” for retrieving the status of the process, the server will return the exact address of my file on the server and that was a good knowledge for me (as an attacker) to know where exactly my file is stored on the server-side:

There was no limitations for uploading HTML files on the server so I could upload my webshell on the server easily but I couldn’t access my web shell using the Browser because the temp directory had some limited permissions, it was created for the process and would be deleted after the process was completed

So I thought, it would be great if I could upload my Web Shell in another path that is accessible from the outside and not deleted.

During the crawling, I found out where the path of the main page of the site is, So, if I wanted the web shell to be accessible from the outside, I should have placed it in the location that the main page of the site is located.

So I decided to make some changes in the HTTP packet that I send to the server and I modified the “filename” argument of Content-Desposition header from this:

Content-Disposition: form-data; name="file"; filename="webshell.html"
Content-Type: text/html

to this:

Content-Disposition: form-data; name="file"; filename="../../../opt/main/site/webshell.html"
Content-Type: text/html

Note: These characters “../../../” are for going back 3 steps from the current location (temp directory) and be on the root directory of the server (that’s a linux addressing syntax) and upload the webshell on the site’s main page location which is /opt/main/site

And that’s it!

Our Web Shell is now uploaded and is accessible from the outside!

I didn’t go beyond this step and reported the bug, but bad things happen if the attacker can upload a file in a path that is not authorized for.

This bug has multiple reasons, one of the reasons is because of the unsecure code and the inputs that are not sanitized.
Probably there is a function on the server side that takes a string as an input and save it without checking the content of the string.

Have a great time Everyone!

More about me on: shellcode.ir

My twitter: yashar0x