SSRF That Allowed Us to Access Whole Infra Web Services and Many More

Basavaraj Banakar

Published in

InfoSec Write-ups

5 min readFeb 12, 2023

Hi this is Basavaraj back again with another writeup on SSRF.

This Writeup/Report/Bug will collaborated with my dost i.e Lohith Gowda

What is SSRF?
SSRF stands for Server-Side Request Forgery, which is a type of security vulnerability that allows an attacker to send unauthorized requests from a vulnerable server to other internal systems, potentially exposing sensitive information or executing malicious actions.

What can be achieved using SSRF?

Basically we can takeover the whole company in some cases(In this case too.)!

An SSRF vulnerability occurs when a server makes HTTP or other types of requests to other internal systems or resources on behalf of an attacker, using the vulnerable server’s network privileges. This can lead to unauthorized access to sensitive information, such as private network data, or to other types of exploitation, such as triggering denial-of-service attacks or even executing code on vulnerable systems.

We will try to keep this writeup as beginner friendly, So lets jump in directly into the topic.

This is an private program, And most of us(Indians) have used this application which has 50M user base.

We have an target called redacted.com and while browsing whole application as an normal user, We found that the one of the POST request is being made to example : /api/v1/json with request body parameter path and contain some json url as a value.

We removed the whole path value and replaced the value with my burp collaborator URL and here we confirmed the full read SSRF with call back on my burp collab listener.

Full read SSRF is present(But want to confirm by exploiting)

We got to know that web server is running on AWS, and I replaced the value with 169.254.169.254(aws metadata url) and I got the 403 response(Which is from cloudflare waf) and we got the confidence that we can bypass this, because the response is not from the server side (It is from waf).

And we explored some of the bypass techniques and many of them worked. and finally chosen one i.e converting the 169.254.169.254 to decimal value and the final URL will be http://2852039166 and by using this URL we successfully bypassed WAF.

Now accessed user data by hitting — /latest/user-data

Now accessed the IAM credentials by appending metadata paths.

Now Imported IAM credentials to AWS-CLI and executed the command i.e aws ec2 describe-instances (When you run this command, it sends a request to the AWS EC2 service to retrieve information about the instances specified in the command. This information can include details such as the instance ID, state, public IP address, instance type, and more.) and saved the output in out.txt

Extracting ec2 instance information

Now we created an bash script that takes the out.txt file and extract the IPv4 addresses from it, remove the duplicate IPv4’s and displays the output.

extracting IP’s and remove duplicate IP’s(i.e repeated)

Now we will run the script and count the number of IP’s which we have extracted i.e.

Totally 3774 internal+public facing IPv4's

Now its time to use burp intruder(You can use any) to bruteforce all of these internal IP’s using our vulnerable endpoint and host.

Paste the list of IP’s i.e 3774 and start attack

Now we got access to 200+ internal web services by bruteforcing the IP’s

Successfully Accessed 200+ internal hosts

We could have takeover the whole company via bruteforcing the internal IP’s with ports and that will be 225(internal hosts)*65535
(ports) = 14745375(Requests), but we didn’t performed that.

And here are some sample screenshots, That describes what we got access for