Hard Server-Side Request Forgery (SSRF) A bypass method to RCE and Port Scan

In SSRF attacks, the attacker exploits a server’s ability to make requests by altering URLs or requests that the server is expected to process. This can grant the attacker access to resources that are otherwise inaccessible to a standard user, such as internal resources like databases, internal services, or even private APIs.

Generally, SSRF occurs when an application or server accepts user input that includes URLs or specific IP addresses without sufficient validation, allowing access to internal resources. For instance, if a server has an input form that allows a user to input a URL for processing, an attacker could exploit this feature by inputting URLs that lead to internal services.

A basic example of this scenario is as follows: Suppose a web application has a form where users can enter an image URL for processing. An attacker could input a local URL instead, such as http://localhost/admin. If the server processes this request, it may inadvertently expose sensitive internal data to the attacker.

Great! Now, I’d like to discuss how to identify vulnerability and bypass them.

Read JavaScript file : I meticulously reviewed each JavaScript file and discovered a path specifically used for rendering files, At this point, I faced an issue: I wasn’t sure which files the path could render. So, I began searching for files with various extensions available on the site.

2. Find file : I found files with the formats: png jpg ogg gif mp4 Unfortunately, whenever I tried any of these formats, I received a “Bad Request” response.

3. Not losing hope is the key to success : I began searching for other files on similar subdomains and discovered additional files with different extensions. I tested these files, and one of them returned a different response header, which led me to realize that this path was specifically intended for rendering that file extension. However, I still received a “Bad Request” response. ( file : *.obj )

4. Test Other server : I started trying various bypass methods but didn’t find a solution. Then, I began adding Burp Collaborator to the URL, yet I still did not receive any response from Burp Collaborator. Now, I need to test with my own server to see if it can send other packets.

5. Find packet : Yes! I realized that a specific TCP packet is being sent to me, but I am unsure which active service on the server is responsible for it. However, this isn’t too important. Now, I need to inject packets to proceed with a port scan, and I also have the main IP address of the site.

6. Port scan : I started conducting a packet injection attack, and by injecting a payload along with one of the response headers from the site related to TCP timing, I was able to perform a port scan.

payload :

GET /cgi-bin/rebind?file=//target.com:PORT/test.obj?\x00={\x90*1024} HTTP/1.1

Note! that I mean to repeat 1024 \x90

Host header response is Port ON :

X-USE-Time : 201 to 301

Host header response is Port OFF :

X-USE-Time : 401 to 601

So far, we have succeeded in identifying a P3 vulnerability. However, the story doesn’t end here. We have managed to uncover the main IP address of the site, and now it’s time to conduct tests on this primary IP.

Port Scan : Initially, I performed a port scan, I noticed that port 1091 is open and returns an HTTP response.Test Vulnerability : When I accessed it, I encountered a login page. I conducted an automated scan on the page and discovered a Log4j vulnerability, which led me to a very effective Remote Code Execution (RCE) exploit.

3. Other Vulnerabiliy : After submitting the RCE report, the story didn’t end there. I downloaded the HTTP page source from the server and began reading and testing for other vulnerabilities. I successfully executed attacks such as HTTP Request Smuggling, XSS via POST request, Authentication Bypass due to misconfigured tokens, and Open Redirect. However, none of these were rewarded, as after accepting the RCE report, they wanted to close the open port on the server. When I checked yesterday, I found that they had indeed closed the port.

I was able to obtain rewards for both a P1 and a P3 vulnerability from this process. I apologize for not being able to share the HTTP requests and other information, as I was not granted full permission to disclose the vulnerabilities.

In the realm of cybersecurity, the journey from identifying vulnerabilities to exploiting them can be both challenging and rewarding. This experience not only underscored the importance of thorough testing and investigation but also highlighted the ever-evolving nature of security measures. Despite the challenges faced — such as the closure of the open port after reporting the vulnerabilities — each step provided valuable insights and knowledge. As security professionals, we must remain vigilant, continuously adapting and learning in order to stay ahead in this dynamic field. The discoveries made during this process serve as a reminder of the critical role that ethical hacking plays in safeguarding systems and maintaining robust security postures.