Highly accurate Information Security Testing

SSRF’s up! Real World Server-Side Request Forgery (SSRF)

Introduction

In this blog post we’re going to explain what an SSRF attack is, how to test for it, and some basic guidelines on how to fix it. We will be using a real-world example, exploiting a vulnerability we discovered in a commercial Business Intelligence product called Dundas BI.

 

Following responsible disclosure guidelines, the vulnerability discussed in this blog post has been reported to the vendor and the vendor has released a patched version of the software. Shorebreak Security would like to commend Dundas BI for taking security issues seriously and rapidly addressing the vulnerability, and for also sending us a sweet care package full of schwag.

 

What is SSRF?

SSRF (Server-Side Request Forgery) is a type of vulnerability that allows an attacker to force an application to issue requests on behalf of the attacker, to unintended resources. The following diagram attempts to explain visually how this attack works:

Conceptually, the attack “encapsulates” a malicious request (request B) in an authentic request (request A), by means of manipulating the vulnerable feature. It is important to note here that “Target server(s), network(s)” can include both internal and external networks from the perspective of the vulnerable server.

 

Because of the nature of this vulnerability, these features will probably have some of the following characteristics (this list is not exhaustive):

 

SSRF exists when the server, as part of one of its features, fetches data or queries an internal or external resource. The key is that this request includes a value that the attacker can manipulate, potentially allowing the attacker to completely change the request being performed by the server.

 

This vulnerability is conceptually very similar to Remote File Inclusion vulnerabilities, which are very common in applications coded in PHP. These two vulnerabilities have a lot of overlap. You can use an RFI to achieve a lot of the same things you achieve with SSRF (port scanning, name resolution, etc.), but in a typical RFI vulnerable application, the goal is code execution. Usually, SSRF does not allow code execution, but it all depends on the particular implementation of the vulnerable code. It is common though, to leverage a SSRF vulnerability to attack internal applications.

 

Usually, SSRF is exploited to perform network scans or attacks against internal systems that may be hidden from the Internet, but accessible from the affected server. The usefulness of this attack will be very much dependent on the verbosity of the error messages returned by the server. For example, if the attacker modifies the request so that the server tries to fetch a resource from an Internet IP on a different protocol (i.e., making it request http://example.com:21, example.com having port 21 open with an FTP service listening) it would be necessary to see what the error message says. It could say “Request failed”, it could say “Connection timed out”, or even “Connection refused”. These error messages offer valuable information to the attacker which will be key to determine the result of the manipulated request.

 

After mapping out the server responses with their meaning, it is possible to start leveraging the attack. Usually, one of the interesting things one can do is write a Python script which will port scan the internal network, to gather insight into the target’s infrastructure. After mapping out the network, it is also possible to leverage the SSRF to perform targeted attacks against internal services. Normally, the malicious SSRF request performed by the server will be an HTTP request, so a common attack vector on internal networks are HTTP servers.

 

Again, the impact and the potential of this attack will be very much dependent on the particular implementation.

 

SSRF in Dundas BI

Dundas BI is a web-based analytics solution developed by Dundas Data Visualization, Inc. During one of our engagements, we found that this product was being used. After spending some time exploring the features and attack surface of the application, one thing caught our eye. One of Dundas BI features allows you to export what you’re seeing in the data dashboard to different formats. For example, the following screenshot shows how it’s possible to share the current dashboard as an image:

 

After submitting the form, the following POST request is issued:

It caught our attention that a parameter with the name “viewUrl” was being sent, with a value that appeared to be a relative URI:

 

“viewUrl”:”/Link/?shortLink=zwee6x6ojtxrjnu61najra8fdr”

 

It seems that this “shortLink” will be used as a shareable link, which you could send to other users in an easy way (we didn’t analyze how that short link is constructed/deconstructed, but it could be an interesting vector to study in another blog post).

 

The fact that the variable name included “url” in it made us think that this could be a good candidate for this type of vulnerability.

 

When you have a SSRF candidate, a good first test to do is the following:

 

  1.  Set up a controlled Internet (or internal if testing locally) facing web server.
  2.  Make sure you can see the request log for that server, (“tail -f /var/log/apache2/access.log” or the output from Python’s HTTP server module, or even just “nc -nlvp <80|443>”).
  3.  Try changing the variable value to something like “http://<your_webserver>/zzz”.
  4.  If you receive a request to “/zzz” after you execute the manipulated request, it is probable that the attack worked.

 

We performed the exact same steps in this case, setting the “viewUrl” variable with the value of “http://<our_ip>/zzz” and executed the “share as image” POST request.

 

Immediately, we received a request from the server!:

And yes, that’s the cookie value also being sent to the attacker.

 

After the malicious request was executed by the server, we checked what the response was from the actual server:

The server fails, revealing a stack trace detailing that the problem was that the resource was not found (HTTP error 404). After this first successful attempt, we started to further explore the application behavior to determine the potential impact of the vulnerability.

 

The next thing to test was sending the same request but modifying the “malicious” URL so as to test different ports, protocols, and hostnames. Interesting variations are the following:

 

 

After performing most of these tests, we were able to determine the following, given the verbose responses of the server:

 

 

So, this allowed us to create a set of scripts that scan networks (internal or external), resolve internal DNS names and eventually attack HTTP servers (internal or external) using the Dundas application as a proxy.

 

In this case, the SSRF request being performed is an HTTP request. So, for example, one could not use this vector to attack services that do not speak HTTP (unless the target service is terrible and fails when it receives unknown input).

Other interesting real-world examples

 

If you’re interested in reading about other examples of this attack, we’ve gathered a few write-ups that we found interesting:

 

SSRF Mitigations

There are three main strategies to follow when trying to address this vulnerability. Through some basic defensive techniques it is possible to prevent this attack or at least make it significantly more difficult for an attacker to exploit:

Disclosure timeline

Software: Dundas BI

Vendor: Dundas Data Visualization, Inc.

Affected version: < 5.0.1.1010

Vulnerability type: Server-Side Request Forgery

Severity: High

CVE ID: CVE-2018-18569

Date discovered: 09/18/2018

Date disclosed: 09/20/2018

 

Before disclosing publicly, Shorebreak contacted the vendor to report the vulnerability and allowed reasonable time for a fix to be released. The response by the vendor was immediate and a new version of the software which addressed this issue was released quickly.

 

 

Credit

Alberto Wilson and Guillermo Gabarrin of Shorebreak Security discovered this issue. For more information, contact Shorebreak Security at:

 

[email protected]