Products You May Like
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 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 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 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.