SSRF Series — The Appetizers

What’s SSRF?

SSRF or Server Side Request Forgery is a vulnerability where an attacker is able to get the server to call an unintentional URL. Now there doesn’t seem any direct impact, however this could potentially be used to leak sensitive information/credentials or download malicious files leading to Critical vulnerabilities like RCE.

Impacting the server

Lets start with the most basic scenario — you find an API where a URL can be passed. The server gets the content from the URL and returns it back to her.

POST /v1/api HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
url=http://some-website.com

The attacker can do the following using the above API:

Bypass Authorization

• Change the URL to point to the admin page. Sometimes, authorization is bypassed knowing that the API call is from a trusted source.

POST /v1/api HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
url=http://localhost/admin

Leak Sensitive Credentials

• Considering the application is hosted on some popular cloud service, change the url to http://169.254.169.254 (AWS, Azure or GCP — refer this). The attacker can potentially extract credentials to gain access to the cloud environment!

POST /v1/api HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
url=http://169.254.169.254/latest/user-data

Scan Network

• An attacker can also use this to look for internal backend systems which are unreachable by normal users. Normally, internal networks will not be hardened against attacks assuming the efforts it would take to get in the system.

POST /v1/api HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
url=http://192.168.1.100/admin

Bypass Common Defenses

Now, even though many times its as simple as that! But sometimes, developers harden the defenses to make sure these can’t be exploited so easily.

Challenge 1: Identifying the parameter

One undeniably sure way of finding SSRFs is to try every parameter that comes your way and wait for the OOB response. However, one way to systematically perform it is Parameter Analysis.

I personally prefer to use tomnomnom’s gf to store/use these lists to identify if these are present in the APIs logged during recon, or to add these to the requests (check out: The Accidental SSRF).

Challenge 2: Blacklisted URLs

Usually, you would find the common URLs blacklisted. To bypass this, we can use the following bypasses here — PayloadsAllTheThings.

Every programming language and every library has a different way of parsing URLs. For e.g. in python, we can either use httplib, urllib, urllib2 or requests. For the below url, each library will resolve to different part of the URL!

Source: Orange Tsai, A new era of SSRF, Blackhat

Some more examples from 0xn3va:

foo@evil-host:80@expected-host
foo@evil-host%20@expected-host
evil-host%09expected-host
127.1.1.1:80\@127.2.2.2:80
127.1.1.1:80:\@@127.2.2.2:80
127.1.1.1:80#\@127.2.2.2:80
ß.evil-host

These are just some ways to exploit SSRF. More in upcoming posts!

Hope you enjoyed this. Thanks for reading. Follow for more!