scroll it
synack-blog1 (1)

Exploits Explained: Using APIs to Execute a Server-Side Request Forgery

SRT Community
0% read

A note from Synack: API security scanners can be useful to quickly identify potential API vulnerabilities through automated means. Automated scans rely on known exploit paths to probe their target, for example by using HTTP response status codes. But the results of a scan don’t always tell the whole story of a potential API vulnerability

In one scenario, a scanner may perform a normal function with “user A” credentials and attempt to simulate another user (“user B”) editing user A’s data. If the API does not return an error code (400), the scanner may flag the endpoint as being vulnerable to an Attribute Based Access Control (ABAC) vulnerability. This is an example of a vulnerability that a scanner could flag.

However, not all vulnerabilities can be found through automated means, some problems require human ingenuity to recreate what a potential adversary might do in an attack. Consider the following server-side request forgery (SSRF) vulnerability:

Cor3min3r is a member of the Synack Red Team and submitted the following Exploits Explained. You can reach out to him on LinkedIn or Twitter

While testing a new target, I found another interesting vulnerability that leveraged a video upload feature to reveal sensitive information. The vulnerability, a server-side request forgery (SSRF), allowed me to read internal files from a server, something that should be otherwise difficult or impossible to do. 

From PortSwigger: A server-side request forgery is a vulnerability that allows an attacker to access the server-side application to make requests to attacker-controlled locations. This can allow an attacker to access internal systems or perform actions that would normally not be accessible from the internet, including reading files, stealing data or executing arbitrary commands.

If you want to learn about SSRFs, check out:

HackTricks 

InfoSec Write-ups 

SSRF Vulnerability

I was on-boarded to a new target, an application used by a multinational chemical company. I started looking for interesting functionalities to explore, such as file uploads, video streaming and so on inside the application. I noticed that there was an option to upload video files that would then be streamed online.

SSF Vulnerability

Because it allowed for videos files to be uploaded, I thought there should be some sort of optimizing mechanism in place, such as ffmpeg, an open source software project used to format transcoding, do basic editing or video scaling, and other video operations.

Since the file upload functionality allows the user to stream video files, ffmpeg HLS processing issue comes into my mind. So using this tool from Github, I generated a payload to read the contents of /etc/passwd on the target server using the below command:

python3 gen_xbin_avi.py file:///etc/passwd outt.avi 

The Github tool created an AVI file with the malicious HLS playlist. To process the playlist, ffmpeg concatenates all segments and processes it as a single file. It then tries to show a screen capture of a TTY printing of this file.

I then uploaded the malicious payload outt.avi file to the server. (An outt.avi file is the output file from the tool.) After the file was uploaded, all of the contents of /etc/passwd were retrieved from the server and rendered in the video.

/ect/passwd


After confirming the vulnerability, I quickly made a report and submitted it to Synack. From there, Synack’s Vulnerability Operations team triaged my submission to check for validity and quality.  

How to Get the Best in API Security Testing  

The video uploading tool would return a 200 success code as long as a valid video file is uploaded. In this case, only a security researcher would be able to inspect the video output and confirm the success of the exploitation. Even if a scanner uploaded malicious video files, such as the one used in the exploit, it would not be able to verify that the contents of the video contain sensitive information. The inherent value of the Synack Red Team, our global community of 1,500 researchers, is the ongoing need for hands-on security testing performed by security researchers. Automated testing can only take an exploit so far, and further investigation to triage would need to be conducted by the security team.