Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about the Office 0day vulnerability CVE-2018-0802 repaired by Microsoft. The article is rich in content and analyzes and describes it from a professional point of view. I hope you can get something after reading this article.

Brief introduction

The office 0day vulnerability (CVE-2018-0802) captured by the core security advanced threat response team was fixed in the January 2018 Microsoft security patch, which affects almost all office versions currently supported by Microsoft. This is the second advanced threat attack in the field to exploit zero-day vulnerabilities since the first Office 0day vulnerability (CVE-2017-11826) was intercepted worldwide. The core security team has been actively communicating with Microsoft to promote the repair of the 0day vulnerability and disclose the vulnerability information after the vulnerability has been properly resolved. The technical principle of this vulnerability is similar to the 17-year-old "Nightmare Formula" vulnerability (CVE-2017-11882). It is another attack launched by hackers using EQNEDT32.EXE, a formula editor embedded in office, and we name it "Nightmare Formula II" (CVE-2018-0802).

Attack flow analysis

We have captured several "Nightmare Formula II" attacks in the field, and the wild samples embed two formula objects that make use of Nday vulnerability and 0day vulnerability to attack at the same time. Nday vulnerability can attack unpatched systems, 0day vulnerabilities attack full-patch systems, bypassing the ASLR (address randomization) security measures of CVE-2017-11882 patch, and the attack will eventually implant malicious remote control programs into the user's computer.

Figure: "Nightmare Formula II" attack flow of wild samples

Vulnerability detail analysis

The "Nightmare Formula II" patch for CVE-2017-11882 bypasses the vulnerability and the type is stack overflow. The root cause is that Microsoft did not fix another stack overflow when copying font FaceName in the "Nightmare Formula Generation" patch. This vulnerability will only cause crash in unpatched versions, but it can be perfectly exploited in patched versions. Let's analyze the CVE-2018-0802 vulnerability through poc samples.

Static analysis

As with CVE-2017-11882, the trigger data for this vulnerability is in the "Equation Native" stream of the extracted OLE object. The red line circled in figure 1 is the core data, with a total of 0x99=153 bytes. 0x08 stands for font tag, followed by 00 01 for the typeface and style of the font, respectively, and the area from 33 to 2500 is the Font name, which is the data copied when the stack overflows. This part of the data contains shellcode, bypass ASLR skills, the process command line, and related data for populating, which we will analyze later.

Figure 1

Equation Native data structure

According to the information made public on the Internet, the data of the whole "EquationNative" is composed of:

EquationNative Stream Data = EQNOLEFILEHDR + MTEFData

Where MTEFData = MTEF header + MTEF Byte Stream.

The structure of QNOLEFILEHDR is shown in figure 2:

Figure 2

The structure of MTEF header is shown in Table 1. With regard to this structure, we have observed differences between the actual data and the format specification. The following table is dominated by the actual observations:

Offset specification value 0MTEF version number 0x031 the data generation platform 0x00 means that the data is generated on the Macintosh platform, 0x01 means that the data is generated by the Windows platform 2 the product 0x00 is generated by MathType, and 0x01 means that the formula editor generates 3 product major version number 0x034 product minor version number 0x0A

Table 1

In the attack sample, the MTEF ByteStream structure is shown in Table 2:

Initial SIZE record FONT record FONT content remaining data

Table 2

The FONT record and the FONT content structure are shown in Table 3:

Member description remarks tag0x081 byte tfacetypeface number 1 byte style font style 1 byte name font name ASCII string ending with NULL

Table 3

Patch bypass analysis

The trigger point for CVE-2018-0802 is located in sub_21E39 (the module base address is set to 0 in IDA). As shown in figure 3, you can see that the function of this function is to initialize a LOGFONT structure based on the font data in the formula:

Figure 3

Let's take a look at Microsoft's description of the LOGFONT structure (figure 4). You can see that the last member of this structure is lfFaceName

Graph 4:LOGFONT structure

Let's take another look at Microsoft's description of lfFaceName members (figure 5). You can see that lfFaceName represents the typeface name of the font, and on the analyzed version, it is a chartype string with an empty ending, with a maximum length of 32, including the Terminator NULL.

Figure 5

