Exploiting Server Side Request Forgery (SSRF) in an API
Not all API vulnerabilities are created equal. Server Side Request Forgery (SSRF) attacks are one of the most dangerous because they can affect web applications and their APIs. So dangerous in fact, it’s recently been added to the OWASP API Security Top 10, which you can read about here.
As the threat landscape continues to evolve, web application security must also evolve. Vulnerable code in a REST API that fails to validate user input properly can ultimately allow access to data or allow remote code execution on the web server hosting the API.
In this article, we’ll explore the ins and outs of SSRF, how it can be exploited, and provide tips for testing your APIs to help find such vulnerabilities.
What is Server Side Request Forgery (SSRF)?
Server Side Request Forgery, also known as SSRF, is a security vulnerability that allows a malicious threat actor to induce the server side of a web application or API to perform unauthorized actions.
This sophisticated form of attack involves tricking the server into sending a request to another machine through a network connection that the attacker may control, which could lead to sensitive data leaks, allow an attacker to gain access to files and resources, allow for remote code execution, or even cause the server to crash.
Like most often in application security, software vulnerabilities like SSRF get abused when we blindly trust user input.
SSRF attacks can be incredibly difficult to detect, and for this reason, they remain a significant threat to businesses today. Organizations need to take proactive measures to protect their web applications against the potentially devastating effects of an SSRF attack, including implementing proper security controls and conducting regular vulnerability tests.
Regular SSRF vs. Blind SSRF
A typical SSRF attack will allow an attacker to get feedback from the web app or API in the form of a response from the server, which typically includes the results of whatever unauthorized action was requested.
Blind SSRF attacks, however, are much more complex. Results from blind SSRF vulnerabilities can occur without any response from the server. This means an attacker may have little to no information on what happened. I previously wrote about how to use out-of-band application security testing (OAST) to find such vulnerabilities in APIs.
Sometimes an attacker can trigger partially-blind SSRF attacks. In these conditions, while they won’t usually get useful responses with results, they may leverage Content-Length, Response Time, or HTTP Status Codes from the HTTP response to track the success of their exploitation.
How to identify SSRF vulnerabilities in an API
Discovering server-side request forgery vulnerabilities is typically relatively easy, especially when the API’s traffic involves request parameters or payloads packed with complete URLs. However, some SSRF cases can prove to be more elusive and tricky to pinpoint.
To successfully bypass input validation within server-side code, you need to get crafty with how you tamper with potential fragments that could create an external request. By strategically tainting these fragments, one can potentially gain access to data tucked away in the raw response body. It’s a game of strategy and skill, so buckle up and get ready to play.
Let’s explore where you might find SSRF vulnerabilities.
Common Vulnerable Parameter Names
Back in the days when Jason Haddix worked at BugCrowd, he built a suite of extensions for Burp Suite and ZAP called HUNT suite that was designed to look for vulnerable parameters in web applications.
If you look in the config data for its SSRF scanner extension, you will find a wealth of security research already done on common parameter names, including:
dest
redirect
uri
path
continue
url
window
next
data
reference
site
html
val
validate
domain
callback
return
page
feed
host
port
to
out
view
dir
show
navigation
openDuring your recon, ensure you collect all parameter names in requests and look for these parameters when searching for sensitive information. They are a good indicator of a parameter that might be vulnerable to an SSRF attack. Send custom data tainting those parameters and see what happens.
You never know what may result.
Webhooks
APIs are crucial to modern software development, enabling seamless communication between different applications and systems. One way developers do this is by using outgoing webhooks.
An API might use a combination of user-controlled data and third-party service URL fragments to construct a URL it will call out to. By manipulating these webhooks, hackers can use an SSRF attack to gain unauthorized access to a server and potentially steal sensitive data or cause other damage.
Sometimes, a web application might allow a user to enter in URLs for custom webhooks to be executed when specific events occur. Companies like Zapier exist to aid in building workflow automation based on this sort of thing. As part of this, sometimes they include a feature to validate/test a given webhook URL entered.
This can usually be abused allowing an attacker to get the server to make requests to internal resources on the private network, verifying the existence of a host or service (aka cross-site port attacks), and even returning data when not expected.
File Imports
Many web apps rely on the need to import files. This might be a picture pulled from a social media profile, an online spreadsheet stored with a cloud provider, or maybe a text file from an external web source.
You get the idea.
Whatever it is, if the API relies on a URL to import a file, it may be vulnerable to server-side request forgery.
One easy way to test for this is to enter a URL of http://169.254.169.254, the typical cloud metadata service. If the expected file is in any way echoed out or stored for retrieval later, you will be able to see the results from the metadata service request.
Another way is to use localhost (127.0.0.1) and see if you can access resources that match the external web server with URL path traversal. If so, you may be able to use this as an attack vector to extract internal resources that normally aren’t served by the web server.
PDF Generators
If an API dynamically generates PDFs based on any input a user controls, it may be vulnerable to server-side request forgery.
An attacker can taint the data so that when the PDF is rendered, it may load arbitrary data in the form of server-side XSS. If that XSS contains javascript or embeds an iframe, it may be able to make requests to internal servers and store the results in the PDF.
My favorite example of this is a video Stok recorded when Nahamsec and friends hacked Lyft while ridesharing around New York in search of a great hot dog.
Ways to exploit SSRF vulnerabilities
While I quickly gave some examples earlier on testing for some forms of SSRF, there is much more you could do with it, depending on what you find.
Local/Remote Port Scanning
Local and remote port scanning are two methods commonly employed to exploit SSRF vulnerabilities.
Sometimes a remote port scan is called a cross site port attack. It looks to abuse private IP addresses to access the local network and the resources within through a targeted port scan on internal hosts.
Scanning ports remotely can be especially effective for attackers looking to exploit SSRF vulnerabilities. They can route their request packets through the vulnerable API’s server, making it appear as if the requests are coming from the server itself, thereby bypassing typical security measures that aren’t in place for access to the internal network.
As a simple example, imagine if you wanted to know if the API server may have SSH enabled on the internal network. If you found an endpoint vulnerable to SSRF in the url param, you might taint it with “?url=http://127.0.0.1:22” and see if it returns an SSH banner.
Local File Read
When looking at SSRF vulnerabilities, it’s good to think outside the box regarding what exactly is causing the server to make a request. If it is fetching a URL with headless server-side code or tools like curl or get, you may be able to leverage alternative protocols to access resources.
As an example, you may be able to replace the http:// protocol with file://, allowing you to access files on the server’s file system. Common examples include something like “?url=file:///etc/passwd“ on a ‘nix-based system or “?url=file://C:/boot.ini” on a Windows-based system.
Interacting With Internal Services
One of the exciting opportunities an SSRF vulnerability may expose to an attacker is the ability to access services on internal networks not externally visible on the application server’s network perimeter.
Think about it for a minute. How many back-end systems could an API server need to contact to complete a transaction? Maybe it needs to fetch short-term data from a caching system like redis or memcache. Then it needs to write long-term data to a datastore like MySQL or PostgreSQL.
All these internal resources start to come into play thanks to SSRF.
Remember earlier when I mentioned you could change the URL schema from http:// to file:// to access internal files? Well, in some cases, you can switch to more complex protocols like gopher:// to take this further and chain a whole bunch of expressions/instructions to interact with other systems in a single request. Here is an interesting write-up that showcases some security research that does just that.
Accessing Cloud Metadata
Most vendors that offer cloud computing services include access to a cloud metadata service. This service can usually only be accessed by back-end components to an internal IP:
- For most cloud services like AWS, Azure, Digital Ocean, RackSpace, HP, etc., this is usually
169.254.169.254 - For Oracle, it’s
192.0.0.192 - For Alibaba, it’s
100.100.100.200
If a server connects to it via HTTP, it can extract sensitive information, which is ripe for abuse through server-side request forgery (SSRF). This includes everything from configuration data to access tokens.
There is a great cloud metadata dictionary published in a GitHub gist by BuffaloWill that you can use during SSRF testing. A quick Intruder payload created in Burp Suite could try to abuse a potential SSRF vulnerability by replacing the target URL with inputs from that dictionary.
Ways to bypass SSRF Protection
As back-end SSRF attacks continue to abuse weak web apps and APIs, developers look beyond the security control of validating user input. New SSRF protections are meant to prevent attackers from being able to modify resources, gain access to a component’s file system, or query HTTP-enabled databases.
Of course, there are usually ways to bypass these protections if you know how.
Let’s cover a few examples.
Use Exotic URL Schemas
If developers don’t disable unused URL schemas, this is a perfect attack vector to abuse during SSRF testing. I previously mentioned legacy URL schemas like gopher:// and file:// that can be abused in this way.
However, the OWASP SSRF Bible publishes a list of other potentially dangerous schemas that can also be used. Some of my favorites include:
dict://
file://
ftp://
gopher://
ldap://
smtp://
telnet://
tftp://I’ve tried only these URL schemas. But the OWASP doc includes several others like expect:// that have been abused in the past to pwn entire PHP web apps. So it’s worth researching further to find what combination of URL schema support is available on your API targets.
Using Hostname Instead of IP
Sometimes developers try to be smart and block HTTP requests that might include known IPs for things like cloud metadata services and localhost (127.0.0.1).
However, these can sometimes be mapped to internal hostnames that aren’t filtered out.
A simple example is metadata.google.internal.
Another would be to use an external DNS service like nip.io that allows you to map pretty much anything to a wildcard DNS entry. Using hexadecimal notation, you could map 169.254.169.254 to a9fea9fe.nip.io. Or you could map 127.0.0.1 to 7f000001.nip.io.
Non-Standard IP Notation
Since we are discussing manipulating IP addresses in formats like hexadecimal, let’s not forget that we can abuse other non-standard IP notations.
Here are several examples that all resolve to 169.254.169.254:
- Hexadecimal –
0xa9fea9fe - Integer –
2852039166 - IPv6 –
::ffff:a9fe:a9fe - Octal –
025177524776
Open Redirects
And last but certainly not least is abusing open redirects to bypass SSRF user input filter protections. If we can host a simple script on a domain we can control and access with an HTTP redirect, we may be able to cause a 302 redirect to the internal servers we wish to access that might otherwise be filtered.
Conclusion
Server Side Request Forgery (SSRF) attacks are here to stay. They are now part of the latest revisions of the OWASP API Security Top 10, and for good reason.
A successful SSRF attack against an API may just be an HTTP request away. Are you ready to test for it?
By understanding how SSRF works and the different ways to exploit it within an API, developers can ensure web application security stays in focus as new application functionality is added to APIs, and API hackers can increase their testing methodology to include more robust SSRF attacks.
Give it a try and let me know what you find!
Want to find other resources on improving your API hacking methodology? Then make sure you download my free ebook on The Ultimate Guide to API Hacking Resources.
The post Exploiting Server Side Request Forgery (SSRF) in an API appeared first on Dana Epp's Blog.
*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/exploiting-ssrf-in-an-api
