In the first blog of the series, we discussed in-depth details about CVE-2021-26855, which is an unauthenticated Server Side Request Forgery (SSRF) in the Microsoft Exchange Server. In this blog, we will take a look at CVE-2021-27065 and DearCry ransomware.

CVE-2021-27065

This is a post-auth, arbitrary file write vulnerability in the Exchange Server. An adversary can exploit this vulnerability and write or overwrite arbitrary files in the system. Since this is a post-auth vulnerability, the adversary should be authenticated as an user to abuse the same. 

Let’s look at the vulnerability details and link the SSRF vulnerability with this and create a perfect Remote Code Execution (RCE). We’ll be discussing CVE-2021-27065 for arbitrary file-write.

IReferences [1] and [2] mentioned at the end of the blog point towards the DDI service and try to modify an object’s Offline Address Book (OAB) Virtual Directories in the Exchange Server. They seem to be using an Exchange Server powershell (exchange management shell) for setting an object. In-the-wild exploitation logs in [2] clearly point to the vulnerability location. Refer [10] for more information about the logs.

Now, Here’s the flow to exploit this

1. Elevate account privileges to admin level
2. Set the external URL in the OAB Virtual Directory (add webshell here)
3. Reset the external URL (add path here)

While setting the external URL, the server checks only for the schema, hostname and length of the URL (<256 bytes). so, we satisfied those checks by providing just that and appending our payload to it.

Now, when we reset the OAB Virtual Directory, the existing virtual directory will be deleted and a new virtual directory in the path specified by us will get created with all the properties of the directory and with the extension we prefer.

Now, our payload is present inside this file with .aspx at an accessible location. So, when we execute this file, our payload gets executed. In a typical webshell.we can pass a command/function as parameter that executes the value on the system (like eval).

This looks easy in theory, but how do we link this to SSRF vulnerability and remotely exploit both of the vulnerabilities to achieve RCE?

Below are the steps involved to do that

1. Retrieve LegacyDN through SSRF endpoint
2. Use LegacyDN and pull the SID of admin
3. Authenitcate with proxyLogon and retrieve sessionID and msExchEcpCanary cookie (using SSRF)
4. Use the cookies to hit the DDI service and request for the OAB Virtual Directory. Retrieve OAB ID 
5. Use the OAB ID and session cookies to inject webshell in the external URL
6. Use the same session cookies and OAB ID to reset the virtual directory and include our path
7. The path is then used to execute the webshell

Retrieve the FQDN from the header

Using FQDN, retrieve the LegacyDN through autodiscover endpoint

Use LegacyDN to retrieve the SID of the admin.

We get an error message while trying to access OAB objects using the DDI service as shown in Figure 6.

Error: The user isn’t assigned to any management roles. 

But, the same user is able to change the OABvirtualdirectory manually. Strange !!

This is the interesting part of the exploit. The /ecp endpoint (frontend proxy) allows arbitrary requests through SSRF and all the requests that are sent with X-BEResource cookie may not grant authenticated access to the entire application.

So, there is another vulnerable endpoint “/ecp/proxylogon.ecp” which lets us authenticate using a legit SID. We’ll have to bypass authentication using proxylogon and use the session to proceed further.

RbacSettings class in Microsoft.Exchange.Management.ControlPanel deals with authentication in HTTPproxy.

It expects additional headers and XML body for authentication.The body of the request will go into the SerializedAccessToken().

The header “msExchLogonMailbox” will be used to check for authentication and for creating new ECP identity. After parsing the headers, the code calls for authenticating the mentioned header for identity in GetInBoundProxyCaller().

The code looks up the SID we have mentioned, through FindComputerBySid(). Upon meeting all the requirements, it will return the server name. 

From Figure 7, once the authentication is done, the code creates ECP identity and assigns cookies.

Now, authenticate using the Admin SID and retrieve ASP.NET_SessionId and MsExchEcpCanary cookies.

Retrieve these two cookies and hit GetObject in DDIService and retrieve rawIdentity (i.e., OAB ID).

Now, using the OAB RawIdentity, we can change any object.

Using these three values, the externalURL for the OABvirtualdirectory is changed to our payload.

As discussed earlier, there are limited checks on externalURL. So, we’ll append our payload (total length <256 bytes) to a URL which follows the correct schema.

Now, reset the OABvirtualdirectory. A new file gets created in the path and extension we mentioned. Our payload gets triggered when accessed as we injected Jscript payload in the external URL and our current file has an extension of .aspx.

So, let’s write the file where we can access via the network.

Here it is, 

These are properties of OABvirtualdirectory written into a different file at a different path and reloaded with the updated externalURL.

The file also has code, as we can see that it is in script tags.

Now, we can execute commands on the system when passed to the endpoint with exec_code parameter.

This is a persistent webshell.

Patch

This is the check in WriteFileActivity class in DDI namespace.

This patch forces the written file to be of type .txt thus, preventing web shells.

CVE-2021-26857

This is an insecure de-serialization vulnerability in Unified Messaging Service (UMS). UMS is a component of the Exchange Server that deals with voice-related features. UMS enables users to use voice mail, call answering rules and show both voice and email message in one mailbox.

This vulnerability can only be exploited when UMS is enabled, which is not enabled by default in the Exchange Server. 

What is Insecure De-Serialization ?

Serialization is a process of converting objects and their fields into byte streams for writing/reading into a file or database. De-serialization is exactly the reverse of that. It restores the object from the stream of bytes. Web applications logic interacts with the stream of bytes while converting it to the object.