The problem is obvious: the code in the red box in figure 3 does not limit the copy length when copying the font FaceName, while the copied source data is the font name provided by the user, and the destination address is a LOGFONT structure address passed in by the parent function. Going back to the parent function of sub_21E39 (figure 6), we can see that this address is on the stack opened by the parent function and is a local variable of the parent function. By constructing malicious data, the attacker overwrites the last two bytes of the return address of the parent function (sub_21774), and then directs the control flow to shellcode on the stack.

Figure 6

In the process of analysis, we found a suspected recursion. Figure 7 is the disassembly code of sub_21774. We can see that sub_21774 first calls the vulnerability function sub_21E39 to initialize a LOGFONT structure, then calls the relevant API, passes in this structure, and obtains a font name from the system to save to Name. Then, it compares the obtained Name with the lpLogFont provided by the user. If it is inconsistent (and the sub_115A7 function needs to return False), it will continue to call or not call itself according to the conditions specified by A3, where A3 is the third parameter of the sub_21E39 function.

Figure 7

Let's take a look at the parameter passed in the third parameter, otherwise there may be multiple recursions and cannot effectively take advantage of this overflow. Based on the previous debugging results of CVE-2017-11882 (figure 8), we can see that when parsing user-supplied font data, the function that calls sub_21774 is sub_214C6. Let's go back to sub_214C6 (figure 9). Before sub_214C6 calls sub_21774, the value passed to the third parameter is 1, so if (A3) in figure 7 is true. Let's take a look at figure 7. Sub_21774 recursively invokes itself with a value of 0 for the third parameter, which means that it will not call itself again, and the recursive level will only be level 1. At the end of the analysis, the doubt of recursion is solved.

Figure 8:CVE-2017-11882 triggers the execution flow

Figure 9

There is another problem here, that is, if the _ strcmpi (lpLogfont,&Name) is not valid (if the font data is forged by the user, it is certainly not true here), sub_115A7 will be called, which means that it will reach the overflow point of CVE-2017-11882. In the version that has not been patched in November, if you want to successfully take advantage of CVE-2017-11882, the point of CVEML 2018-0802 will not overflow, because the former requires a much smaller overflow length than the latter, and the copy is truncated with a NULL symbol (we know that controllable eip overflowing to CVE-2017-11882 only needs 0x2C bytes, while through the analysis below (figure 11) we can know that controllable eip overflowing to CVE-2018-0802 requires 0x94 bytes). On the other hand, in versions that are not patched in November, if you want to trigger CVE-2018-0802, you must trigger CVE-2017-11882 first. In short, CVE-2018-0802 is not available on pre-patch 11 versions.

However, as you can see from figure 10, in the November patch, Microsoft imposed a 0x20 length limit on the copy length before the copy of the CVE-2017-11882 overflow point, and after the copy was completed, a NULL was manually added at the end of the copy, thus invalidating CVE-2017-11882. This directly leads to the use of CVE-2018-0802, which cannot be used before patching! Now, as long as sub_115A7 returns False, the vulnerability can be perfectly exploited, while the actual debugging found that sub_115A7 returned False.

Figure 10

Dynamically analyze the data copy of the overflow point

With the above analysis, dynamic analysis becomes very simple. Since the data will be copied at this overflow point, let's monitor the source string and corresponding stack backtracking during each copy. We first enter the Load function (sub_6881) related to OLE data, and then enter the breakpoint and output it before copying the data. The result is shown in the code:

You can see from the log that there are two copies, and through stack backtracking, we can see that these two copies are the two calls to sub_21174 in static analysis. The first is sub_214c6 's call to sub_21174, and the second is sub_21174 's call to itself. You can see that there is an obvious stack overflow on the first copy. Just to mention here, cb ce cc E5 represents the Song style.

Let's calculate in detail how much length we need to overflow to control the return address of the parent function (sub_21174) (the conclusion of this problem is mentioned in the section "Patch Bypass Analysis"). As you can see from figure 11, overflow from lfFaceName (- 0x90) to ret_addr (+ 0x4) requires a total of 0x94 bytes, and bytes beyond the 0x94 will overwrite the return address one by one from the low address.

Figure 11

Let's take a look at the data in poc. As shown in figure 12, the blue part is the first 0x94 byte of the overflow, 2500 is the last two bytes of the overflow, 00 is the Terminator, and the copy is stopped when it encounters 00. According to the small-end address layout, when poc is running, the EIP will only be overwritten by the low-end 2 bytes. Why would you do that? The answer is to bypass ASLR.

Figure 12

Bypass ASLR

Let's take a look at why ASLR can be bypassed in just two bytes.

