Recently, we came across an unknown document exploit which was mentioned in a blogpost by the researcher @ropchain. As part of our daily routines, we decided to take a look to see if there was something interesting about the document exploit. The sample’s SHA1 used in the analysis is FB434BA4F1EAF9F7F20FE6F49C4375E90FA98069. The file we’re investigating is a Word document called amendment.doc.
In fact, the exploit is not widely covered by AV vendors. Thus it becomes more challenging for any researcher who tries to identify which vulnerability the exploit attempts to leverage. An initial look at the document using a text editor gives no clues either. The purposes of the OLE objects embedded in the document are already explained by @ropchain in his blog post, so we will not discuss them here again. Our main objective in this section is to identify the vulnerability, so we will use a very primitive but effective way to determine its root cause: we want to crash Microsoft Word upon loading the document exploit. Because we know that the third OLE component is responsible for triggering the vulnerability, we strip the other unnecessary OLE components embedded inside the document. Obviously, the size of the new file is smaller after stripping some of the embedded components out of the original document:
Figure 1: Stripped down exploit document to find the root cause of the vulnerability
We are going to analyze the vulnerability on the following test environments:
As we already expected, Microsoft Word crashes immediately upon opening the document:
Figure 2: Exploit crashed Microsoft Word when opening the exploit document
We reproduce the crash a few times to make sure that this is the actual code that we should look into before we dive deeper into the code. Interestingly, we see the ECX always contains the constant address 0x7c38bd50 in all of the crashes. Thus we are fairly convinced that this is the actual code path that we want to look into. Without further ado, we attach WinDBG to WINWORD again and set a DLL loading breakpoint on MSVCR71.dll. This address seems to belong to a Microsoft DLL component because the exploit document attempts to load otkloadr.dll, which in turn loads MSVCR71.dll that will be used to bypass ASLR. We confirm our hypothesis with the following output from WinDBG:
Figure 3: Finding the constant address
At this point, we are inclined to believe that the constant address controlled by the attacker could be hardcoded in the exploit document. So we quickly run RTFScan from OfficeMalScanner to extract the second Word.Document object where the vulnerability resides and eventually we manage to locate the said constant address in document.xml:
Figure 4: XML smart tag that caused the vulnerability
Based on our analysis, these hardcoded addresses are carefully chosen by the exploit author(s) to make sure Microsoft Word will continue executing without crashing the process until it achieves arbitrary code execution. These values appear to be a series of DWORD stored in a structure that will be dereferenced in the function sub_31249E2E. Presumably, the purpose of picking these particular addresses is to always return acpositive value from the function sub_31249E0A. In other words, the exploit author(s) want to ensure that the function sub_31249E0A always returns true to the caller function.
Figure 5: Code path leads to vulnerability
Figure 6: DWORD values from the hardcoded addresses that will be dereferenced in the vulnerable function
After back-tracing further from the vulnerable function, we find that the cause of the vulnerability revolves around the SmartTag parser routine. This routine passes a wrong type structure and eventually dereferences the value in sub_31249E0A incorrectly. Coincidentally, this value is defined in the SmartTag element attribute. With the understanding of how the vulnerability works, we further verify our findings by crafting different proof-of-concept (POC) documents and these POC documents crash Microsoft Word reliably.
Figure 7: SmartTag parser passed a wrong type structure to the vulnerable function
With the vulnerability information obtained above, it is possible to find out which vulnerability the document is exploiting. Since Fortinet is also a partner in the Microsoft Active Protections Program (MAPP), it becomes one of the valuable sources to verify our findings. We managed to find a report which is aligned to our findings and thus concluded the document is exploiting vulnerability in CVE-2015-1641.
By leveraging the incorrect structure type passed to the vulnerable function, the exploit author attempts to corrupt some part of the memory from MSVCR71.dll, a non-ASLR DLL module. A function pointer in MSVCR71!acmdln+0x4 will be referenced upon executing the vulnerable function and this function pointer will be corrupted and replaced with an arbitrary value at some point:
Figure 8: Memory corruption on MSVCR71!acmdln+0x4 lead to arbitrary value overwrite
The first stage shellcode will be stored in a heap-spray address sprayed via the ActiveX component embedded in the document. The heap-spray buffer is allocated with size 0x1ffa00 (2095616 bytes) which is exactly the file size of activeX1.bin. The execution will be transferred to the first stage shellcode at 0x08080808 upon calling MSVCR71!acmdln+0x4:
Figure 9: Arbitrary code execution on heap-spray buffer containing the nop-sled and shellcode
Figure 10: First stage shellcode in heap-spray buffer
In this section, we will briefly discuss the characteristics of the first and second stage shellcode:
In conclusion, this vulnerability is clearly being actively exploited by the attackers. One of the reasons is definitely because of the exploit stability which can guarantee a successful exploitation on all vulnerable version of Microsoft office. Looking for the CVE number and the vulnerability description on Internet, we could identify some groups potentially distributing the exploit. We can further confirm our theory when we saw the exploit document includes a calc.exe payload which is a common POC payload for demo purposes. Furthermore we are able to identify the threat actor who is possibly closely related to this exploit by analyzing the RAT payload. In part 2 of the blog post, we will be discussing the possible source of this attack.
Fortinet released AV detection MSOffice/CVE_2015_1641.A!exploit and IPS signature MS.Office.RTF.Array.Out.of.bounds.Memory.Corruption to cover this threat.
-= FortiGuard Lion Team =-