By Jake Garner, Director, Technical Operations, Synack Inc.

As a technical director at Synack, I have had the pleasure of validating and accepting about 75 unique Server-Side Request Forgery (SSRF) and XML External Entity (XXE) vulnerabilities discovered by our extremely talented SRT researchers. These tend to be some of the more interesting reports to validate outside of the standard critical vulnerability categories like Remote Code Execution (RCE) and SQL Injection (SQLi).

Although some Infosec practitioners generalize the impact of these vulnerabilities, it is not always easy to determine risk without thoroughly testing them. The severity of these vulnerabilities varies widely, and I intend to explain why below.

Coming Up to Speed

I encourage you to become familiar with what SSRF and XXE vulnerabilities are before continuing with this article. My Synack colleague Trent Gordon did a great job explaining some intricacies of XXE here. I will focus on SSRF examples, but realize that there are similarities between these two categories. I encourage you to use owasp.org and I especially recommend this thorough Portswigger article as an additional reference.

For simplicity’s sake, an extremely common version of an SSRF exploit could be displayed in a diagram like so:

Here we show an attacker sending a request to a vulnerable server which instructs the server to make a request on its behalf. The vulnerable server made a request to a host on an internal network which would not normally be accessible to external attackers. The internal network host responds to the vulnerable server’s request, and then the server relays that response back to the attacker. There are many variations of this scenario, but this should serve as a simple example to build on.

Control, Visibility, and Environment Affect Exploitability and Impact

SSRF and XXE vulnerabilities give attackers a wide range of control. An attacker may be able to control the data, protocol, and destination of a request that a server makes, or they may be restricted to only controlling the destination domain or IP address. Usually with SSRF, the amount of control falls somewhere in the middle of these extremes. When an attacker has limited control over the request sent by the server, this restricts what can be accomplished and tends to lower the severity.

SSRF exploits’ visibility typically falls somewhere in between being full visibility and completely blind from the attacker’s perspective.

Full – An attacker has the ability to see (or at least predict) the full request and has the ability to receive a full response
Blind – the request made by the vulnerable server and/or the response delivered back to the attacker may not be fully visible, forcing parts of the exploit to be an educated guess

In a full SSRF vulnerability, an attacker can see and control much of the request data and can then receive a clear response. This usually results in a more impactful exploit than when an attacker does not have full control or visibility over their desired request and cannot receive the full response. Most exploits fall somewhere in between, offering some control and some visibility.

Blind exploits often cause an attacker to resort to tricks in order to successfully craft an exploit. Some of the many available tricks are:

Forcing a DNS lookup to come from a non-internet accessible host to receive an indication that an exploit was successful
Forcing output into some other format than expecting an HTTP Response, for example forcing a vulnerable server to generate a PDF which contains file contents or a server response such as an SSH, Telnet, or FTP banner
Comparing response times between requests and making assumptions based on response times. For example, a response time of less than one second for port 22, 80, and 443 may indicate open ports (especially since these are commonly open ports) where a response time of greater than 5 seconds may be the result of a timeout, indicating a closed port
Relying on HTTP response codes as an indication of success or failure, but this can be very error prone. For example, if the protocol used in the SSRF is hard coded as https:// and out of the attacker’s control, the results of performing a request to ports that are expecting a TLS handshake will behave differently than services that are expecting HTTP, which will behave differently than ports that do not expect web traffic at all. Additionally, visiting a site with a valid certificate may result in a different response than visiting a site with a self-signed, expired, misconfigured, or otherwise untrustworthy certificate

Another important consideration is what environment the vulnerable system is in and what systems it has the ability to communicate with. A stand-alone system vulnerable to XXE or SSRF running in a segmented network with tight inbound and outbound communication restrictions might pose little risk to an organization. The opposite is true if the vulnerable system is a server in a corporate network with little to no network segmentation and the vulnerable service is running with a privileged enterprise user account.

Some consideration is required in each of these areas before determining business risk. Each vulnerability should be evaluated carefully to decide their risk and determine patch prioritization.

Lower Impact SSRF/XXE

Synack and its customers have criteria for SSRF (and XXE) that pay more based on the real-world impact of the discovered exploit. One type that Synack rarely accepts is what we refer to as an “external only” exploit. This occurs when an attacker is only able to force the vulnerable server to make a connection to a server on the internet, but when there is no capability to prove connections to services on the internal network can occur.

One exception to this is when the attacker can force a vulnerable server to fetch a file which is protected by authentication. Sometimes this technique can be used to leak an enterprise user account’s password hash because the vulnerable server tries to authenticate to an attacker controlled server (using SMB) to retrieve the file. If the password is weak or if the attacker has enough time and computing resources, it may be possible to determine the password which is associated with the leaked hash. If the same enterprise has externally available services such as Outlook Web Access (OWA), Citrix, VPN, or another service that accepts enterprise credentials, this may allow for further exploitation and would pose more risk than a normal “external only” SSRF.

In Part II of this blog post, we’ll go further and explore more severe examples of SSRF – the ones that earn the most money from Synack. These include creative ways to use SSRF as a path to achieve lucrative bounties for RCE and SQLi.