Blind SSRF that Leads To Port Scaning And Descover The Infrastracture

Today, I will talk about a Blind SSRF that I discovered in the final weeks (pray for me, I don't like summer courses).

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

First Step (Discovering the function)

There is a function that imports sound via a link. So I tried sending it a lot of links, and it fetched the data into a JSON response.

— -

The Normal SSRF

The first thing anyone would try is putting a Collaborator link and waiting for the HTTP and DNS interactions. But no, there was a WAF.

So I tried a popular way: using a redirection server where the DNS points to the Collaborator, and then… yeah, like our Indian brothers say, BOOM!!!! I got a DNS and HTTP interaction, hahaha :)

Yeah, it's a great step, but we still needed impact.

Note: We should know that the AWS IP of their server changed a lot, which means there is a load balancer. We should keep that in mind because it will help us later.

— -

Next Step: The Impact

I tried to connect to 127.0.0.1, buuut nooo. When we tried to use that payload, the response was a 403 Forbidden.

So I tried a lot of ways to bypass it, like:

• 127.1
• 127.0.1
• ::1
• 7F000001 (Hexadecimal)
• 2130706433 (Decimal)

And guess what? 127.1 bypassed the WAF!

But there was a problem: no data was fetched! That meant we had to do it the hard way: TIME-BASED.

— -

How We Got Our Impact

Of course, I tried port scanning the server.

And note that: 11 →20 seconds means it is not a live port. 1 →5 seconds means it is an LIVE port.

So I knew that ports 21, 3389, 80, and 443 were alive ports. I tried port 54321 to see if my theory was true, and it took 11seconds to respond. So yeah, I was right!

Now, I did the same for the internal network 192.168.1.0/24. I tried it in decimal form, from: 192.168.1.1 →3232235777 192.168.1.255 -> 3232236031

And found that 192.168.1.70 was alive.

When I tried to scan the ports, it was weird; sometimes a port showed as open, but in another scan, it didn't.

So, flashback to the note that there is a load balancer! I put all the requests into Burp Repeater and sent them as parallel requests. Now, we could accurately map and know the internal ports for 192.168.1.70 but it was inverse of the locall hoist

it triaged as a low impact but there still a discution with the triager

End

at the end we should say Alllhamdollah and see u soon in the next writeup

don't forget to follow me on

• inkedin
• facebook
• yeswehack