In Sept 2021, Microsoft patched CVE-2021-40444, a Remote Code Execution (RCE) vulnerability in Microsoft Office applications, which was being exploited in the wild. This vulnerability was due to weakness in Trident, Microsoft Internet Explorer’s (IE) browser engine. In this blog we will discuss CVE-2021-40444 and briefly look at some related internals of Trident.
Trident
Trident was introduced with IE 4, back in ‘97. Since then it has been part of Windows. Along with IE, Trident supports multiple Windows applications including MS Office and IE mode in MS Edge (MS browser introduced to replace IE in Windows 10). This is the reason why even after IE has been discontinued, Trident remains part of Windows 10 and Windows 11. Trident is backed by MSHTML DLL, responsible for rendering web pages and JS.
CVE-2021-40444
This vulnerability impacts Microsoft Office applications, which utilises ActiveX to render HTML content with support of the Trident engine.
Although there are many malicious documents available online, exploiting this vulnerability, we decided to generate our own malicious document using Metasploit, which contains a reverse shell to connect back to our server, so that we can control what the crafted document is doing.
We started with analysing the malicious word document generated. We extracted the document and took a look at various files present.
The interesting bit was present in the _rels/document.xml.rels file, which stores the references to various resources present in the document. Here we observed an OLEObject relationship targeting an external URL, in this case our malicious HTML hosted on the server.
If you’ll observe closely, the link starts with ”mhtml” and has a “!x-usc:” in the middle. Based on a quick internet search, “mhtml”stands for “MIME Encapsulation of Aggregate HTML” Documents, which is a web archiving format, to combine HTML and resources. The “x-usc” derivative is used to request resources.
This link is referred to when the document loads. If the document loads in Protected mode, this is referred to when the user selects Enable Editing. In our case, the document loaded in Protected mode, and as soon as we allowed editing, msfconsole displayed a message showing that it is sending HTML and JavaScript (JS) files to the target.
Intercepting the communication using the Burp suite, we observed that an obfuscated JS was being sent to the victim machine. This JS is relatively easy to de-obfuscate. Looking at msfconsole output, we observed that it uses a stored template to generate the HTML and JS file. So we got access to the clear text JS as well.
What’s going on here
The JS file, upon execution, instantiates a htmlfile ActiveX object, used to render the HTML page. This is then used to request and download a cabinet (CAB) file, which contains a malicious setup information (INF) file. It then executes the malicious INF file using the .cpl method.
This is a living-off-the-land binary (LoLBins) execution method;employed by numerous types of malware, which utilises existing binaries on the OS to execute malicious code. In this case .cpl refers to the Control Panel item, which represents some functionality provided by the control panel or related programs.
The actual command line parameters passed can be seen in the Rundll command line.
The INF file in our case, is a reverse shell, which on execution will connect back to our Metasploit session.
We analysed multiple malicious word documents available online and the execution flow is similar to the one we observed here. Only the final INF file will perform different tasks like executing the Cobalt Strike payload.
Debugging and Patch Diffing
Microsoft patched multiple files to fix this issue. We analysed MSHTML.dll. Microsoft has introduced a function – IsValidSchemeName().
This function is called from ShellExecURL(). We debugged winword.exe (Microsoft Word executable) setting a breakpoint at ShellExecURL(). This function calls ShellExecuteW() [Figure 7] with URI as its argument. B in Figure 8 is the URI that leads to execution of our INF. The difference in name of the INF is because the screenshot was captured in a different debugging session. The URI in this case is the path to the INF file. As we saw in Figure 5, there are multiple calls to INF using .cpl, we were able to observe all the calls during our debugging session [Figure 8].
ShellExecURL() accepts the Universal Resource Identifier (URI) and calls ShellExecuteW() to open the passed URI. This may be a URL or a file on the machine.
All URI’s begin with a scheme followed by a ‘:’. A scheme let’s application identify how the following characters are to be interpreted. In most cases, this is the protocol that will be used for communication.
The added function, IsValidSchemeName() checks for the presence of non-alphanumeric characters in the URI scheme before ShellExecuteW() is called. In the case of CVE-2021-40444, this will prevent execution of the INF file since scheme ‘.cpl’ has a dot (.), which is a special character, leading to IsValidSchemeName() returning false.
WorkArounds and Mitigations
- Install patch for CVE-2021-40444 if not already installed
- Always open documents in Protected Mode, and do not click on Enable editing if you don’t trust the sender
- Disable ActiveX controls in browser and Office
Further Readings
