Introduction
ProxyNotShell is composed of two CVEs, which allow for authenticated remote code execution in Microsoft Exchange versions: 2013, 2016 and 2019, these exploits can be chained together to perform an RCE attack from an authenticated low-privilege mail user, resulting in full control over the exchange server.
Microsoft have deployed patches to fix these vulnerabilities after previous mitigations were found to be ineffective.
In August 2022 Vietnamese security researchers discovered an attack on their Exchange servers. Their internal blue team noticed malicious requests in their logs resembling a format similar to a previous Microsoft Exchange exploit ‘ProxyShell’, a vulnerability which also allowed for remote code execution.
Vulnerabilities Involved in ProxyNotShell
An Authenticated Server Side Request Forgery attack allowing an attacker to generate requests on the server’s behalf
Vulnerabilities in Depth
A Remote Code Execution vulnerability that allows Microsoft’s exchange ‘remote powershell’ feature to be leveraged to pass system commands to the server.
Two vulnerabilities are used in the ProxyNotShell attack, which, when combined together, allow for Remote Code Execution on locally deployed Exchange servers:
CVE-2022-41040
The first vulnerability in the exploit chain is CVE-2022-41040, which is a Server-Side Request Forgery vulnerability in the Exchange software that enables an attacker to gain access to the internal PowerShell API endpoint. This vulnerability is exploited by sending data to the Exchange server’s “autodiscover” mechanism, which is typically used to minimise user configuration and simplify deployment by providing clients access to the Exchange server’s features. Using maliciously crafted data sent to the autodiscover endpoint along with a known username and password, an attacker can gain access to the exchange environments PowerShell; the attacker can then execute commands in this PowerShell instance by sending them in a payload through the XML SOAP protocol. Once this has been achieved, the attacker has to get access to the “Web-based Enterprise Management” (WBEM) via the WSMAN Protocol, once this is complete the attacker then uses “Windows Remote Management” (PsRemoting) to initiate the shell on the exchange server which allows for further PowerShell script execution.
CVE-2022-41040
The second vulnerability in the ProxyNotShell chain is CVE-2022-41082 which is exploited by sending encoded, serialised data subsequently leading to code execution on the server. In this case it is used to spawn the “System.Windows.Markup.XamlReader” object which processes the XAML data sent in the payload. This then creates a new object from the “System.Diagnostics” class which contains an action to create a new process on the exchange server such as “cmd.exe” or “calc.exe”
Prior Exchange Exploits
‘Proxyshell’ is an exploit in Microsoft Exchange that was unveiled at the blackhat convention in 2021 by Orange Tsai, this involved three separate vulnerabilities in the platform which when chained together allowed for an unauthenticated user to achieve RCE on the system.
Checking ProxyNotShell
The community around Nmap have created a script allowing the exchange service to be checked for susceptibility to this attack. The Nmap script is available on github and allows for multiple hosts to be checked simultaneously. This tool can also detect any server deployed mitigations related to the attack.
Patching and Mitigations
Since being disclosed various patches and mitigations have been issued by Microsoft, with the most recent patch proving to be the most effective. Released on November 8th 2022 the fix was shown to rectify the issues divulged in CVE-2022-41040 and CVE-2022-41082, completely negating the attack. Previous mitigations had limited success and the URL rewrite rule Microsoft released was bypassed within a month.
Vulnerable Devices
Prior to the most recent patch (Nov 2022), all versions of the Microsoft Exchange Service were vulnerable. Using the following filter in shodan ‘http.component:”outlook web app”‘, Exchange and Outlook servers can be listed. When the public were notified of the attack in September there were around 200 thousand Microsoft Outlook servers running the vulnerable software and accessible through the internet.
According to researchers at internet security company Shadowserver, there are currently many servers still running vulnerable versions of Exchange that are susceptible to the ProxyNotShell attack
The chart above shows the number of currently vulnerable Exchange Servers present on the internet, this data is gathered from ShadowServer and is updated live on their website. According to the data, most of the vulnerable servers are in Europe and North America.
In the UK there are estimated to be around 3000 publicly deployed vulnerable servers, at the time of writing, but it does appear that this number is generally decreasing
Proof of Concept and the Fakes
Shortly after the vulnerability was released many bad actors created GitHub repositories with fake proof of concepts requiring payment in cryptocurrencies in order to capitalise on the attention that the attack was getting. Many of these were launched from fake accounts impersonating legitimate threat intelligence reporters such as Kevin Beaumont, a well known researcher who was one of the first to report on the exploit
On November 18th shortly after the final security patch, a proof of concept was released by testanull that allowed security researchers to test the ProxyNotShell exploit and its effectiveness on a live un-patched system. A link to this can be found here.
Patching Policy
To help mitigate 0-day attacks businesses should implement a ‘secure patching policy’ that monitors for new vulnerabilities and patches, this will allow the business to calculate the cost:risk ratio of using vulnerable devices/software and if that risk can or should be mitigated with a patch, or even potentially removed and replaced with another solution entirely. A good patching policy will specify how often and when these tasks are performed, guidance on creating a patching policy for devices can be found at the NCSC website here.
To ensure that businesses are compliant they need to follow strict patching policies which mitigate business risk. Cyber Essentials is a certification developed by NCSC attesting that an organisation’s security posture is compliant with Cyber Essentials defined standards. More information can be found on the Cyber Essentials website which sets out the following requirements in relation to patch management:
The applicant must keep all its software up to date. Software must be:
- Licensed and supported
- Removed from devices when no longer supported
- Patched within 14 days of an update being released, where the patch fixes a vulnerability with a severity the product vendor describes as ‘critical’ or ‘high risk’.*
(NCSC, Cyber Essentials)
To conclude, this paper has explored the ProxyNotShell attack targeting Microsoft Exchange Servers and discussed how chaining multiple less severe vulnerabilities together can be effective at creating a more severe and consequential attack which, in worst case scenarios, can result in complete system compromise. The severity of ProxyNotShell also demonstrates the importance of robust patching policies and that Defence in Depth principles should be utilised to ensure that systems do not contain a single point of failure; as relying on software patches alone, even from reputable vendors, can still leave applications vulnerable.