Beginner Guide To Exploit Server Side Request Forgery (SSRF) Vulnerability
2021-10-11 15:32:00 Author: infosecwriteups.com(查看原文) 阅读量:54 收藏

Muh. Fani Akbar

Server Side Request Forgery (SSRF) is simply an attack where the server will make a request (act like a proxy) for the attacker either to a local or to a remote source and then return a response containing the data resulting from the request.

SSRF Illustration

We can say that the concept of SSRF is the same as using a proxy or VPN where the user will make a request to a certain resource, then the proxy or VPN Server will make a request to that resource, then return the results to the user who made the request.

From SSRF, various things can be done, such as:

  • Local/Remote Port Scan
  • Local File Read (using file://)
  • Interact with internal apps/service/network
  • RCE by chaining services on the internal network
  • Read Metadata Cloud (AWS, Azure, Google Cloud, Digital Ocean, etc)
  • Reflected XSS/CSRF

For the use of the lab in this blog post, only use the simple script below (of course maybe the application in Real World is not as simple as this) and will be deployed on Digital Ocean.

<?php
$url = $_GET['url'];
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER,1);
curl_setopt($curl, CURLOPT_TIMEOUT, 5);
curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 5);
$data = curl_exec ($curl);if(curl_error($curl)){
echo curl_error($curl);
}else{
echo "<pre>" . $data . "</pre>";
}
curl_close ($curl);
?>

Curl was chosen as the requester for this blog post because curl supports various protocols, so it's good for learning purpose.

requestster is a function or library that we use to fetch/request of the resource from input URL.

The purpose of scanning a port is simply to be able to map running applications/services behind that port so the attacker can identify what applications/services are running on that port. This becomes very important if the attacker wants to interact and then perform querying to internal applications/services.

Port scanning can be done using HTTP, HTTPS, GOPHER, or DICT protocols.

If there is a Blind SSRF to find out whether the port is open or closed, you can pay attention to Content-length, Response Time, or HTTP Status Code.

The indicator to find out, of course, is not just the three elements mentioned above, there could be “unusual” elements that appear during port scanning because it depends on what technology and what environment the web application uses.

HTTPS protocol if the port is open the response time will be longer because HTTPS will do the handshake, therefore the use of the HTTPS protocol can be a suitable choice for port scanning when faced with Blind SSRF

In the context of SSRF accessing/reading Local Files can only use the file:/// protocol, but not all requesters support the file:/// protocol. Besides, there may be a hard filter/blacklist that does not allow the use of that protocol, but still, it depends on the behaviour of the requesters.

To access the file itself, you can use file:/PathToFile , file:///PathToFile or file://hostname/PathToFile. The three access methods are valid URIs for file:///.

If the web application is deployed on Windows Server, to access files using the file:/// protocol, you can use file:///<drive_letter/PathToFile. Example : file:///d:/hello.txt

Interactive With Internal Service by SSRF

The real power of SSRF is where the attacker can interact with the internal application/service/network in Local Network, imagine if there is a vulnerable application/service in the internal network where the attacker cannot reach the application/service because it is on a different network, but if there is SSRF vulnerability the Attacker might be able to do that.

If the requester supports the use of the gopher:// protocol or there may be a CRLF Injection vulnerability, it will allow attackers to interact with various internal services such as SMTP, MySQL, Redis, Memcached and so on. Then querying these services to give the desired command, for example, to read local files or even to get RCE.

Gopher is classified as a universal protocol, through gopher the attacker can do smuggling to other protocols, besides that gopher also supports the use of newline (\r\n) so that even though the requestster is not vulnerable to CRLF Injection, the attacker can still perform CRLF Injection because Gopher does support multiline requests.

A blog post on how to interact with internal services can be read in separate material below:

There are various vendors that provide cloud computing services such as AWS, Azure, Google Cloud, Digital Ocean, etc. where these vendors provide Metadata access using REST API, but the REST API can only be accessed through the cloud network.

If a vulnerable SSRF web application is deployed in one of those Cloud Services, it will be very possible for an attacker to access Metadata information by exploiting the SSRF vulnerability.

Digital Ocean instance metadata

Digital Ocean instance metadata

References to REST API endpoints can refer to the official documentation of the cloud service provider used or can see the Cloud Metadata Dictionary useful for SSRF Testing by BuffaloWill.

Reflected XSS can occur if you are not faced with Blind SSRF.

XSS on Blind SSRF can happen if the requester supports javascript, for examples like PhantomJS and Selenium, then it’s not impossible for an attacker to do a DNS Rebinding Attack to “play” with internal services/networks.

List of requesters that support various protocols :

(Source: SSRF bible. Cheatsheet by Wallarm)

List some protocols that support for smuggling to other protocols :

(Source: SSRF bible. Cheatsheet by Wallarm)

  • Do a test whether the requester does the following redirect or not, so that the payload creation becomes easier, besides that it will also bypass if there are some parts of the payload that are hard filtered/blacklisted.
  • Always test various protocols such as GOPHER, FTP, SSH and so on.
  • Do a test of CRLF Injection, because this becomes important if the attacker wants to query the internal service
  • When faced with BLIND SSRF things like reading local files and reading metadata, there will be no other way to find out the response data, so the obvious solution is to do other things such as port scanning or interacting with the internal network so you can get RCE.

文章来源: https://infosecwriteups.com/exploiting-server-side-request-forgery-ssrf-vulnerability-faeb7ddf5d0e?source=rss----7b722bfd1b8d--bug_bounty
如有侵权请联系:admin#unsafe.sh