ProxyNotShell: New vulnerabilities in Microsoft Exchange Server (CVE-2022-41040, CVE-2022-41082) (update)

Content

Update January 2, 2023

Microsoft has released Nov. 8, 2022 security updates for Exchange Server 2013, 2016 and 2019. These protect against CVE-2022-41040 and CVE-2022-41082. NFIR at all times recommends installing patches as soon as they are available. These patches constitute the structural final measure and override the temporary mitigation measures.

See also the FAQ section in the Microsoft blog:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2022-exchange-server-security-updates/ba-p/3669045
For environments still vulnerable to CVE-2022-41040 and CVE-2022-41082, new exploits are regularly published by security researchers. For example, see this Dec. 20, 2022 article from CrowdStrike:

OWASSRF: CrowdStrike Identifies New Method for Bypassing ProxyNotShell Mitigations

This means that the temporary measures published as a workaround in 2022 are no longer sufficient to close these CVE vulnerabilities. Keeping Exchange up to date with the latest patches from Microsoft is the motto. The recommendation is to have at least patch level November 2022 for Exchange Server to protect against CVE-2022-41040 and CVE-2022-41082.

===

A set of two new zero-day vulnerabilities for Microsoft Exchange Servers – ProxyNotShell, disclosed by GTSC on Sept. 29, 2022, is currently being actively exploited by hackers. No patch is available at the time of writing.

Microsoft published a “Customer Guidance” article in the Microsoft Security Response Center on the morning of Sept. 30, 2022, in which Microsoft confirms it is investigating two reported zero-day vulnerabilities. They are CVE-2022-41040, a Server-Side Request Forgery (SSRF) vulnerability and CVE-2022-41082, a Remote Code Execution (RCE) vulnerability if PowerShell is accessible to the attacker.

Microsoft is aware of limited targeted attacks exploiting the vulnerabilities to get into victims’ systems. In these attacks, CVE-2022-41040 can enable an “authenticated” attacker (i.e., the attacker must already have a successful successful login to the affected environment) to then trigger CVE-2022-41082. It should be noted that authenticated access to the vulnerable Exchange Server is required to successfully exploit one of the two vulnerabilities. The vulnerability uses what is known as Autodiscover functionality. URLs using Autodiscover do not have Multi-Factor Authentication (MFA) protection.

Microsoft is currently working on a patch.

These vulnerabilities are very similar to vulnerabilities reported last year called ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207). The vulnerability has been labeled in the cybersecurity community (see Twitter @GossiTheDog) as #ProxyNotShell.
Until there is a patch, it is highly recommended to follow mitigation and detection guidelines to help customers protect themselves from these attacks.

Microsoft Exchange Online already has detection and mitigation to protect customers. Only environments with Microsoft Exchange Server (on-premises or hybrid, versions Server 2013, Server 2016, Server 2019) are potentially vulnerable.

Update October 3, 2022:

Microsoft has published an update to the “Customer Guidance” article.

If an attacker is able to successfully exploit the vulnerability, it can lead to the execution of unauthorized code on the affected systems. This could potentially result in the server and the data present being compromised. This attack can be carried out from the Internet requiring authentication.
From a compromised server, an attacker may be able to gain access to the machine and possibly to the rest of the network.

Microsoft has included a number of specific mitigation measures in the "Customer Guidance" report (see https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
NFIR strongly recommends implementing these measures.
At the time of writing, no patches have been published by Microsoft - however, Microsoft's article described a number of workarounds that are summarized below:

If you don't know if you have vulnerable Outlook Web App services available on the Internet, you can search Shodan.io website with:

http.component: "outlook web app" and by adding the filter
org:yourorganizationname or ssl: "*yourorganizationname"

Details of the mitigation measures can be found in the Microsoft article (see https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/)

It is important for your organization to take at least the following steps:

  1. Check publicly available Indicators-of-Compromise (IoCs) on your systems to determine if any systems may have been compromised, or have external preventive research performed on your systems.
  2. Implement the workarounds made available to reduce the impact, where possible.
  3. Prepare your organization for the situation when patches need to be executed unexpectedly (outside the regular update timeframes) and apply patches in a controlled manner according to the procedure usual for your organization.
  4. Immediately run the available security updates/patches as soon as they are published on the systems and verify that the updates have actually been applied. In case you have an external IT service provider: Have your provider perform these actions and have them confirm the actions and their result to you in writing.

Do you have systems where the risk is high (for example, systems with very sensitive or special personal data)? If so, do you possibly have indications that the system cannot be mitigated and/or updated immediately? Then consider temporarily disabling the system until it can be updated.

If your organization is suspected to have been the victim of an attack, the urgent advice is to have research conducted into the cause, to what extent attackers may have compromised other systems and what information may have been accessed unauthorized.

  1. If possible, disconnect affected systems from the network, but leave them on (in connection with any traces such as volatile memory - RAM);
  2. Have the affected systems forensically examined; ensure adequate backups;
  3. Reset your passwords and user data;
  4. Report to the Police;
  5. Consider filing a report with the Personal Data Authority.

Does your organization currently have an incident? Our Computer Emergency Response Teams
(CERT) are available to organizations 24/7 to support IT Security Incidents.
Then call 088 133 0700 and we will do our best to help you as soon as possible.

Learn more about our Incident Response Service

Does your organization currently have an incident? Our Computer Emergency Response Teams (CERT) are available to organizations 24/7 to support IT Security Incidents.

Then call 088 133 0700 and we will do our best to help you as soon as possible. Here you will find more information about our Incident Response service.

Disclaimer: NFIR has made every effort to make this information accurate and reliable. However, the information provided is without any guarantee of any kind and its use is entirely at the risk of the user. NFIR assumes no responsibility or liability for the accuracy, content, completeness, legality or reliability of the information provided.