Blind SSRF into Internal Port Scanning
Most of the time if you find the blind SSRF, try to escalate or dig more to increase the impact by showing the port scanning.
Hello Folks, In this article, I will explain SSRF → Internal Port Scanning.
What is SSRF ??
I answered this question in my previous blog, again I don’t want to repeat the same.
But today will see what are the possible impact that we can get from the SSRF and also I will explain one of my reports here!
- Sensitive Data Exposure — I explained this in my previous blog.
- Cross-Site Port Attack — We normally call it as an XSPA or Internal port scanning.
Let me explain this in more detail.
As we know, in recon we use NMAP for port scanning and fingerprinting.
But this can be done only if the target application exposes the ports to the public. What if the web server doesn’t show which services are used in the backend to the public?
Yes, Ideally while designing the application infrastructure, the architect will design in such a way that most of the internal services are not exposed to the public or the internet for security reasons.
Modern applications are scattered into various services such as SMTP Gateway, SMS services, Storage services ( popular such as S3, Azure blob ) Tomcat, and other services required to run the business.
By default infrastructure team will configure all services into a private subnet, which means outside the VPC ( Virtual Private Cloud ), no one can able to access these services.
Commonly web servers are placed behind the Web Application Firewall such as Cloud flare or Akamai etc. This will hide the actual server from the internet for security concerns.
3. Distributed Denial of Service Attack — The attacker can send a huge request to the target application, and makes the application unavailable to the user by consuming all the resources. Once the attacker found the Origin IP of the server by Blind SSRF, they can bring down the server via a DDOS attack.
I will write a separate blog on this attack.
Let's come back to today’s topic which is Internal Port Scanning…
If an application is vulnerable to SSRF, an attacker can send a forged request to the application and make the application induce internal services such as SMTP, Ports, etc., which the attacker can leverage to exploit it further and gain access to the various sensitive information behind the website.
Let's get Started !! 😉
I found the exact type of security bug on various applications, especially the application that has a URL functionality to make a call to the remote application.
Let's call the target application a https://vulnapp.com
As usual, I fired up my Burp suite and the browser. I opened the target application which is https://vulnapp.com and I quickly signed up for the application. After surfing most of the application, I ended up finding one API which makes the call to the remote path of another server, to download some analytical reports in PDF format.
Which looks like below:
https://vulnapp.com/down_report/?url=https://remoteserver.com
I forward the request to the repeater, and I quickly created the collaborator payload and replaced it with the remote server URL, which looks like
https://vulnapp.com/down_report/?url=https://unlcyjivqo6qxoeyzybwn4it0k6auz.burpcollaborator.net
Once I send the request with the collaborator payload, Immediately I received the HTTP callback to the collaborator client.
This confirms that the application was making the request to the collaborator and which we commonly called a “Blind SSRF”.
As you know. I usually don’t stop hunting, I always want to show more impact.
That is where I found the Internal port scanning.
Now, let's start with the second part of the testing. This time I replace the remote server URL with a loopback IP, which is http://127.0.0.1:80
And I got a 200 OK response from the server, which means I can able to make a call to port 80 which is an HTTP service, but not with a Fully qualified domain name or URL, but with a loopback IP.
This should not happen, the application should have the proper security control on calling the loopback IP.
Here I can able to do that…!! Again this confirms another level of SSRF.
Wooow……………………………….Great…………………………………………
Now I started scanning all the standard ports in the application.
Boom !!
I can able to do that. Instead of HTTP, I replaced the port with 22 ( SSH )
Yaaahhh…. I can able to see the SSH port banner or service version in the response.
That’s really cool !!
But still, the climax was not yet finished, I want to extract more details, I know if the application is vulnerable to SSRF, we can dump the metadata of the cloud service provider ( If it is hosted in the cloud ).
Note: I found this application is hosted behind the Web Application Firewall, during my recon phase.
I don’t know whether this application is hosted in a cloud environment or not ?? 🤷♂️🤷♂️
Randomly I went to the official AWS metadata documentation, and I copied the metadata URL:
Metadata URL
I pasted it into the remote server URL of the vulnerable API which looks like this:
https://vulnapp.com/down_report/?url=http://169.254.169.254/latest/meta-data/
Hahhhaahhhaa…..!! Yessssssssssssssssssssssss.
I got it….!!
Now, the Impact is critical.
Then immediately I started making the report.
Happy Hacking 🥂🥂
Thanks for reading.
Please follow me for more writeups.
