Exploiting SSRF, Nitty-gritty Details

Server Side Request Forgery vulnerability allows attacker to fetch resource while server acts as a proxy, in this blog I'll focus on scanning the internal network exploiting SSRF vulnerability.

In this post I found a service in Facebook which makes HTTP calls to user supplied URI call it A. This service will make a HTTP GET call to the A and print a response based on the response generated by the A server.

In the developer's section, Realtime Updates feature allows user's server to receive a ping from Facebook's server upon certain trigger

I submitted value for Callback parameter

  • http://domain:80/
  • http://domain:12131/

Port 80 is open while the latter isn't

Upon fetching port 80, this is the response generated from the server

Response does not match challenge

While non-exsistent port response

Callback verification failed:

Now, we have model to distinguish between open and closed port

Calculating the response-length,

Between : 4363 – 4365 : Port Open
Between : 4428 – 4430 : Port Closed

We can pivot it to scanning internal IPs ie. 127.0.0.1, 192.168.1.1,10.1.1.1 or 172.16.1.1

Facebook fixed the bug by adding rate limit to the input parameter

  • 22 - Jul - 2013 - Initial Report
  • 12 - Jan - 2014 - More Infomation Exchange
  • 16 - Jan - 2014 - Fix Pushed
  • 23 - Jan - 2014 - Reward assigned