First of all, let's be clear that the patch file has ASLR turned on, as shown in figure 13. As a result, the base address of each EQNEDT32.EXE load is random, so the first issue to consider when overflowing is how to bypass ASLR. (as for DEP, you can see from figure 14 that DEP is not enabled in the EQNEDT32.EXE of the patch file, so normally there is no need to consider DEP.)

Unfortunately, the attacker clearly knows a lot about Windows system mechanisms and defense measures. Because on the Windows platform, the ASLR of a 32-bit process randomizes only the higher 2 bytes of the address at a time, while the lower 2 bytes remain the same. If you can find a ret instruction in the same low 0xFFFF space of the address being covered, and satisfy this kind of address like 0xABCD00XY (where ABCD and XY are 6 arbitrary hexadecimal numbers, the penultimate byte in the address must be 0x00, because you need to be accurately truncated after copying), you can directly use this ret to jump to the stack. Since there is no need to bypass DEP, you can execute shellcode directly on the stack.

Figure ASLR status of 13:EQNEDT32.EXE is enabled, DEP is non-permanent DEP

Figure 14: DEP status of EQNEDT32.EXE is deactivated

More unfortunately, in the EQNEDT32.EXE module, Microsoft did and only give such an address (figure 15). There is only one address that meets the condition, that is, the two bytes 2500 covered in the 20025Personality EIP is unique, and there is no second qualified ret.

Figure 15

Let's think about what the original return address of sub_21174 was. Of course, it is the address of the next instruction that sub_214C6 calls sub_21174. From figure 16, you can see that the offset of this address is 214E2. According to the coverage mode of figure 12, the offset after coverage becomes 20025. From the above analysis and figure 17, you can see that this address is a ret instruction. This instruction pops up the first parameter that sub_214C6 gives to sub_21174 and switches the control flow to this value for execution. To make matters worse, this first parameter happens to be lpLogFont, which is exactly the FontName provided by the user. So after the ret is executed, the control flow is transferred to the stack and just begins to execute the first byte of the user-supplied FontName.

Figure 16

Figure 17

Shellcode Analysis of sample A

In the modified poc for sample A, the control flow hijacking and the execution of the shellcode section are shown in figure 18:

Figure 18: due to recursion, the sub_21774 function needs to be returned twice, which explains the first two ret

WinExec is called immediately after the jmpeax instruction, and the command line argument happens to be calc.exe, as shown in figure 19:

Figure 19

Shellcode Analysis of sample B

Sample B bypasses ASLR in the same way as sample A, but the shellcode part is different from sample A. The shellcode of sample B finds the export table of kernel32.dll through PEB (figures 20 and 21), and then searches the export table for the hash value of the desired function given in shellcode through a specific hash algorithm (figure 21). Shellcode then saves the found function address to the place where the hash value was previously stored (figure 22).

Figure 20: the hash value given in the shellcode of sample B and the path name of the copy

Figure 21: find the desired function in the export table of kernel32.dll through the hash value

Figure 22: comparison of data on the stack before and after finding function addresses

After successfully finding the function and saving the address on the stack, first call the ExpandEnvironmentStringsA function to expand the short path (the short path is saved in shellcode), and then call CopyFileA to copy the payload to the word plug-in directory, so that payload is automatically loaded into memory the next time word starts. Finally, call ExitProcess to exit the formula editor process (figure 23). The whole process does not affect the normal opening of the document.

Figure 23: expand the short path, copy the file, and exit the process

The 0day vulnerability used in the Nightmare Formula II (CVE-2018-0802) can be called the twin vulnerability of CVE-2017-11882. One vulnerability in the attack sample is aimed at the unpatched system, and the other is aimed at the patched system, using two OLE to attack at the same time. The carefully constructed attacks by hackers are perfectly compatible with the different situations of the patched environment of system vulnerabilities. The exploit techniques of this vulnerability and the way Bypass ASLR are coincidental to a certain extent, if there is not a qualified ret instruction in the EQNEDT32.EXE module that can be used to bypass ASLR, if lpLogFont is not the first parameter of sub_21774, and if the patch repair mode of CVE-2017-11882 is forced to open DEP protection, the "nightmare formula II" will not have the opportunity.

The latest 360security products have been able to detect and prevent this 0day vulnerability, and we recommend that users update the Microsoft security patch in January 2018.

The above is what the Microsoft fixed Office 0day vulnerability CVE-2018-0802 is like. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.