In September of 2022, a vulnerability was reported in one of the most utilized services, that is Microsoft Exchange, more specifically, Microsoft’s own Outlook Web App, used by most enterprises worldwide. We are talking about the OWASSRF exploitation chain (Outlook Web Application Server-Side Request Forgery), based on CVE-2022-41080.
The bug was discovered by the team of security researchers and engineers from VcsLab of Viettel Cyber Security, who go by pseudonyms rskvp93, Q5Ca and nxhoang99, and zcgonvh of 360 Noah Lab.

Is your company affected by this?

The vulnerability affects MS Exchange servers that are self-hosted by the companies (Microsoft hosted Office 365 version of OWA non-included).

Versions of the Exchange server that are affected by OWASSRF:

  • Microsoft Exchange Server 2013 Cumulative Update 23
  • Microsoft Exchange Server 2016 Cumulative Update 22
  • Microsoft Exchange Server 2016 Cumulative Update 23
  • Microsoft Exchange Server 2019 Cumulative Update 11
  • Microsoft Exchange Server 2019 Cumulative Update 12

Exploiting CVE-2022-41080 can be done without any user interaction whatsoever. Only one email account needs to be compromised (by phishing, for example).

So why do we say that there is no user interaction needed in order to exploit this vulnerability?

Privileges needed to exploit this vulnerability are low, as the compromised account can belong to anyone in the company. It’s because the simple end-user account shouldn’t have the potential to obtain this much control over the entire business infrastructure in the first place. So, while the above statement is true, the actual OWASSRF exploit chain does, in fact, rely on more than one vulnerability.

So, after authenticating with the front-end, they need to perform this request to the /owa end-node.

GET /owa/user%40gmail.com/mapi/nspi HTTP/1.1
Host: 192.168.xxx.yyy
User-Agent: python-requests/2.27.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
X-OWA-ExplicitLogonUser: owa/user@gmail.com
Cookie: <my-cookie>

The real vulnerability hides in this snippet of code that helps forge the request that’s being sent to the back-end.

protected override UriBuilder GetClientUrlForProxy()
{
    UriBuilder uriBuilder = new UriBuilder(base.ClientRequest.Url.OriginalString);
    if (this.IsExplicitSignOn && !UrlUtilities.IsOwaDownloadRequest(base.ClientRequest.Url))
    {
        uriBuilder.Path = UrlHelper.RemoveExplicitLogonFromUrlAbsolutePath(HttpUtility.UrlDecode(base.ClientRequest.Url.AbsolutePath), HttpUtility.UrlDecode(this.ExplicitSignOnAddress));
    }
    return uriBuilder;
}
public static string RemoveExplicitLogonFromUrlAbsolutePath(string absolutePath, string explicitLogonAddress)
{
    ArgumentValidator.ThrowIfNull("absolutePath", absolutePath);
    ArgumentValidator.ThrowIfNull("explicitLogonAddress", explicitLogonAddress);
    return absolutePath.Replace("/" + explicitLogonAddress, string.Empty);
}

The GetClientUrlForProxy() method handles the request inadequately, in a way that the /owa/user%40gmail.com gets cropped from the request URL, forwarding the request to /mapi/nspi.

This results in the authentication with the back-end using the same credentials that have been stolen from the victim and used to authenticate with the front-end. Basically, this wouldn’t be “that big of an issue”, if only there weren’t other vulnerabilities. CVE-2022-41080 will only create an attack vector for performing a TabShell exploit, based on CVE-2022-41076.

Once authenticated with the back-end, the attacker can make an arbitrary request for /powershell. At that point, they would be able to run a limited list of PowerShell commands in a sandbox. That’s where TabShell kicks in and allows total control over PowerShell, giving the attacker the ability to run arbitrary commands and pretty much do whatever he desires, ranging from denial of service, all the way up to data encryption for the purpose of extorting ransomware.

How can you mitigate this threat?

The best thing to do would be to install the official security patch via update. For most clients, the safest bet would be to switch on automatic updates for their Exchange server.

If for whatever reason this is not possible in your case, we recommend you to hot-fix this issue by undertaking these steps:

  1. Disable Outlook Web App and use Outlook Desktop App instead.
  2. Deny remote PowerShell access to everyone, except for server administrators (and be careful not to be the one whose credentials get stolen).

As AC/DC’s own Angus Young once said:

“So lock up your daughter, lock up your wife”

What will DataGrid do to help?

Using our sanity check tool you can make sure that your IPs are not vulnerable. If you believe that your company might be affected, feel free to get in touch with our team!

Subscribe to be updated on the new content!

Subscription Form (#4)