Regarding Coverage for CVE-2022-41040, CVE-2022-41082 (aka ProxyNotShell)

Rule Signatures
1

Greetings Everyone,

The Emerging Threats team is aware of the recent zero-day vulnerabilities revealed for Microsoft Exchange and Microsoft OWA services – also known as CVE-2022-41040, CVE-2022-41082, and collectively as “ProxyNotShell”.

At this time, a public proof of concept has not yet been discovered, however several organizations are claiming that these newly discovered vulnerabilities are almost identical in nature to the ProxyShell vulnerabilities discovered last year (CVEs 2021-34473, 2021-34523, and 2021-31207)in that the newly discovered vulnerabilities exploit an SSRF vulnerability to trigger remote code execution.

The primary difference between 2021’s ProxyShell, and this new ProxyNotShell is that the new vulnerability requires valid credentials for an exchange user on the on-prem Exchange/OWA deployment in order to trigger the exploit successfully. Last year, we developed Suricata and Snort sids 2033684, 2033711, 2033712, 2035649, and 2035650 to detect exploit attempts of the ProxyShell vulnerability chain. However with scant details on how this new ProxyNotShell vulnerability is triggered, and how that differs from the previous vulnerability, we have been prompted to create a new signature based on information presented by Microsoft MSRC. While the guidance is scant on specific details for ProxyNotShell, MSRC mentions a mitigation method that involves blocking access to a specific URI pattern:

.*autodiscover\.json.*\@.*Powershell.*

Again, this URI pattern is almost identical to the URI pattern used to trigger ProxyShell, and our existing rules account for this. However, our existing rules also assume the existence of an Email= parameter as well as the X-Rps-CAT parameter – in either the http URI or the http cookie fields of the HTTP header. It is not yet known whether or not these parameters are required to be present to trigger this new vulnerability, so in an abundance of caution we have created a new, more generic rule that triggers on the URI pattern that microsoft has specified, without any additional parameters. This rule will be released this evening (2022/09/30) EST as a part of our daily rule release into the ETOPEN and ETPRO rulesets.

If you would like to know more about ProxyNotShell, including host-based detection methods, mitigations, and the campaign by which this new vulnerability was discovered, please consult the following links:

https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

We would like to thank Kevin Beaumont (@GossiTheDog) for his detailed coverage of these new vulnerabilities, Gteltsc for their write-up, and MSRC for their advisory.

1 Like
2

Greetings folks,

If you haven’t been following new developments regarding this exploit, let me key you in to a new development that has occurred over the weekend:

From observations in the wild, it has been discovered that the URI pattern rewrite/block that Microsoft provided above (.*autodiscover\.json.*\@.*Powershell.*) is too restrictive, and may result in bypassed requests that still trigger the exploit, per security researcher @testanull.

It has been noted that, like the ProxyShell exploits from a year ago, that 1) the Email parameter is used, and 2) It can be moved to the HTTP cookie field, just like last time. They recommend changing the URL block/rewrite pattern to:

.*autodiscover.json.*Powershell.*

Note the removal of the 0x40 (@) symbol from the pattern. This new pattern should catch the bypass attempts that attempt to offload parameters to the HTTP cookie field. ET Rule 2039065 will be updated in today’s daily rule release to reflect changes to the recommended URI pattern.

As always, if you experience any problems feel free to let us know via: https://feedback.emergingthreats.net

3

Hey Folks,

We have another small update on this advisory. Another bypass for the URI pattern from MSRC has been discovered:

This update has been added to Kevin’s blog on ProxyNotShell but to make a long story short, attackers are using URL encoding to break the URI pattern microsoft provided.

The good news: Assuming ETPRO/ETOPEN users already have the capability to inspect encrypted by default OWA traffic, Suricata has the ability to automatically detect HTTP no matter the port it is detect on via automatic application layer protocol detection.

This is important because Suricata rules will automatically apply HTTP normalization for HTTP traffic detected on nonstandard ports. This means that URL encoded characters in the HTTP URI will automatically be decoded as a part of the normalization process

The bad news: If you are a consumer of the ETOPEN or ETPRO ruleset on snort 2.9.x, that rule was written without the use of HTTP buffers, because we have to assume that the our users are operating with a default snort.conf (or suricata.yaml) without the ability to modify it. We can’t publish a rule then tell users “You need to modify the HTTP_PORTS variable, Stream5 processor, and HTTP Inspection preprocessor for it to work”. So, unfortunately, we’re stuck between a rock and a hard place.

But unofficially, assuming your are using snort with SSL inspection, your SSL inspection vendor likely has already informed you to make the necessary configuration changes to inspect HTTPS traffic properly – at least on port 443, but in the case of OWA/exchange traffic, you’ll also want make sure you’re inspecting traffic on port 444 as well.

Now, assuming you have all of that in place, here is a snort rule you can use to benefit from HTTP normalization and deal with URL encoding evasions:

alert tcp any any -> [$HOME_NET,$HTTP_SERVERS,$SMTP_SERVERS] [$HTTP_PORTS,444] (flow:established,to_server; content:"POST"; http_method; content:"autodiscover.json"; nocase; fast_pattern; http_uri; content:"Powershell"; nocase; http_uri; distance:0; sid:9000000; rev:1;)

As always, we’ll keep you posted as we learn more.