Voicemail Vandalism: Getting Remote Code Execution on Microsoft Exchange Server
August 14, 2018 | The ZDI Research TeamWe recently received a bug report with an intriguing description:
“A non-privileged Exchange user can run arbitrary code as "NT AUTHORITY\SYSTEM" in the Exchange Server through a .NET BinaryFormatter Deserialization vulnerability.”
It definitely caught our attention, especially since the quality of the report matched the severity of the bug. Today, Microsoft issued a patch to correct the vulnerability, and we’re providing additional details about the bug itself. First, here’s a video of the exploit in action.
There’s quite a bit going on here, so let’s break things down.
The Setup
To be affected by this vulnerability, the Exchange server needs to be configured with Unified Messaging (UM) enabled. If you’re not familiar with it, UM provides email, voice, and fax messages all in your inbox. While not a default Exchange setting, it’s not unusual for enterprises to have the option enabled. The implementation of this feature has changed over the years, but it remains a core Exchange feature. Beyond that, it’s just the standard Exchange setup.
From the attacker’s perspective, they need to gain access to a mailbox account set up with a UM voice mailbox. In all likelihood, real-world usage of this vulnerability would involve a malicious insider since they already have access to the needed resources to execute this attack. However, an outside attacker could also target a member of an enterprise, usually through spear phishing, then use that access to take over the Exchange server.
If you’re looking to reproduce this in a lab for research purposes, you’ll also need to set up a PBX to allow UM and voicemail. For example, you could set up Asterisk Free PBX for this demonstration.
The Exploit
The exploit begins with the attacker using a script that uses Exchange Web Services to upload a .NET serialization payload to the server. This is seen in the video on the left virtual machine with the Hit Return to Install Payload dialog. Next, the attacker leaves a voicemail message on the UM mailbox of the same account. If you’re an insider, this is your own account. If you took over someone’s account, the attacker leaves that person a voicemail. The voicemail triggers the payload, which results in code execution at the NT AUTHORITY\SYSTEM level.
For this demonstration, we chose to execute the traditional calc.exe, but since the code executes at SYSTEM level, any actions could be taken by the attacker. The final piece here is simply the attacker restoring the original values to the inbox folder on the server to cover their tracks.
The Root Cause
The source of the vulnerability resides in the Inbox folder property called TopNWords.Data. This data is stored on the Exchange server itself. This is a public property, so it can be changed by the user through Exchange Web Services (EWS). It’s likely this property was not meant to be altered by the user.
When receiving a voicemail, Exchange will attempt to turn it into a transcript to display in the recipient’s inbox. Transcription is enabled by default once UM is enabled. To perform transcription, Exchange reads the TopNWords.Data property configured for the user’s inbox, and deserializes it with the .NET BinaryFormatter to obtain a text-to-speech component. An attacker can hijack this sequence by installing a binary payload that runs arbitrary code upon deserialization.
The Patch
In the documentation for the patch, Microsoft notes that the bug is fixed by “correcting how Microsoft Exchange handles objects in memory.” In all likelihood, this means they have restricted access to the TopNWords.Data property. Microsoft lists no mitigations or workarounds for this vulnerability, so applying the patch is the only way to ensure you’re Exchange server gets protected for this issue. Microsoft also lists this as “Exploitation Less Likely” in their Exploit Index (XI) rating. However, as the video above shows, demonstration code already exists. Full exploits are likely not far behind.
Wrapping it Up
This bug shows how simple things can turn into serious consequences if not secured properly. It also shows how the insider threat can be just as real and dangerous as threats external to your enterprise. What good is a solid perimeter if your internal defenses are non-existent? Kudos to Microsoft for patching this bug in a timely manner. Kudos also go to the anonymous submitter for discovering the bug and the fantastic write-up.
If you’re interested in getting the most out of your research and learning what all we look for in a great submission, be sure to check out our previous blog on the topic. Over the next few months, we’ll be publishing details on other well-documented bug submissions and the patches that fixed them. Until then, follow the team for the latest in exploit techniques and security patches.