Two Exchange Server vulns veer dangerously close to ProxyShell

Though the Patch Tuesday release for October 11 is still taking shape at Microsoft, Exchange could be a major focus point that day — if not sooner. A pair of chained web-shell vulnerabilities affecting versions 2013, 2016, and 2019 of Exchange Server, with an assist from the frequently abused PowerShell, appears to be a valid attack combination. After public disclosure of the exploit by security firm GTSC, Microsoft issued guidance on the issue (which they describe as limited and targeted, but real) ahead of the usual fix cadence.

Sophos customers are already protected. To supplement existing proactive runtime protections, we also released new network IPS signatures and endpoint anti-malware detections: IPS signature sid:2307757 for both Sophos Endpoint IPS and Sophos XG Firewall, as well as Troj/WebShel-EC and Troj/WebShel-ED to detect the “web shells” associated with the attacks reported. (Please see the chart at the end of this article for a complete list of updates.) In addition, based on public reports, the behavioral detection rule Exec_30a was designed to stop PowerShell abuse from IIS, while the Lateral_1b rule blocks the certutil download command lines — both tactics reportedly associated with these attacks.

Sophos X-Ops’ investigation has determined that Microsoft correctly identifies this as targeting a specific and small set of victims, so much so that we find no evidence of these attacks in our own database so far. However, the attack is now public knowledge, which means other attackers will attempt to adopt and use it. We therefore advise customers to follow the mitigation advice provided, and to apply Microsoft’s patch as soon as it is available.

To aid administrators, the Exchange team has released a PowerShell script to apply the suggested fixes automatically. For customers who have the company’s Exchange Emergency Mitigation Service (EEMS) enabled, Microsoft has also released the URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019, which the company says will be enabled automatically. Finally, Microsoft recommends that enterprises disable non-admin access rights for PowerShell in their organizations if possible.

Specifically, Microsoft says the two vulnerabilities involved in this are CVE-2022-41040, a Server-Side Request Forgery (SSRF) vulnerability, and CVE-2022-41082, a vulnerability that allows remote code execution (RCE) when PowerShell is accessible to the attacker.

A Server-Side Request Forgery (SSRF) vulnerability can enable an attacker to make the vulnerable server access or manipulate information or services that the server normally shouldn’t be able to, via a malicious URL. For example, an attacker could use a SSRF vulnerability to instruct a server to access a file on a web server they normally wouldn’t be able to access. It’s notable that another Exchange SSRF vulnerability, CVE-2021-26855, was the key entry point for the attacks against Exchange in 2021. In these latest reported attacks, it appears that the new SSRF vulnerability, CVE-2022-41040, serves the same purpose: acting as the front door for attack.

Similar to last year’s ProxyShell, the new attack appears to be accomplished by chaining one exploit against the SSRF vulnerability with one utilizing another vulnerability. In last year’s attacks, the SSRF vulnerability CVE-2021-26855 was chained with CVE-2021-26857 to elevate privileges, after which either CVE-2021-26858 or CVE-2021-27065 was used to execute code on the system. In this case, the SSRF vulnerability CVE-2022-41040 is chained to CVE-2022-41082, which as described above provides remote code execution through PowerShell if that is available to the attacker. Interestingly, this particular attack chain doesn’t require an additional elevation of privilege vulnerability, presumably because CVE-2022-41082 can be executed with SYSTEM privileges.

Based on the report from GTSC, once the attack chain of CVE-2022-41040 + CVE-2022-41082 has been executed, the attackers use this chain to load web shells on the compromised systems, giving them full control of the server and a foothold on the network.

While CVE-2022-41040 requires a user to be authenticated, in practical terms for many Exchange installations this is a low bar, especially those running Outlook Web Access (OWA).

The not-so-good news is that attackers have a head start on utilization – and Microsoft may or may not have known about that. On Twitter, Kevin Beaumont’s thread discussing attack reports points to an August 2022 dive into these vulnerabilities posted by researchers affiliated with GTSC, who in turn reported the issues to the venerable ZDI bug-bounty program. The bugs were disclosed to Microsoft in the usual fashion, but GTSC – seeing more customers of their SOC affected by the attack, and with no word on a forthcoming patch – decided to present what they know to the public at large.

GTSC’s own discovery came when SOC analysts spotted exploit requests in IIS logs that were identical in format to those left by the ProxyShell vuln. Since initial reports of the two vulnerabilities came up, managed detection and response services around the world (including Sophos’ own MTR) have hustled to check their logs more closely than ever for traces of trouble – one of the reasons that we deem Microsoft’s claim of “limited, targeted” attacks likely to be accurate so far.

In its own statement, Microsoft states that the necessary fixes are on an “accelerated timeline,” which usually means that the Redmond company is hurrying to get a patch or patches out the door as soon as possible – perhaps before the scheduled October 11 Patch Tuesday release.

It’s possible, whatever happens with these two bugs, that there will still be plenty of Exchange activity in the regular Patch Tuesday haul over the next few months. Though it took no patches in September, Exchange saw six fixes in August (including two Critical-class elevation-of-privilege vulns found by external researchers and an information-disclosure 0day) – precisely half of the product’s 12 patches so far this year. 2021 was also a difficult year for Exchange Server, so much so that Microsoft was compelled to delay release of the next version of the product, scheduled that year, to the latter half of 2025. This year, the number of vulnerabilities in Exchange has been dwarfed by the volume addressed in Windows (or even Azure), but Exchange is harder to patch – leaving a high percentage of servers exposed to older bugs (including the ProxyShell bug, which was patched in mid-2021).

The XG and SG sigpacks have been updated as follows to provide coverage for Exchange Server vulnerabilities CVE-2022-41040 and CVE-2022-41082:

You can also learn more about these attack in this episode of the Naked Security Podcast with Chester Wisniewski.

Prefer to read rather than listening? Read the full transcript instead.