Initially, Microsoft stated this bug was due to a memory corruption vulnerability and could be exploited by a specially crafted email sent to a vulnerable Exchange server. They have since revised their write-up to (correctly) indicate that the vulnerability results from Exchange Server failing to properly create unique cryptographic keys at the time of installation.
CVE-2020-0688 (exchange server)
Download Zip: https://urllio.com/2vzGCf
Specifically, the bug is found in the Exchange Control Panel (ECP) component. The nature of the bug is quite simple. Instead of having randomly-generated keys on a per-installation basis, all installations of Microsoft Exchange Server have the same validationKey and decryptionKey values in web.config. These keys are used to provide security for ViewState. ViewState is server-side data that ASP.NET web applications store in serialized format on the client. The client provides this data back to the server via the __VIEWSTATE request parameter.
Due to the use of static keys, an authenticated attacker can trick the server into deserializing maliciously crafted ViewState data. With the help of YSoSerial.net, an attacker can execute arbitrary .NET code on the server in the context of the Exchange Control Panel web application, which runs as SYSTEM.
The CVE-2020-0688 vulnerability affects the Exchange Control Panel (ECP) component. The vulnerability affects all installations of Exchange Server because until the most recent patch, all Exchange Servers had the same validation key and validation algorithm in the web.config file. The POC exploits take advantage of same validation key and validation algorithm to craft a serialized __VIEWSTATE request parameter containing an embedded command, signed with the valid key. By default, the POC does not attempt to encrypt the __VIEWSTATE data, although this is an option. The server after, receiving the malicious payload, deserialize the __VIEWSTATE data and execute code as SYSTEM. The image above shows the execution of the POC exploit. The image below shows the Task Manager window where the POC malicious command of calc.exe is executed as SYSTEM.
The exploit first authenticates with the server through a POST/owa/auth.owa request. This POST request contains a valid username andpassword. After a successful authentication, the exploit requests the/ecp/default.aspx page in an attempt to get the content of __VIEWSTATEGENERATORand the ASP.NET.SessionID. Using the data obtained from parsing the__VIEWSTATEGNERATOR, the exploit crafts a serialized payload containing themalicious command to be executed. The final serialized payload is then sentback to the /ecp/default.aspx.
When the exploit sends the payload to the server, the IIS workerprocess w3wp.exe will spawn the malicious command. The figure below illustratesthat the malicious calc.exe is running as a child to the parent w3wp.exeprocess. The calc.exe is also executed by the SYSTEM user.
The CVE-2020-0688 vulnerability is contained in the Exchange Control Panel (ECP) component and is related to the server being unable to properly create unique cryptographic keys because the keys are not randomly generated but are preset with identical values. If we examine the content of the ECP settings in the web.config file from C:\Program Files\Microsoft\Exchange Server\\ClientAccess\ecp, we see that the validationKey and decryptionKey values are already set. These keys are used to secure the ViewState parameter.
On the ASP.NET pages View State presents the state of the page when it was last processed on the server. This parameter is used to create a call context and store values in two consecutive requests for the same page. By default, the state is saved on the client using a hidden field added to the page and restored on the server before the page request is processed. View State moves back and forth with the page itself, but does not represent or contain any information relating to the display of the page on the client side.
As such, pre-shared keys allow an authenticated user to send a deliberate ViewState parameter to the ECP application, which when deserialised will cause malicious code to be executed on the Exchange server in the context of System.
If the vulnerability is successfully exploited, the w3wp.exe process responsible for the ECP (MSExchangeECPAppPool) will execute the payload transferred in the ViewState parameter. Below is the correlation rule to detect cmd.exe commands or the PowerShell interpreter being executed by a w3wp.exe web server process:
The IIS access logs contain a request for the URL /ecp/default.aspx to which the server responded with status 500 (internal server error). Below is the rule for detecting the exploitation of CVE-2020-0688 using IIS events:
Successful exploitation of the CVE-2020-16875 vulnerability allows an attacker to execute arbitrary code on the Exchange server in the context of the System user. The attacker can then escalate their domain privileges and compromise the entire company network.
The attacker must then trick a privileged user (ideally an Exchange administrator) into clicking on a prepared link containing the malicious JavaScript code. This code can send requests to the ECP on behalf of the administrator. This could, for example, be used to exploit the CVE-2021-27065 vulnerability, which we covered in the previous article. As a result, the attacker would gain access to the Exchange server with System privileges via the downloaded web shell.
Previously, in April, Rapid7 researchers found that more than 80 percent of servers were vulnerable; out of 433,464 internet-facing Exchange servers observed, at least 357,629 were open to the flaw (as of March 24). Researchers used Project Sonar, a scanning tool, to analyze internet-facing Exchange servers and sniff out which were vulnerable to the flaw.
A remote code execution vulnerability exists in Microsoft Exchange Server when the server fails to properly create unique keys at install time. Knowledge of the validation key allows an authenticated user with a mailbox to pass arbitrary objects to be deserialized by the web application, which runs as SYSTEM.
On February 11, 2020, as part of Patch Tuesday, Microsoft released cumulative updates and a service pack that addressed a remote code execution vulnerability found in Microsoft Exchange 2010, 2013, 2016, and 2019. The vulnerability was discovered by an anonymous security researcher and reported to Microsoft by way of Trend Micro's Zero Day Initiative. Two weeks after the security updates were released, the Zero Day Initiative published a blog post providing more details on the vulnerability. The post made it clear that an attacker could exploit a vulnerable Exchange server if the following three criteria were met:
Volexity has observed multiple APT actors exploiting or attempting to exploit on-premise Exchange servers. In some cases the attackers appear to have been waiting for an opportunity to strike with credentials that had otherwise been of no use. Many organizations employ two-factor authentication (2FA) to protect their VPN, e-mail, etc., limiting what an attacker can do with a compromised password. This vulnerability gives attackers the ability to gain access to a significant asset within an organization with a simple user credential or old service account. This issue further underscores why changing passwords periodically is a good best practice, regardless of security measures like 2FA. In recent attacks, Volexity has observed the Exchange ECP vulnerability leveraged to do the following:
If you have concerns that your Exchange server has been targeted or may be compromised, there are a handful of directories and resources on your Exchange server that can be examined. Use the details below to search for signs of suspicious or malicious activity. Note: Volexity has primarily investigated incidents involving Exchange 2013 and 2016 servers. It is possible certain log files or data may be different on Exchange 2010 or 2019.
When something goes wrong with ECP, a folder named ServerException may get created in the ECP Logging directory. The existence of this folder and files does not necessarily mean the server has been exploited. This is a normal logging directory for when something goes wrong. With that said, Volexity has looked at several Exchange servers where this folder did not exist at all, and some where there were a handful of unrelated files in the directory. Volexity has also found this folder to have several recent files on exploited Exchange servers. These log files were created when the attackers exploited the servers. In order to look for these files, check for the following directory:
By default, Exchange servers should be logging access via a standard IIS log. The default location will be at C:\Inetpub\Logs\LogFiles\W3SVC1\. This path can be changed and more than one site may be used, which would result in additional or alternate W3SVC# directories. All access to /ecp/ should be logged in these files. Simply looking for requests going to /ecp/default.aspx should be enough to narrow down your search. However, looking at all requests with /ecp/ in the path would be advised. Further examination of these logs should show the same __VIEWSTATEGENERATOR and __VIEWSTATE parameters. As described above, the __VIEWSTATE parameter can then be further examined through base64 decoding to look for signs of exploitation. This log should also capture the source IP address and username that was leveraged in the attack.
An attacker can write malicious files and tools in any number of places. However, attackers often like to start with placing a webshell on Exchange servers. Any folder that is accessible over the Internet through a web browser is a potential target. Attackers will often place files or folders associated with Outlook Web Anywhere (OWA) or the default IIS web directory. A few example directory paths to check for webshells are:
In addition to the sources listed above, it is worth noting that all the commands run by the attackers after successful exploitation would be spawned under the IIS worker process w3wp.exe on the Exchange server. Monitoring for various processes such as PowerShell.exe, net.exe, net1.exe, cmd.exe, ping.exe, nslookup,exe, certutil.exe, etc., where the parent process is w3wp.exe can be an effective mechanism to detect exploitation. 2ff7e9595c
Commenti