[German]Last night I had reported on the blog about a 0-day vulnerability ZDI-CAN-18333 in Microsoft's on-premises Exchange Servers, which is already being exploited in the wild. Within hours, Microsoft has now responded and confirmed that they are currently investigating two reported zero-day vulnerabilities (CVE-2022-41040, CVE-2022-41082) affecting Microsoft Exchange Server 2013, 2016 and 2019. At the same time, Microsoft is providing affected administrators with guidance on what to do to protect against these zero-day vulnerabilities until appropriate security updates are available.
Advertising
Microsoft confirms vulnerabilities
The information about possible zero-day vulnerabilities in on-premises installations of Microsoft Exchange have only been public for a few hours. I had reported about it the night in the blog post Exchange Server servers attacked via 0-day exploit (Sept. 29, 2022). Microsoft responded within hours, confirming in the tech community post Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server, Sept. 29, 2022, that they are currently investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016 and 2019. The vulnerabilities are as follows:
- CVE-2022-41040: It is a server-side request forgery (SSRF) vulnerability.
- CVE-2022-41082: Allows remote code execution (RCE) if the attacker has access to PowerShell
Details are not disclosed. Microsoft also states that there are currently only a few known targeted attacks using the two vulnerabilities. In these attacks, CVE-2022-41040 can allow an authenticated attacker to remotely trigger CVE-2022-41082, according to Microsoft.
A 1st classification by Microsoft
Microsoft writes in its post, It should be noted that authenticated access to the vulnerable Exchange Server is required to successfully exploit either vulnerability.
This sounds "reassuring" at first, since authentication is required on the Exchange Server. But in the hafnium hack at the end of February, beginning of March 2021, there was a massive attack on Microsoft Exchange Server (see Exchange server 0-day exploits are actively exploited). Later, the US accused China of this attack (see USA, EU, NATO, Microsoft & Co. blame China for Hafnium Exchange Hack). And I'm not sure how much authentication information on Exchange systems has been captured in hacks in recent months.
Microsoft Exchange Online not affected
Redmond says Microsoft Exchange Online has detection capabilities and mitigations in place to protect customers against the vulnerabilities. Microsoft is also monitoring these already-implemented detections for malicious activity and says it will take the necessary steps to protect customers.
Additions by security researchers
Security researcher Kevin Beaumont has since published his own article on DoublePulsar with the latest information and his own findings on the matter (thanks to blog readers for links to Beaumont's and Microsoft's articles).
Advertising
Beaumont writes that users of the cloud version Exchange Online are not affected. The same is true for systems that do not run Outlook Web App, which is accessible via the Internet. But Beaumont also posted the following account from search engine Shodan. In Germany, more than 40,000 Exchange installations are accessible via the Internet using Outlook Web App.
Exchange Server accessible via Internet using Outlook Web App, Source: Shodan
Mitigation the vulnerabilities
While Microsoft states that they are working at full speed to release a fix. Until new findings or a fix are available, Microsoft proposes the following mitigation measures to mitigate the vulnerabilities and detect attacks.
The current workaround is to add a blocking rule under "IIS Manager -> Default Website -> Autodiscover -> URL Rewrite -> Actions" to block the known attack patterns.
This measure had already been described by the discoverers of the vulnerability (see also my blog post Exchange Server servers attacked via 0-day exploit (Sept. 29, 2022)). The Microsoft post includes some images that illustrate the approach. Microsoft writes that there is no known impact on Exchange functionality if the URL rewrite module is installed as recommended.
Note: German blog reader Robert Richter points out a discrepancy in the URL for the regular expression in this German comment on my German blog. Microsoft uses a * as the pattern for the blocking rule, while the discoverers from Vietnam specify the .* expression for the rule. In my opinion (I'm not a crack at this), the expression .* is the correct version – since this pattern is supposed to find any number of characters, according to this post. The * should be preceded by a character, which should be searched for. In the form * of the pattern given by Microsoft an empty string is searched for – imho the dot was forgotten. But I'm not 100% sure, that my interpretation is right.
Within my German article Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333 there is also a comment, mentions, that Microsoft's mitigation is wrong. The given pattern for URL rewrite (".*autodiscover\.json.*\@.*Powershell.*") looks like a RegEx (recognizable by the backslashes as escape character). However, the instructions from Microsoft shown with screenshots do not change the selection field "Using" to RegEx, but leave it at "Wildcards". Thus the given pattern is not interpreted as a regex pattern, but as a normal string with wildcards. And thus blocking the query will probably not work.
Further, Microsoft writes that authenticated attackers who can access PowerShell remoting on vulnerable Exchange systems are able to trigger RCE with CVE-2022-41082. Therefore, blocking the ports:
HTTP: 5985
HTTPS: 5986
used for remote PowerShell can limit these attacks.
Attack detection
Microsoft has not yet implemented a specific detection query for the vulnerabilities in its security solutions. However, in the tech community post Customer Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server, Microsoft writes that based on what has been observed in the wild during attacks, existing detection techniques are helpful.
The post Web Shell Threat Hunting with Microsoft Sentinel on finding Web shell threats with Microsoft Sentinel also provides good guidance for finding Web shells in general, he said.
The Exchange SSRF Autodiscover ProxyShell Web Shell Threat Hunting with Microsoft Sentinel detection, created in response to ProxyShell, can also be used for queries. This is because there are similarities in the approach of the above threat. There is also a new query for Exchange Server Suspicious File Downloadsthat specifically looks for suspicious downloads in IIS logs. In addition to these queries, there are a few more that could be helpful in finding post-exploitation activity that Microsoft lists in the post. Microsoft Defender for Endpoint can also detect and alert on attack attempts.
So administrators are not helplessly exposed to it all, but can largely protect their on-premises Exchange installations from this threat.
Article series:
Exchange Servers are attacked via 0-day exploit (Sept. 29, 2022)
Microsoft's recommendations for Exchange Server 0-day vulnerability ZDI-CAN-18333
Update on Exchange Server 0-day Vulnerability ZDI-CAN-18333: Fixes, Scripts and EMS Solution
Exchange Server: Microsoft updates it's mitigation for the 0-day ProxyNotShell vulnerability (October 5, 2022)
Exchange Server: Microsofts improves solutions for 0-day mitigation again (October 8, 2022)
Similar articles
Exchange Server Security updates (August 9, 2022)
Microsoft Exchange Server: Remote Code Execution vulnerability CVE-2022-23277 exploitable despite patch?
Update on ProxyLogon hafnium exchange issue (March 12, 2021)
Anatomy of a Hive Ransomware Attack on Exchange via ProxyShell
ProxyShell, Squirrelwaffle and a new PoC Exploit, patch your Exchange Server!
Exchange and ProxyShell: News from Microsoft and security experts
ProxyShell, ProxyLogon and Microsoft's contradictious Exchange doc for virus scan exceptions
Wave of attacks, almost 2,000 Exchange servers hacked via ProxyShell
Attacks on Exchange Server via ProxyShell vulnerability (8/13/2021)
Exchange Server: Update on ProxyShell vulnerabilities
Issues with Exchange March 2022 Updates
Exchange Update errors and information (April 13, 2021)
Exchange isues with ECP/OWA search after installing security update (March 2021)
Exchange 2016/2019: Outlook problems due to AMSI integration
Exchange Server September 2021 CU comes Sept. 28 with Microsoft Exchange Emergency Mitigation Service
Exchange Server 2016-2019: Custom attributes in ECP no longer updatable after CU installation (July 2021)
Exchange Server 2013: Microsoft's tips on decommissioning the systems
Update for Exchange Extended Protection script, but still error
Tip: Exchange Health Checker – Script extensions by Frank Zöchling
Why do they have requestblockingrule -> pattern ony * when if you use ".*autodiscover\.json.*\@.*Powershell.*" it create PATTERN .* (with dot)
which one is good?
The RegExpression Pattern ".*autodiscover\.json.*\@.*Powershell.*" (without the "") is the right one – as a MS employee has confirmed in a techcommunity comment (see also the comments within my German blog posts). The wildcard option and the * pattern doesn't work, as some German users has found out.