Critical Vulnerabilities on Exchange #ProxyNotShell

Update 11/08/2022: the update has been published in the security bulletin of November

Update 12/10/2022: the security update does not contain the patch for the vulnerabilities described in this post, you must continue to apply the workarround https://techcommunity.microsoft.com/t5/exchange-team-blog/released-october-2022-exchange-server-security-updates/ba-p/3646263

Update 11/10/2022: the patch will be dropped today at 6PM GMT

Last Thursday night (french night), as always, critical vulnerabilities were announced affecting Microsoft Exchange, all supported versions.

The vulnerabilities were found by a Vietnamese Blue Team (GTSC) who discovered them being exploited in the wild against its customers: https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html

It’s a chain of two vulnerabilities allowing remote control of Exchange, without authentication:

• SSRF (CVE-2022-41040), allowing to bypass the authentication with the Autodiscover feature
• Execution of PowerShell code (CVE-2022-41082), by calling PowerShell Remoting from the Autodiscover configuration file

As with the vulnerability named ProxyShell, for this one, named ProxyNotShell, the problem comes from the automated discovery feature of a user’s email settings, the (in)famous “AutoDiscover”. As this feature is used to find a user’s information to make their life easier when configuring their email access, it is accessible without any authentication. It is possible to pass an “Email” parameter containing… an email address that Exchange will use to find the user’s parameters. In theory, Exchange will only process the request if the domain of the email is that of the Exchange (name@domain.com) and will retrieve a JSON file containing the configuration information.

But there seem to be several problems:

If the email address contains a “?” instead of the “@” at sign, then Exchange will still retrieve the JSON file using what the “name” contains (name@domain.com) by adding it to the domain which will be passed directly as a parameter (I don’t have the details of why it works yet) Exchange will look for a JSON file on the Internet and interpret its content, I guess that’s where the second vulnerability is located, which allows PowerShell to be executed. Exploit

The exploit for the SSRF (CVE-2022-41040) was released Saturday morning and is widely used in the wild but for now, without the code execution.

There are several ways to check your Exchange. The simplest one seems to be:

"https://MY-SERVER-EXCHANGE.com/autodiscover/autodiscover.json?@outlook.com/&Email=autodiscover/autodiscover.json%3f@MON-DOMAINE-MAIL.com" By replacing:

MY-SERVER-EXCHANGE.com by the FQDN of your Exchange server, like mail.mycompany.com MY-DOMAIN-MAIL.com by your mail domain name such as mycompany.com If you get a 400 error with a JSON containing an error message, then you are vulnerable.

Microsoft recommends implementing URL rewriting to block calls to PowerShell Remoting. All the details are in their article, part “Mitigations”: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

They also recommend blocking the ports used for PowerShell remoting at firewall level (TCP 5985 for HTTP and TCP 5986 for HTTPS) but the risks of side effects seem to me to be significant so to put it simply: if you don’t have any other solution, prefer a breakdown of certain services to a complete compromise of your email infrastructure 😥.

Personally, I’d recommend that your Exchanges do not have any flow allowed to Internet except the standard mail ports (25, 465, 587). It is easy to bypass but it is a first step, which will block the first exploits, those completely automated.

Detection

If you have a WAF or a reverse proxy, you can detect (and block) the exploitation of both vulnerabilities in the request by blocking with this regular expression:

.*autodiscover\.json.*PowerShell.*

Microsoft’s recommendation containing an “@” is easily bypassable (https://twitter.com/wdormann/status/1576922677675102208). This one can also be bypassed (with the case of letters for example) but seems to block most of the automated current exploitations.

If you have Azure Sentinel, as PowerShell Execution Vulnerability Exploit (CVE-2022-41082) looks like ProxyShell, you can search with the following filter:

W3CIISLog

| where csUriStem == “/autodiscover/autodiscover.json”

| where csUriQuery has “PowerShell” | where csMethod == “POST”

https://twitter.com/GossiTheDog/status/1425851771553992709

You also have some recommendations in the Microsoft article, “Detections” part: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

The Vietnamese cybersecurity company’s blog also offers IoCs to detect exploits, it’s a first base but I think that as the hours progress, private exploits among cybercriminals will come out and the exploitation could be massive, from everywhere 😩.

Once the Exchange is compromised, there are several persistence techniques used, here is a message thread with some examples: https://twitter.com/GossiTheDog/status/1575580072961982464

Good luck