Yesterday, Microsoft released information along with security researchers at GTSC regarding newly discovered 0-day vulnerabilities in Microsoft Exchange. The two vulnerabilities in question have been assigned to CVE-2022-41040 and CVE-2022-41082 collectively referred to by some as ProxyNotShell. The first (CVE-2022-41040) is a server-side request forgery (SSRF) which an authenticated attacker can use to then exploit CVE-2022-41082 which is a remote code execution (RCE) vulnerability that allows the attacker to remotely execute Powershell on the targeted Exchange server. Microsoft points out in their bulletin that the attacker does need to already be authenticated to the vulnerable Exchange Server before they can make use of this attack which makes this vulnerability significantly less critical than the large-scale ProxyLogin vulnerability that first brought major attention on Microsoft Exchange in the Spring of 2021.
According to GTSC, they first discovered unusual behavior in August 2022 which led to their discovery of ProxyNotShell and the fact that it is actively being used by what is believed to be a Chinese threat actor. The attacker was trying to exploit Microsoft's Internet Information Services (IIS), which hosts the front-end web component of Microsofts Outlook Web Access (OWA), using the same format as the ProxyShell vulnerability. After successfully exploiting a server, the attacker deployed Antsword, which is a Chinese open-source web admin tool that can be used as a web shell. The attackers also modified "RedirSuiteServiceProxy.aspx" and replaced it with a webshell.
Mitigation
Though a patches are not yet available for CVE-2022-41040 or CVE-2022-41082, Microsoft has released some mitigation guidance that will protect your systems from being exploited. The instructions provided by Microsoft are:
- Open the IIS Manager.
- Expand the Default Web Site.
- Select Autodiscover.
- In the Feature View, click URL Rewrite.
- In the Actions pane on the right-hand side, click Add Rules.
- Select Request Blocking and click OK.
- Add String “.*autodiscover\.json.*\@.*Powershell.*” (excluding quotes) and click OK.
- Expand the rule and select the rule with the Pattern “.*autodiscover\.json.*\@.*Powershell.*” and click Edit under Conditions.
- Change the condition input from {URL} to {REQUEST_URI}
According to the bulletin released by Microsoft, the above modifications will not impact the normal functioning of Exchange in any way.
An attacker can also use CVE-2022-41082 to remotely execute Powershell if a server has Remote PowerShell enabled. For this reason, they also recommend blocking Remote PowerShell ports 5985 (HTTP) and 5986 (HTTPS).
****UPDATE - October 3, 2022****
Since the original blog post by Microsoft was released some new information has been discovered. First, the URL Rewrite rules above are not entirely sufficient to mitigate the vulnerability and can be bypassed. More information regarding the bypass, as well as a video demo can be found on security researcher Kevin Beaumont's blog. We are still waiting on an update regarding this from Microsoft, but in the meantime it has been suggested on Tiwtter that the Rewrite pattern should instead be replaced with:
.*autodiscover\.json.*Powershell.*
Though one person is reporting that this causes some issues with Outlook and some alternate patterns are suggested. You can following the full Twitter thread here.
It has also been suggested by security researchers that an additional rule be added from {HTTP_COOKIE} containing:
Email=autodiscover
Additionally, Microsoft has determined that blocking the Remote PowerShell ports as mentioned above also does not mitigate the issue, and has removed that recommendation from their site and have replaced it with the following:
"We strongly recommend Exchange Server customers to disable remote PowerShell access for non-admin users in your organization. Guidance on how to do this for single user or multiple users is available here."
CW SIEM Detection
The attack vectore used for ProxyNotShell is very similar to ProxyShell. In fact it is similar enough, that several IDS signatures and Event Notifications within the CW SIEM designed to detect ProxyShell will also detect ProxyNotShell. We also have existing detections for web shells used in past Exchange attacks that will detect the new web shells being deployed. So, if you are a CW SIEM customer and are subscribed to both the Perch Users community and the CRU Collection than you can rest assured that existing detections would have triggered if your systems were exploited even before information on these new vulnerabilities were disclosed.
We have two new signatures deployed today that are more specific to the webshells that have been deployed in the currently active campaign:
alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"[ConnectWise] HUNTING Microsoft Windows Exchange WebShell Observed Outbound"; flow:established,from_server; file.data; content:"|3c 25|"; startswith; content:"|20|Language="; nocase; pcre:"/^(\x22|\x27)(VB|Jscript|C#|java)(\x22|\x27)/Ri"; content:"|25 3e|"; distance:0; classtype:trojan-activity; sid:900700; rev:2; metadata: created_at 2022_09_29, updated_at 2022_09_30;)
alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"[ConnectWise] Potential SharPyShell Webshell"; flow:established,from_server; http.response_body; content:"<script Language=|22|c#|22 20|"; fast_pattern; nocase; reference:url, github.com/antonioCoco/SharPyShell/tree/master/agent; classtype:trojan-activity; sid:900701; rev:1; metadata: created_at 2022_09_29, updated_at 2022_09_29;)
