Server Side Request Forgery (SSRF). This vulnerability class triggers a wide range of emotions and reactions, ranging from complete ignorance to panic. Though it is included in the OWASP Top 10 list of web application security risks, at times vendors tend to downplay it and not treat it seriously.

As usual, the truth lies somewhere in between. What appears to be SSRF may sometimes in fact be intended functionality. Even so, an attacker may be able to abuse that functionality to improperly disclose sensitive information, either from the application containing the SSRF or from unrelated internal systems.

You may have noticed battles between researchers and vendors where an SSRF vulnerability was at the center of the disagreement. The fun part starts when a single vendor responds to different SSRF vulnerabilities in different ways and you are not able to reverse engineer their decision-making algorithm.

Whenever I find an SSRF vulnerability, my personal approach is to divide the assessment into four main categories. 

a)     Internal vs. external application

Ideally, we want to find SSRF vulnerabilities in applications that are widely exposed to the internet. Such a vulnerability may allow you to interact with an internal network to which you would not have direct access.

This isn’t to say that SSRF vulnerabilities in internal applications are without value. Sometimes, internal applications may be placed in the DMZ or another restricted area of the network. When you are an internal attacker (an attacker who is already in the internal network), you may find an SSRF useful for reaching some inaccessible networks or machines. Still, it’s typically a much less attractive case than an internet-reachable SSRF.

 b)     Does the product expose services on the loopback interface?

Some products expose services that are reachable only through a loopback interface. If we can interact with such a service through the SSRF, it allows us to extend the attack surface and to potentially chain it with other vulnerabilities. It makes the SSRF potentially more interesting and useful.

c)     Privileges required

As always, the strongest vulnerabilities are those that do not require authentication.

After that come vulnerabilities requiring low privileges. Though less powerful, they can still be very dangerous. Consider an externally exposed application with 50,000 users. An authenticated SSRF in such a case may be very dangerous, as we all know that threat actors have multiple ways of obtaining credentials.

Last and least, there are SSRFs that require administrative privileges. Typically, I almost immediately drop those. Seeing a vendor that fixes admin-level SSRF is a rarity.

d)     What can we achieve with the SSRF

This is a crucial category, and we can divide it into two subparts.

1 - Request shaping:

— What protocols can we use? HTTP, HTTPS, FTP, any other?
— How much do we control the request? In case of HTTP:

o   Can we pick the HTTP method? GET, POST or any other? If not, which method is being used for the request?
o   Can we fully control the URL? Are some query string parameters hardcoded, or do we have full control?
o   Can we specify arbitrary HTTP headers?
o   Can we insert arbitrary data into the request body?
o   And so forth.

2 - Response handling:

— Does the SSRF sink follow redirects? If so, does it allow switching protocols?
— Does it return a response to the attacker?

I find this last question particularly important. If the attacker can use the SSRF to receive a response, the information leak risk is real. I’ve done hundreds of penetration tests and believe me – SSRF that allows you to make GET requests to the internal network and receive the response will give you a ton of sensitive information.

That was long, I’m sorry. But this shows that the evaluation of SSRF vulnerabilities is in fact complex and it depends on many factors. When you find an SSRF vulnerability, you will need to do a similar evaluation by yourself. Afterward, you might find that when the vendor performs their own evaluation, they may have a completely different definition of a “potentially harmful SSRF”.

To illustrate, I once reported an SSRF vulnerability in Microsoft SharePoint, CVE-2023-28288. This vulnerability could be exploited by any authenticated user and allowed the attacker to make any HTTP GET request but did not return the response. Microsoft treated this vulnerability seriously and provided a quick fix. MSRC even assigned a higher CVSS score than we originally had. This may be because the vulnerability additionally allowed disclosure of the contents of local files with the xsl extension. I did not find that especially interesting, but perhaps Microsoft did.

