How do I debug and analyze the Office EPS vulnerability sample?

Posted on | In

Preface

Recently, an APT organization began to use Office EPS vulnerability samples to attack again. Because EPS syntax adopts inverse Polish notation, it is difficult to understand statically. This article shares some experiences of the author on dynamic debugging of EPS vulnerabilities.

3 EPS vulnerability

There have been three vulnerabilities in Office EPS components, namely CVE-2015-2545, CVE-2017-0261 and CVE-2017-0262. Subsequently, Microsoft disabled EPS components, and no new EPS vulnerabilities appeared.

These EPS vulnerabilities are favored by attackers because EPS is a scripting language with similar characteristics to scripting languages such as JavaScript. It is more convenient than traditional Office vulnerabilities in PoC writing, heap injection, mitigation mechanism bypass and Shellcode writing.

Microsoft has already realized the danger of EPS parsing component, so in Office 2010 and above, it will start the sandbox process fltldr.exe (fltldr.exe process has low permission and cannot perform conventional file writing and other operations) to load epsimp32. Flt dynamic library. Therefore, if an attacker wants to use EPS vulnerability to attack users of Office 2010 and above, he needs to use a kernel privilege vulnerability in Shellcode for sandbox escape.

The combinations of Office EPS vulnerabilities and kernel empowerment vulnerabilities that have been observed so far are as follows:

CVE-2015-2545 + CVE-2015-2546
CVE-2017-0261 + CVE-2016-7255
CVE-2017-0261 + CVE-2017-0001
CVE-2017-0262 + CVE-2017-0263
CVE-2017-0261 + CVE-2019-0808

Remarks :

All windbg breakpoints and shifts in this article take this version of Office 2007 as an example:

epsimp32. flt 2006·1200.4518. 0 32bit

Differences of EPS Components in Different Versions of Office

Differences in exploiting vulnerabilities

The difference between EPS components under Office 2007 and Office 2010 mainly lies in whether there is a sandbox mechanism, so the difference used mainly lies in whether there is a matching kernel authorization program. Theoretically, if an EPS vulnerability sample only attacks Office 2007 users, there is no need to embed a kernel empowerment component. At present, most of the actual attack samples observed are embedded with kernel weighting vulnerabilities, so it can be inferred that the attack targets are mainly Office 2010 and above.

Differences in debugging

According to the author’s experience, debugging EPS vulnerabilities under Office 2010 is a troublesome thing, mainly because of the sandbox mechanism of fltldr.exe process, and there are many inconveniences in attaching debuggers to fltldr.exe process for debugging.

Since most CVE-2017-0261 samples can be fully triggered on Office 2007, samples that encounter CVE-2017-0261 vulnerabilities can be debugged on Office 2007 first. However, there are exceptions. Recently, it was observed that a CVE-2017-0261 sample of an APT behaved inconsistently under Office 2010 and Office 2007 (an additional kernel empowerment component was released when running under Office 2010).

How do I locate a shellcode start point in memory

Location Handler Address (IDA)

The Office module responsible for parsing EPS files is called epsimp32.flt, although the suffix is .flt, which is actually a dynamic library. Take the unpatched version of Office 2007 as an example, drag epsimp32. Flt into IDA for reverse. Many PostScript syntax keywords can be located in the Strings interface, and a series of virtual function call entries can be located by cross-referencing these keywords:

image.png

Through this level of entry, you can find the processing functions related to PostScript syntax.

Locate the load of epsimp32. flt

Here, the author takes office 2007 + windbg as an example. In order to break the assembly code in the epsimp32. Flt module, it is necessary to locate the loading place of epsimp32. flt first:

Sxe Id:epsimp32.fit //Broken while loading epsimp32.flt module

After successful disconnection, the windbg interface is displayed as follows:

image.png

Locate the hijacking point of virtual function call

When debugging a vulnerability sample, the ultimate goal is to find the shellcode it executes. The following author shares some experiences on how to locate the EPS vulnerability shellcode entry in memory. In the attack samples of EPS vulnerabilities that have appeared, the control flow is mostly switched by means of virtual table hijacking. At present, there are two virtual table hijacking places observed:

1
2
3
4
5
6
7
// One is within the CloseFileFunc keyword processing routine:`

bp epsimp32+0x30197 // In CloseFi1eFunc, call a vtable func,` The execution flow switching of most CVE-2015-2545/CVE-2017-0261 vulnerability samples is here.

// The other is within the BytesAvailableFunc keyword processing routine:`

bp epsimp32+0×300A6 // BytesAvailabIeFunc` function entry, in which the execution flow of some CVE-2017-0262 vulnerability samples is switched.

If the above address is broken after loading epsimp32. Flt, there is a relatively high probability that it will be broken at the virtual function call hijacking point after the vulnerability is triggered. For example, the latest CVE-2017-0261 sample (md5: 7e74d8708c118c133e6e591ae0fac33b) is finally switched in control flow through the virtual function call at epsimp32 +0x30197:

image.png

Locate ROP gadgets

After the EPS vulnerability sample successfully hijacks the virtual function call, it usually starts with the xchg instruction to switch the stack frame. Here is an example with the help of a CVE-2017-0261 sample (md5: 7e74d8708c118c133e6e591ae0fac33b):

