In recent weeks, we have seen first-hand the importance of having early detection capabilities, the correct implementation of security measures, up-to-date software as well as an incident response plan in place to effectively deal with threat and emergencies that might occur.
The vulnerabilities in Microsoft Exchange servers allegedly exploited by Hafnium, a group of cyberattackers originating from China, are important and should be taken seriously as they allow cybercriminals to remotely execute commands on affected servers without the need for credentials. The breach compromised the privacy and security of thousands of companies around the world with victims including government agencies, defence contractors and medical researchers.
On March 2nd, Microsoft released patches to tackle four severe vulnerabilities in their Exchange Server software. A week later, on March 10th, a working exploit for the Exchange flaw was published on Github and later removed by Microsoft, which owns the platform. The publication of this exploit granted access to an explosive number of compromised servers - in addition to those previously compromised by other APT groups - affecting more than 30,000 in the United States only.
What are the vulnerabilities and why are they important?
These critical vulnerabilities, collectively known as ProxyLogon, impact on-premise Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019:
- CVE-2021-26855: CVSS 9.1: a Server Side Request Forgery (SSRF) vulnerability leading to crafted HTTP requests being sent by unauthenticated attackers. Servers need to be able to accept untrusted connections over port 443 for the bug to be triggered.
- CVE-2021-26857: CVSS 7.8: an insecure deserialization vulnerability in the Exchange Unified Messaging Service, allowing arbitrary code deployment under SYSTEM. However, this vulnerability needs to be combined with another, or stolen credentials must be used.
- CVE-2021-26858: CVSS 7.8: a post-authentication arbitrary file write vulnerability to write to paths.
- CVE-2021-27065: CVSS 7.8: a post-authentication arbitrary file write vulnerability to write to paths.
If used in an attack chain, all of them can lead to Remote Code Execution (RCE), server hijacking, backdoors, data theft, and potentially further malware deployment.
What are some of the exploits that have been published and how does it work?
There are many publicly available PoCs for the mentioned Microsoft Exchange vulnerabilities. A few examples are:
We wanted to showcase the kind of requests and responses going through during the exploitation chain (CVE-2021-26855 and CVE-2021-27065). In order to do so, we simply sent the packets through a proxy software. In this particular example, we used hausec's PoC.
Step 0: Running the PoC
First, we need a user with a valid mailbox which will alow us to run the PoC. See example below.
We then perform a GET request to a 3-letter random named JS file in order to get the FQDN of the target server.
All requests made to this JS file (starting from this step) make use of CVE-2021-26855, the SSRF vulnerability.
If the server is vulnerable, we can see the FQDN value from "X-FEServer" in the response.
Similar to the previous request, we then call the autodiscover service to get a LegacyDN value. Email addresses needed to run the PoC are used during this step.
We then map the endpoint with the LegacyDN value previously retrieved. With this request, we are able to trigger an error which reveals the SID of the user.
Now that we have the SID value, we can attempt to obtain Session ID and Canary Token values which are needed to perform the arbitrary file write vulnerability.
The Proxylogon.ecp file from the ECP (Exchange Control Panel) service provides us with these values.
We then test the Session ID and Canary Token values to see if they work.
Once we have a valid session, we can proceed to the next vulnerability: CVE-2021-27065, arbitrary file write.
During this step, we get an OabVirtualDirectory object to access the Offline Address Book (OAB) ID value.
Using the OAB ID (RawIdentity value) from the previous step, we set OABVirtualDirectory's ExternalURL value with a malicious payload that runs a JScript webshell.
We then call ResetOABVirtualDirectory with a FilePath value. This action will write a file named shell.aspx under the "/owa/auth/" directory.
If we check the shell.aspx file on the exchange server's "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth" directory, we can see that the following file has been created:
At this point, all that is left is to run the webshell with a payload. Executing a "whoami" command reveals that we are now able to perform a remote code execution with SYSTEM privileges.
What we did
Based on the exploit analysis and Microsoft research, the default path where the webshell is hosted is: "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\".
In addition, below we reference the file names we used in these attacks:
With this information it is possible to automate the detection of servers compromised with these files as long as the aforementioned conditions are met:
Results of the vulnerability patching progress
Whenever a critical vulnerability is disclosed, the CyObs team immediately proceeds to create an identification/verification method for that particular vulnerability. These "plug-ins" are loaded onto the CyObs platform and immediately launched to obtain the exact number of vulnerable elements found within the scope - whether it is a private company, a government or a whole country.
Timeline of vulnerable IPs - Chile:
Timeline of vulnerable IPs - Peru:
Timeline of vulnerable IPs - Bolivia:
Timeline of vulnerable IPs - Switzerland:
Prior to the 19th of March, the CyObs scans had found 1300 vulnerabilities. On the 19th, 769 vulnerabilities were recorded. Since then, the level of patching has slowly stabilised and we have seen a slower rate of patching:
During the first two weeks we saw a quick drop in the number of vulnerable IPs in Switzerland. Since then, only Switzerland and Chile have gradual decreased their number of vulnerable IPs.
Based on our observations, Bolivia and Peru have not shown much change over the analysed perio
Manufacturer Information and Mitigations: