An exciting journey to find SSRF , Bypass Cloudflare , and extract AWS metadata !

In the name of God.

Hi researchers,

This is my first write-up, and in this write-up i’m gonna share with you my recent exciting finding which led me to extract aws metadata !

I already know that most readers know what is ssrf but for a brief explanation let’s look at portswigger:

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing.

I was working on a program and since I have no permission to disclosure the name of the target , let’s call it redacted.com .

after a little bit working around this program I came to an endpoint which was some thing like this ~> https://redacted.com/api/download-pdf?url=”http://SomeThing.com”.

After seeing this url I was like :

I immediately fired up my burp collaborator and replace the default url with mine , fortunately my burp collaborator received HTTP and DNS requests and I got the burp page in response.

After , first thing came to my mind was, let’s put http://localhost there to get interesting response !

but I got :

There was a protection for this one , but i didn’t give up and i went through all the way’s to bypass localhost restriction , I tried all of these payloads :

http://127.0.0.1:80

http://127.0.0.1:443

http://127.0.0.1:22

http://127.1:80

http://0

http://0.0.0.0:80

http://localhost:80

http://[::]:80/

http://[::]:25/ SMTP

http://[::]:3128/ Squid

http://[0000::1]:80/

http://[0:0:0:0:0:ffff:127.0.0.1]/thefile

And lot’s of other’s which you can find in ~> https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery.

Even i tried other protocols like : “file:///” , “sftp://” , “gopher://” and so on .

None of them works ! :(

After a while something triggers my mind , that why not trying “http://169.254.169.254/” for retrieving AWS metadata instances ?.

So i did that and i got :

I continued researching till i found this one :

It might be possible that the server is filtering the original request of a SSRF but not a possible redirect response to that request. For example, a server vulnerable to SSRF via: url=https://www.google.com/ might be filtering the url param. But if you uses a python server to respond with a 302 to the place where you want to redirect, you might be able to access filtered IP addresses like 127.0.0.1 or even filtered protocols like gopher.

So i fired up my django server and insert this code to my server :

I sent this request and i got the prod then i put the prod in my django server after “http://169.254.169.254/latest/meta-data/iam/security-credentials/YOUR-PROD-HERE”,

And Finally I got :

After this I :

This is the end , Thank you for reading my article hope you learned something, and wish me to find more bugs like this to share with you ! ❤

My twitter : https://twitter.com/HoseinVita