image.png

The purpose of the above instruction is to replace the original eps register value. Dps looks at what information is stored in the forged stack (now stored in eax):

image.png

You can see that the return addresses on the stack are all the addresses of some rop gadgets:

image.png

Locate shellcode

After executing the last ret 0c instruction mentioned above, the rop chain will call kernel 32! The VirtualProtectStub function sets the address of the shellcode to executable:

image.png

Look at each parameter against the declaration of the VirtualProtect function:

1
2
3
4
5
6
7
8
9
10
11
 BOOL VirtualProtect(

​     LPVOID IpAddress,    // 0x6feee0 <- Shellcode starting address

​     SIZE_T dwSize,      // 0x5b617  <- shellcode size

​     DWORD flNewProtect,  // 0x40 (PAGE_EXECUTE_READWRITE)

​     PDWORD Ipf101dProtect,// 0x6e74330

);

Obviously, the starting address of the shellcode is 0x6fee0, and the starting address of the shellcode is obtained after the lower breakpoint is hit:

image.png

Through the above method, the shellcode of the above sample is located at the beginning. At this time, a snapshot of the virtual machine is taken, and the following task is converted into how to debug the shellcode.

LoadEps

Some time ago, the author read an analysis article of CVE-2017-0261 (https://bbs.pediy.com/thread-261442. Htm) in the Snow Forum, and accidentally found that there is a LoadEps loader on Github (https://github.com/kcufId/eps-CVE-2017-0261) which is more interesting. In short, the author of LoadEps wrote an EPS component loader in assembly language. This file will directly call the EPS file for parsing. In this way, EPS samples can be debugged in an environment without Office installed, which brings some simplification to the debugging work in this area.

Samples for LoadEps

The author downloaded and tried LoadEps, and found that it can normally load many EPS files extracted from previous samples, such as the sample of Hello World dialog box (md5: 845ca93dd2f8d74614d687d52b3eee24) and the sample of calculator (md5: 2734e3655a1d30b8948c186b361ffb72). The method is to change the suffix of LoadEps to. Exe in the done folder of the original project, replace the eps.poc file with the eps file to be loaded this time and rename it to eps.poc. Of course, you can also manually change the LoadEPS source code and recompile it.

If LoadEPS can load the current EPS file, the debugging task translates to debugging the epsimp32. Flt module loaded in the LoadEPS process, which can be done in an environment without Office installed, thus simplifying the debugging scenario. Then you can use debuggers such as windbg to load LoadEps to debug EPS files. However, it should be noted that if you directly use the LoadEps.exe compiled by the author, you need to manually set the startup directory in the debugger. Otherwise, LoadEps cannot find eps.poc according to the default directory enumeration method, and you cannot load eps files normally:

image.png

Samples not applicable to LoadEps

However, in the experiment, the author found that LoadEps could not normally load the EPS files embedded in some CVE-2017-0261 samples (md5: 7e74d8708c118c133e6e591ae0fac33b) that appeared this year. When loading related samples with LoadEPS, it was found that it would crash at a registration callback point. The author carefully looked at the LoadEps source code and found that the author did not realize some callbacks that may be involved in EPS loading:

image.png

Remarks:
1
2
3
1. ; ; There will be a judgment condition in the middle to determine whether the condition is RegisterPercentCallback, which is ignored because it is not.

2. ; ; There is a registration callback function ESPCallbacks, which is embedded in the mso module and is not registered.

For these EPS files that cannot be loaded by LoadEps, readers can only load the corresponding docx files and debug them manually with the help of the environment where Office is installed.

Summary of Debugging Ideas

To sum up, the author suggests that the following steps can be taken to analyze such EPS vulnerabilities:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
if (sandbox can separate all results) {

​               // End of analysis

} else if (LoadEPS that can be borrowed plus EPS files that I fear to take) {

​              // Debug with LoadEps.exe and EPS file under debugger

​              // Call the breakpoint at the hijacking point of the virtual function, and step into shellcode

} else if (Vulnerability samples can be tried manually in an Office 2007 environment) {

​                // Call the breakpoint at the hijacking point of the virtual function, and step into shellcode

} else {

​                 // Debug or analyze in its own way under Office2010

}

At present, it has been observed that some EPS vulnerability samples cannot be triggered normally in VMWare virtual machines, but they can be triggered in Hyper-V or QEMU virtual machines. Readers can sometimes consider trying several different virtual machine products if they cannot be triggered in the current virtual machines.

CVE-2015-2545

Https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/twoforonefinal.pdf

Https://www.fireeye.com/blog/threat-research/2015/12/the_eps_awakens.html

Http://blog.morphisec.com/exploit-bypass-emet-cve-2015-2545

CVE-2017-0261/CVE-2017-0262

Https://www.fireeye.com/blog/threat-research/2017/05/eps-processing-zero-days.html

Https://bbs.pediy.com/thread-261442.html

LoadEps

Https://github.com/kcufId/eps-CVE-2017-0261

Author

Lieying.Lab - DBAPPSecurity