The adversaries can send manipulated objects to serialize which when de-serialized results in unexpected behaviour. This is often used to elevate privileges.

This vulnerability can also be used to elevate privileges of a limited user in the attack chain before exploiting the arbitrary file write. But, RCE can be achieved without exploiting this as well.

Let’s look at some file-diffs in Unified message dlls and see where the vulnerability is lying. 

The unsafe Base64Deserialize() is replaced with DeserializeObject(). The patch reconstructs the original function into multiple steps. First, by converting the data from base64 to memory stream and then, converting the serialized object data using DeserializeObject. Also, several exceptions are added to handle InsecureDeserialization vulnerability.

Stats

At the time of writing this blog, there were around 60,000 publicly exposed vulnerable Microsoft Exchange servers.

Post Exploitation

In the initial days, we have seen evidence of webshells and exporting mail information using Powercat, Nishang, etc.

Downloading Powercat 

Using Nishang for reverse shell

Soon after that, there were reports of malware authors exploiting 0-day Exchange Server vulnerabilities and dropping a ransomware post-exploitation. On 13th March, we saw the first  ransomware which is dubbed as DearCry exploited in the wild. Let’s look at the details of the ransomware.

DearCry!

Since the release of the OOB patch in March 1st week, a lot has been reported about DearCry ransomware, which was downloaded and executed on Exchange Servers, post-exploitation of the vulnerabilities discussed in the blog.  Here, we will discuss some basic working of the malware to aid the understanding of our readers. 

Ransomware begins its execution with calls to function that use anti-analysis techniques to check for the presence of debuggers.

If no debugger is present, the entry function then calls another function (renamed to main() in Figure 27), which uses StartServiceCtrlDispatcherA() to register ‘msupdate’ service. This might allow ransomware to maintain persistence on the system. StartServiceCtrlhandlerA() is used to set and update service status.

Both main() and handler function, call Ransomware_Encryption() to encrypt the files as shown in Figure 27.

Ransomware has RSA Public Key hardcoded in the binary (Figure 28). The presence of AES related strings suggest that AES symmetric encryption algorithm is used to encrypt the files, and PKI, RSA (asymmetric encryption algorithm) is used to encrypt the symmetric key for AES.

Ransomware enumerates the files using FindFirstFileA() and FindNextFileA() Windows APIs to identify interesting files and encrypt them.

It identifies files with extensions shown in Figure 31 and encrypts and saves them with new extension ‘.CRYPT’.

Hex dump of an encrypted file header shows that the header starts with string ‘DEARCRY!’.  

The ransomware adds a ransom note along with threat actors’ contact address. The ransom note is shown below.

While we were working on this blog, there were already multiple reports of threat actors exploiting these vulnerabilities to gain access to the server.

Recommendations 

• Use VPN or limit access to your Exchange Server by placing it behind a firewall in your internal network. Also, do not expose your Exchange Server to the internet unless absolutely necessary
• Turn on your firewall at all times
• Avoid using the administrator account as the main account on critical machines
• Ensure your systems are up-to-date for OS patches
• Use a reputed security product like K7 Endpoint Security and K7 Total Security to stay protected from the latest threats

Mitigations

• Install the patches if you haven’t already, from Microsoft here
• Investigate your server for IOCs and exploitation
• If you’d like to scan your servers for the vulnerability, microsoft has released an nmap script to detect any vulnerable exchange servers in your network : 
• Disable Unified Messaging service, if not in use
• Disable OAB Virtual Directory, if not in use

We at K7 Computing constantly monitor for such malware and vulnerabilities and ensure that we provide proactive protection against such attacks. Also our Generic Anti-Ransomware feature in our security product flags it before the ransomware can execute. As always, we recommend our customers to use the K7 security products to protect their data and keep it updated to stay protected from the latest threats. 

Indicators Of Compromise (IOCs)

1. By Volexity

• S:CMD=Set-OabVirtualDirectory.ExternalUrl=’
• /ecp/DDI/DDIService.svc/SetObject

2. Logs of in-the-wild exploitation, reported by Crowdstrike

• /ecp/DDI/DDIservice.svc/SetObject?msExchEcpCanary=<redacted>&schema=ResetOABVirtualDirectory#
• /ecp/DDI/DDIservice.svc/SetObject?msExchEcpCanary=<redacted>&schema=OABVirtualDirectory#

3. Hashes of malicious files identified on compromised systems                                                       

File Name	Hash	K7 Detection Name
1.exe	10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25da	Trojan ( 005790de1 )
2b9.exe	2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bff	Trojan ( 005790de1 )
e044.exe	e044d9f2d0f1260c3f4a543a1e67f33fcac265be114a1b135fd575b860d2b8c6	Trojan ( 005790ee1 )

Further Readings 

1. https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/
2. https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
3. https://proxylogon.com/
4. https://www.recordedfuture.com/redecho-targeting-indian-power-sector/
5. https://www.reuters.com/article/health-coronavirus-india-china-idUSKCN2AT21O
6. https://cobalt.io/blog/a-pentesters-guide-to-server-side-request-forgery-ssrf
7. https://docs.microsoft.com/en-us/exchange/architecture/architecture?view=exchserver-2019#client-access-protocol-architecture)
8. https://www.exploit-db.com/exploits/49637
9. https://portswigger.net/web-security/deserialization
10. https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/
11. https://packetstormsecurity.com/files/161938/Microsoft-Exchange-ProxyLogon-Remote-Code-Execution.html