Server-Side Request Forgery (SSRF) allows internal ports scanning

Hi everyone, I am socalledhacker, i am a security researcher , penetration tester, certified ethical hacker and a web3 noob. In past months, I have discover lots of bugs but in today’s article we are going to discuss about Server-Side Request Forgery (SSRF) allows internal ports scanning, which i discover recently so without further delay let’s start….

Server-Side Request Forgery (SSRF) allows internal ports scanning

Recently I was hunting on a large wide scope program and i found an interesting server side request forgery bug in form field and then i escalate it to make it’s bigger impact, so let’s dive into how i found this bug and how you can try to find this similar issue on other applications.

Let’s say the program name is example.com and there is a subdomain like helpdesk.example.com in this subdomain user can submit their queries by filling a form, I thought that there is a possibility of SSRF there. So, i fire up my burpsuite and put my collaborator URL in first, last name, subject, description and also insert collaborator URL in description insert link section, and submit the form.

Surprisingly, multiple HTTP request hit to my collaborator so at the point SSRF is confirmed but it’s a P4, as there is not much impact of it, then i was curious that which field of the form is vulnerable to SSRF, so i put collaborator link in this format like collab.link.ostify.com/name, collab.link.ostify.com/subject, collab.link.ostify.com/description etc. and i found that subject field is vulnerable to SSRF.

But there is a problem in this, as the form is using HTTP Post request method so in this case data exfiltration is difficult because in post based request there is no data comes form server. So i tried port scanning and i got success in this when i hit multiple close ports i got DNS queries which i later found out that when a port is close i got only DNS queries but, on port 80 and port 25 which are open ports, i got HTTP and SMTP queries respectively.

Remember while trying SSRF always put your collaborator link in every input field and for post based request try port scanning and also use other methods of data exfiltration.

As always POC time 🙂

Description:- SSRF vulnerability allowing attacker for internal port scanning through specific DNS and service request behaviors. By leveraging SSRF, attacker is able to differentiate between closed and open ports on internal services.

When the SSRF request is directed at a closed port, only a DNS query is triggered, as no response from the service is received.

For open ports, a full service request is generated, which is detected on the collaborator endpoint.

This behavior enabled identification of open services based on response patterns:-

Port 25 (SMTP) – Received SMTP-specific data on the collaborator.

Port 80 (HTTP) – Received HTTP requests on the collaborator.

Steps to reproduce:-

1. Open this url in browser. ( https://example.com/support/tickets/new )
2. Fill the submit request form and put your burpsuite collaborator URL in subject field and fill the rest form with test data and click submit.
3. Now check your burpsuite collaborator and you will see that DNS and HTTP request hit in collaborator, and this is a SSRF vulnerability
4. Now to scan port, again fill a new submit request form and this time use your burpsuite collaborator URL with port like this xdec54tyfdfgl7s95ujvg8c2skmyd44svnjc.oastify.com:25
5. If port is open the you will get request form specific request like for port 25 and 80 you got SMTP and HTTP queries in collaborator respectively, and if port is closed then only DNS query hit in burpsuite collaborator.

Impact:-

1. Internal Network Reconnaissance: By using SSRF to probe internal ports, an attacker can map the internal network’s structure and identify which services are running (e.g., HTTP, SMTP, databases). This knowledge of accessible internal services is valuable in crafting further attacks.

2. Exposed Services Exploitation: Once internal services are identified (e.g., HTTP on port 80 or SMTP on port 25), the attacker could attempt to exploit known vulnerabilities in these services, especially if they’re outdated or misconfigured.

3. Privilege Escalation & Data Exfiltration: If the attacker can find a way to gain access to sensitive internal resources or configurations, they might escalate privileges within the internal network or exfiltrate sensitive data. This could affect Google’s internal resources and potentially have indirect consequences for end-users if any user-related data is accessible.

4. User Data Compromise: If sensitive data or user-related information is accessible within the internal services, a sophisticated attacker might leverage this SSRF to target and access that data.

That’s it for this article I will upload more articles related to web2 bugs covering all p4 to p1 bugs in near future so stay tuned… 🙂

Buy Me a Coffee : https://buymeacoffee.com/socalledhacker

Follow Me On :

• LinkedIn
• Medium
• X
• GitHub