Microsoft Outlook flaw opens door to 1-click remote code execution attacks

Microsoft released its batch of monthly security updates this month covering 73 vulnerabilities, including two zero-day flaws exploited in the wild. While organizations should prioritize all critical and high-risk issues, there is one critical vulnerability in Outlook that researchers claim could open the door to trivial attacks that result in remote code execution.

Dubbed MonikerLink by researchers from security firm Check Point Software Technologies who found it, the vulnerability allows attackers to bypass the Office Protected View mode that opens files downloaded from the internet in read-only mode by default to prevent potentially malicious scripts inside from executing.

Email attachments and links are the most common vectors for distributing malware and have been for years. Mechanisms like Protected View make it more difficult for attackers to deploy exploits for existing vulnerabilities in Microsoft Word, Excel, PowerPoint, and other Office components.

“Let’s assume the attacker has an exploit for Microsoft Word working without the Protected View (as this is the most common case),” the Check Point researchers explained. “If the exploit is sent as an attachment, the attacker needs the victim to perform one double-click on the attachment. However, this is not the total because an attachment sent from an external email address would activate the Protected View on Word, and that would block the attacker’s exploit because the exploit doesn’t work when the Protected View is activated.”

“That means the attacker needs to trick the victim to perform another single-clicking to exit the Word Protected View mode, so that his/her exploit can run,” the researchers said. “So, in total, that’s one double-click and one single click for the whole attack chain.”

With MonikerLink, tracked as CVE-2024-21413 by Microsoft, such an exploit chain would require a single click from the user, because the vulnerability exists in the way Outlook calls external applications when users click on a link inside an email message. Furthermore, the flaw could serve as a vehicle to deliver one-click exploits to other applications aside from Word.

Exploiting Component Object Model (COM) behavior

Outlook’s behavior is different for various types of links. For example, for links that start with http:// or https://, the email client will send the link to the default browser installed on the operating system. However, if an email includes links for other protocol handlers, for example skype:, the email client will display a warning that the link might be unsafe before allowing the user to continue and forward the request to the locally installed Skype application, which is the registered protocol handler for skype: links.

Another common link protocol is file:// which would normally call an external application to render the file depending on its format. However, Microsoft has intentionally put a restriction in place to not allow the opening of remote file links — for example, files hosted on a remote network share potentially over the internet.

However, the Check Point researchers found that this restriction could be bypassed by adding the character “!” followed by a random string at the end of the URL. For example, file:///\10.10.111.111testtest.rtf would not work, but file:///\10.10.111.111testtest.rtf!something would work and the file would be passed to Microsoft Word, which is the registered handler for the .rtf file extension.

The reason this works is because the !something part makes Outlook treat the link as a Moniker Link in the context of the Component Object Model (“COM”) on Windows where the part after ! is used to look up a COM object. The Component Object Model is a binary interface through which different software components can communicate with each other. Dating back to 1993 it has served as the foundation for different technologies such as ActiveX or Microsoft Object Linking & Embedding (OLE).

In essence, Outlook strips the file:// protocol handler and parses the link using the “ole32!MkParseDisplayName()” API. This in turn treats it as a compound moniker: a FileMoniker being \10.10.111.111testtest.rtf and an ItemMoniker being “something.”

Because the FileMoniker has the extension .rtf, the API will call a COM server that handles that extension, which happens to be Microsoft Word, which runs as a COM server in the background without the GUI. When receiving the request, Word opens the remote file and then tries to look up a COM object for the ItemMoniker “something.”

It doesn’t matter if a COM object with that name doesn’t exist, because at this point Word has already accessed the remote file as the first step. As it turns out, it did so without the usual Protected View mode that applies to files downloaded from the internet when a user tries to manually open them.

Bypassing protection not the only risk from the Outlook flaw

This has two major implications: First, the request to the remote file location is done over SMB so it leaks NTLM credential information to the attacker-controlled server, which is a security risk in itself. Second, if the .rtf file contains an exploit for an unpatched Word vulnerability, the attackers just bypassed one of the major hurdles they would normally have to get that exploit to execute — convincing users to manually override Protected View on the file.

Furthermore, the researchers demonstrated their proof-of-concept attack using the .rtf file extension to reach Word, but the attack could work with other file extensions too in order to deliver exploits to other third-party applications that register themselves as COM servers and handlers for specific file types.

Email Security, Vulnerabilities, Zero-day vulnerability