ProxyNotShell – the New Proxy Hell?

Nicknamed ProxyNotShell, a new exploit used in the wild takes
advantage of the recently published Microsoft Server-Side Request
Forgery (SSRF) vulnerability CVE-2022-41040 and a second
vulnerability, CVE-2022-41082 that allows Remote Code Execution
(RCE) when PowerShell is available to unidentified attackers.

Based on ProxyShell, this new zero-day abuse risk leverage a
chained attack similar to the one used in the 2021 ProxyShell
attack that exploited the combination of multiple vulnerabilities –
CVE-2021-34523, CVE-2021-34473, and CVE-2021-31207 – to permit a
remote actor to execute arbitrary code.

Despite the potential severity of attacks using them, ProxyShell
vulnerabilities are still on CISA’s list of top 2021 routinely
exploited vulnerabilities.

Meet ProxyNotShell

Recorded on September 19, 2022, CVE-2022-41082 is an attack
vector targeting Microsoft’s Exchange Servers, enabling attacks of
low complexity with low privileges required. Impacted services, if
vulnerable, enable an authenticated attacker to compromise the
underlying exchange server by leveraging existing exchange
PowerShell, which could result in a full compromise.

With the help of CVE-2022-41040, another Microsoft vulnerability
also recorded on September 19, 2022, an attacker can remotely
trigger CVE-2022-41082 to remotely execute commands.

Though a user needs to have the privilege to access
CVE-2022-41040, which should curtail the vulnerability
accessibility to attackers, the required level of privilege is
low.

At the time of writing, Microsoft has not yet issued a patch but
recommends that users add a blocking rule^[1]
as a mitigation measure.

Both vulnerabilities were uncovered during an active attack
against GTSC, a Vietnamese organization called GTSC, granting
attackers access to some of their clients. Though neither
vulnerability on its own is particularly dangerous, exploits
chaining them together could potentially lead to catastrophic
breaches.

The chained vulnerabilities could grant an outsider attacker the
ability to read emails directly off an organization’s server the
ability to breach the organization with CVE-2022-41040 Remote Code
Execution and implant malware on the organization’s Exchange Server
with CVE-2022-41082.

Though it appears that attackers would need some level of
authentication to activate the chained vulnerabilities exploit, the
exact level of authentication required – rated “Low” by Microsoft –
is not yet clarified. Yet, this required low authentication level
should effectively prevent a massive, automated attack targeting
every Exchange server around the globe. This hopefully will prevent
a replay of the 2021 ProxyShell debacle.

Yet, finding a single valid email address/password combination
on a given Exchange server should not be overly difficult, and, as
this attack bypasses MFA or FIDO token validation to log into
Outlook Web Access, a single compromised email address/password
combination is all that is needed.

Mitigating ProxyNotShell Exposure

At the time of writing, Microsoft has not yet issued a patch but
recommends that users add a blocking rule^[2]
as a mitigation measure of unknown efficacy.

Blocking incoming traffic to Exchange Servers holding critical
asserts is also an option, though only practicable if such a
measure does not impact vital operations and should ideally be
perceived as a temporary measure pending Microsoft’s issuance of a
verified patch.

Assessing ProxyNotShell Exposure

As the current mitigation options are either of unverified
efficacy or potentially damaging to the smooth running of
operations, evaluating the degree of exposure to ProxyNotShell
might prevent taking potentially disruptive unnecessary
preventative measures, or indicate which assets to preemptively
migrate to unexposed servers.

Cymulate Research Lab has developed a custom-made assessment
for ProxyNotShell^[3]
that enable organizations to estimate exactly their degree of
exposure to ProxyNotShell.

A ProxyNotShell attack vector has been added to the advanced
scenarios templates, and running it on your environment yields the
necessary information to validate exposure – or lack thereof – to
ProxyNotShell.

Until verified patches are available from Microsoft, assessing
exposure to ProxyNotShell to evaluate exactly which servers are
potential targets is the most cost-efficient way to evaluate
exactly which assets are exposed and devise targeted preemptive
measures with maximum impact.

By Cymulate Research
Labs^[4]