Microsoft has published its third update for its mitigation of an exploit abusing two zero-day vulnerabilities in Microsoft Exchange Server, known as ProxyNotShell.
It marks the latest step towards providing a fix for the issue, which chains the two vulnerabilities together to execute the attack.
Security researcher Kevin Beaumont highlighted on Friday that there is already a bypass for the Microsoft-provided mitigation. It means every one of the company's attempts to prevent the exploit from harming customers has been circumvented within hours of publication.
The issue is in the way Microsoft's signatures detect the exploit. Signatures monitor the w3wp.exe internet information services (IIS) module but for customers of Windows Server 2016 and above, w3wp.exe is excluded automatically by Exchange Server when IIS is installed.
"The only way to correct this is to turn off automatic exclusions," he said, but Microsoft states explicitly in its documentation to not do this.
The original vulnerability disclosure for the ProxyNotShell exploit was atypical in nature and the information regarding potential fixes has been fragmented and confusing to follow for many.
Discovered last week by security researchers at Vietnam-based company GTSC, the pair of zero-days has received a number of attempted fixes - the first of which was bypassed “easily”.
GTSC said in its report that it had noticed in-the-wild exploitation of both vulnerabilities for at least a month before publishing its findings.
Cyber security in manufacturing
The increasing cost of cyber crime means manufacturers need to adapt
The security issues are related to, but different from, the ProxyShell exploit which was developed in 2021 and are not protected by the patch Microsoft provided for ProxyShell that year.
Tracked as CVE-2022-41040 and CVE-2022-41082, they each received a CVSSv3 severity score of 8.8/10. Microsoft Exchange versions 2013, 2016, and 2019 are affected.
Exploitation requires access to an authenticated user account but initial tests indicated that any email user’s account, regardless of the level of privileges they had, could be used to launch an attack.
Microsoft Exchange Server customers are advised to monitor the official mitigation page and apply new ones as they become available in order to protect against exploitation. There is currently no available patch.
Exploitation has been linked to China by cyber security company Volexity, which first discovered the ProxyLogon exploit last year.
It publicly tied “at least some of” the exploitation of both zero-days to a known Chinese threat actor that’s been active in Asia for the past 12 months.
Support for the link with China was also found in GTSC’s original report which detailed the use of China Chopper web shells in successful attacks - a tool known for being used by Chinese threat actors.
Explaining the ‘confusing’ vulnerability disclosure and mitigation releases
GTSC originally published its report on the two vulnerabilities last week but its claims that the flaws were legitimate zero-days were contested by prominent members of the cyber security community.
Details of the two-part exploit process were included in the company’s blog post but the first stage which described a similar format to the exploitation of ProxyShell was criticised by one security researcher who said the exploit looked too similar to ProxyShell’s to be considered a new method.
Matters weren’t helped by GTSC not working with Microsoft before publishing its findings, either.
In an atypical move, the Vietnam-based security firm instead went to the Zero Day Initiative (ZDI) which accepted the two vulnerabilities as zero-days.
The company said it hoped ZDI would work with Microsoft on a mitigation. It’s unusual for security researchers to publish details of zero-day vulnerabilities without alerting the affected vendor.
GTSC omitted many of the technical details from its report, reducing the risk of hackers developing exploits using information in it, and likely published ahead of informing Microsoft due to the risk it posed to the global threat landscape.
Days after GTSC’s original publication, Microsoft triaged the two vulnerabilities and issued CVE tracking codes for them both, confirming they were indeed zero-day vulnerabilities.
Zero-day vulnerabilities are security flaws in software, firmware, or hardware that are unknown to the party responsible for maintaining the affected product.
Microsoft Exchange Server was the impacted product but because Microsoft was not aware of the issues that were being actively exploited, and the fact the vulnerabiltities were eventually proved to be novel, both CVE-2022–41040 and CVE-2022–41082 were classified as zero-days.
In the days after issuing the CVEs, Microsoft released a number of mitigations for the exploit and the security community developed bypasses on numerous occasions.
Microsoft also originally said that Exchange Online customers did not need to take any action, a message later disputed as false since Exchange hybrid servers were still vulnerable.
The information surrounding the disclosure and potential fixes for the ‘ProxyNotShell’ exploit has been disseminated over a number of days and through fragmented sources.
Microsoft’s official blog has served as the central point of information but mitigation bypasses and other useful information have been sourced from various figures from the cyber security community across the internet.
Additional mitigation details
Microsoft’s latest update ‘further improves’ its mitigation strategy, first released on 30 September, which involves implementing URL rewrite rules.
The company originally instructed vulnerable customers to block ports used for Remote PowerShell to stop attackers from triggering remote code execution (RCE) through CVE-2022-41082.
This advice was later removed as a result of the community highlighting that PowerShell is available directly via Exchange and doesn’t require any other ports.
There are also a number of caveats to the provided mitigations that customers and system admins should take into account when locking down their service.
One of the updated mitigations supplied on Tuesday referenced an earlier Exchange Emergency Mitigation Service (EEMS) rule it released on 30 September.
Microsoft said this was automatically applied but others suggested that the EEMS rule was only automatically applied if the customer was on the latest Exchange cumulative update, which many aren’t according to scans.
Microsoft’s URL rewrite mitigation was delivered using the EEMS rule and an Exchange On-premises Mitigation Tool v2 (EOMTv2) that it made available. Some users also chose to manually apply the mitigation.
A bypass was made public for both EEMS and EOMTv2 methods on Wednesday, with the wider security community sharing their own manual rules to help block incoming attacks.
Microsoft issued an update to its mitigation on Thursday. Those who manually applied the mitigation are advised to update it and those who used the EEMS and EOMTv2 methods must redownload and rerun the script.
Admins who also follow Microsoft’s own advice to exclude the w3wp.exe internet information services (IIS) module from antivirus detections should understand that the new rules and signatures do not work when w3wp.exe is excluded, according to one researcher.