On the other hand, the researcher known as Frycos found a pre-auth SSRF in Skype for Business, and more than a year passed waiting for the fix. It was not treated as an immediate threat. Quoting from that blog post:

Since the MSRC rejected my submission for this vulnerability with a “not meeting the bar” argument, I told them to publish a blog post instead.

I am doing something similar right now. Not so long ago, I had 4 hours to spare, and I decided to look at I quickly identified 3 SSRF issues, one of which seemed to be particularly dangerous:

— Exchange OWA is frequently exposed to the internet.
— The vulnerability could be exploited by any authenticated user (any user with a mailbox). Even though this means that authentication is required, the number of mailboxes deployed in some organizations can run into the hundreds of thousands.
— It allows performing any HTTP GET request, with full control over the URL and query string parameters.
— It retrieves the content of the response.

As the attacker can abuse this SSRF to retrieve the content of the response, I thought it was a good finding. However, Microsoft did not agree:

MSRC has investigated this issue and concluded that this does not require immediate servicing. We have shared your report with the team responsible for maintaining the product or service and they will consider a potential future fix, taking the appropriate action as needed to help keep customers protected.

We do not have a timeline for when this review will occur, and will not be able to provide status for this issue moving forward.

In short: this may get fixed or it may not. If they decide to fix it, the patch may appear in 1 year or in 3 years. In general, we know nothing.

Accordingly, we informed Microsoft of our intention to publish this vulnerability as a 0-day advisory and a blog post. As we consider this issue potentially dangerous, we want organizations to be aware of the threat. For this reason, we are providing a PoC HTTP Request to be used for filtering and/or monitoring.

ZDI-CAN-22101 – CreateAttachmentFromURI Server-Side Request Forgery

When a user wants to attach a file to a message through Exchange OWA, he can use the “clip” button. It allows the selection of any file from the local file system.

Quite an obvious thing, right? On the other hand, when I was going through the methods defined in the Exchange OWAService, I found an interesting one called CreateAttachmentFromUri.

At [1], an HttpClient is created.

At [2], a request is made.

At [3], an attachment is created on the basis of the retrieved response.

According to that, this method allows performing an HTTP GET SSRF. The attacker can target any endpoint and can specify any query string parameters.

One may notice that this SSRF has an additional feature that makes it even more dangerous. It creates the attachment on the basis of the response. There are also bonus points for the fact that this SSRF sink handles redirects – they are supported by default by HttpClient, and the AllowAutoRedirect property is not modified by the code.

My guess is that this is some obsolete Exchange OWA feature, which has been deprecated and removed from the GUI. However, it has not been removed from the server-side code. This is only a guess though, as I have never been a serious user of OWA.

To sum up, the following attack scenario is possible:
• The attacker authenticates to OWA.
• The attacker creates a new draft message.
• The attacker invokes CreateAttachmentFromUri, triggering the SSRF.
• The response of the SSRF gets added to the mail message as an attachment.
• The attacker downloads the attachment and retrieves the response content.

I implemented this attack scenario in my exploit. The following screenshot presents a sample exploitation, where the http://internaltomcat.zdi.local:8080 URL was targeted.

Such a request produces SSRF. It will not allow you to retrieve the response content, though. If you want to retrieve the content, you must provide a valid message’s ChangeKey and Id in the respective JSON keys (here, they were set to poc). If a proper ChangeKey and Id are provided, the response will be attached to the specified message.

The JSON payload can be also delivered through the X-Owa-Urlpostdata HTTP header. The following snippet presents an example of such a request:

Summary

Assessment of Server Side Request Forgery issues may be hard and lead to disagreements. Such vulnerabilities often do not impact the same product in which they exist, which is an argument frequently heard from vendors. However, they can be used as an access path for external attackers to reach the restricted areas of networks, thereby causing an impact on other systems in the corporate environment. Accordingly, I would recommend that vendors take SSRF seriously, and reassess functionality that involves forwarding arbitrary requests.

I hope you liked this writeup. Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.