Server-Side Request Forgery (SSRF) is classified by the MITRE ATT&CK framework as a type of Initial Access technique, the first step in a multistage attack. While it is currently less well-known than other techniques, the Open Worldwide Application Security Project (OWASP) has noted that the incidence and severity of SSRF are increasing. Due to the increasing number of cloud services and the complexity of architectures, security teams should educate themselves on SSRF attacks and how to prevent them.
What is an SSRF attack?
SSRF attacks take advantage of flaws in web applications, enabling threat actors to make an organization’s application behave in unintended ways. The technique has been featured in the OWASP Top Ten due to the potential impact it can have on an organization’s security posture. Attackers manipulate the vulnerable web application into making requests to other applications, even when they are behind a firewall, VPN or other forms of network segmentation.
Diagram showing the flow of a basic SSRF attack
Common use cases of SSRF attacks
- Scanning the ports of internal servers within the network to map internal networks.
- Collect sensitive data by accessing local files such as /etc/shadow or /etc/passwd.
- Access the metadata of cloud services that is stored within the network.
- Conduct Remote Code Execution (RCE) to compromise servers on the local network.
- Create operational downtime by launching Denial of Service (DoS) attacks.
Examples of recent SSRF attacks
In the last three months there have been several notable SSRF techniques that have been discovered:
- Microsoft revealed that Cuba ransomware threat actors were attacking unpatched Microsoft Exchange servers using SSRF using a known vulnerability (CVE-2022-41080).
- An SSRF vulnerability (CVE-2023-23560) in Lexmark printers was given a CVE severity rank of 9.0.
- Four SSRF vulnerabilities in Azure cloud services were patched by Microsoft.
How an SSRF attack works
Server-Side Request Forgery attacks take advantage of the implicit trust between applications, with the target application automatically treating every request from the vulnerable application as legitimate. In addition to basic SSRF, there is also a class of the technique called “blind SSRF” that involves the attacker manipulating the target application without any responses being returned.
SSRF is typically done by manipulating an application to create requests to another resource using URLs. The example below shows how “Snappy” the innocent-looking website screenshot application could be manipulated.
import requests
from flask import Flask, request
app = Flask("Snappy - A Website Screenshot Application")
# Hadles a webserver endpoint
@app.route("/post/<screenshotUrl>")
def madeScreenshot(screenshotUrl):
# The requested URL is directly used to create the request.
response = request.get(screenshotUrl)
# ...
# Code to create a screenshot from a reponse.
# ...
#Returns a screenshot of the requested resource directly back to the user.
return webpageImage
Code of an application that screenshots websites
In this code example, line 10 creates a request based on the URL supplied by the user in the /post/<screenshotUrl> endpoint. This input is directly used and unsanitized, no other application level protections have been used either. This can be used to gain access to the local network by sending the application the address to the loopback network interface of the server (localhost or ‘127.0.0.1’) or to the IP of a system within the network.
Recommendations
The Open Worldwide Application Security Project has provided a handy cheatsheet which should be shared and reviewed by your security team. Using the cheatsheet as a guide, the team should create an action plan for reviewing and remediating potential vulnerabilities. However, in many cases identifying all of the applications that could be exploited by SSRF and accurately ranking them by severity is a timeconsuming task. Hadrian recommends that a scan of your attack surface is conducted to immediatly reveal which vulnerabilities that pose the greatest risk.
