How the EPS File Exploit Works to Bypass EMET (CVE-2015-2545) – A Technical Exploration

A few days ago @PhysicalDrive0 (malware hunter) published a new word document sample that we were intrigued to check-in Morphisec Labs.  We wanted to see if our product performs its immediate prevention objective. And it did, as expected. When we opened the Word document, the malicious file immediately tried to execute and infect our machine, however, our WinWord application is protected by Morphisec Protector, so the attack was a) immediately prevented (see below), b) trapped, and c) revealed some very interesting malicious activity.

We decided to look deeper into this very clever method and researched the logs from the Morphisec interception. It was especially fascinating that the malicious behavior originated from EPS (image) file processing.

We decided to turn off the Morphisec protection and verify what happens. We were surprised to see that the sample fully bypasses the latest EMET version 5.5 (see below):

Note that for this particular vulnerability, CVE-2015-2545 - “Microsoft Office Malformed EPS (Encapsulated Post Script) File Vulnerability,” a patch has been available since November 2015 (ms15-099). So any system that has implemented this patch should have been protected. But as often happens, many systems go unpatched for a long time since managing the endless stream of patches can be time-consuming and disruptive.

Parallel to our research, @r41p41published findings with regard to the exploit (based on a slightly different sample) in this blog post.  Since @r41p41 already described the EMET Bypass in great detail (I would like to thank @r41p41 for this contribution to our research), I decided to take a different approach, a different look so to speak, rather than researching the low level using our extensive forensic, we opted to do research at a higher level.

Our Analysis of the PostScript Abstraction Level

Here I’ll focus on the PostScript abstraction level by describing the ROP search in the PostScript itself (after slight de-obfuscation). The sample we analyzed is: 23368088b183a8b7dc59f33413a760daa06fa0e027a1996677c97db2aeec22b8

In the following technical description, I focus on the exploitation of 32-bit process, although the exploit works on 64 bit processes as well. The code snapshots represent already de-obfuscated code. It is worth mentioning that almost all of the existing samples for this exploit contain the same EPS file with slight modifications, therefore it is critical to fully understand how it works.

 Exploitation Steps

1. First the code exploits the vulnerability in order to identify if the process is 64 or 32 bit (we will focus on 32bit == 321):
2. It then uses the vulnerability again to corrupt the new vector:

   a/>

3. It then sprays the Heap by allocating a 400 big chunks (size 0Xfffdf) and writes the pattern on every 64k boundary:
4. Then, it defines a set of helper functions

   

5. It defines a function which looks for the MZ Base Address given leaked address from module, the function will subtract 0x10000 (64k) each time from the address until MZ signature is found and NT Header signature is verified.

   

6. It looks for the leaked address from the EPSIMP32 module, and then activates the search for the MZ using previously defined function:

7. It defines a function that searches a module name in the IAT of given module (base address) and returns the relevant import descriptor:

8. It defines a function that searchesa specific function in the import table of a given module (base address), and returns the function address.

   

9. It defines a function that returns the base address of a given module name that exists in the import table of a given module (base address):

10. It defines a function that searches for the system call number given a system call function address. If the first opcode (mov reg, system_call_num) is hooked by any security solution, it will go and look for the next system call until it finds a valid mov command. Additionally, it counts the number of ret’s (system calls that are scanned but hooked), after it finds a valid non-hooked function call, it subtracts from its system call the number of ret’s it encountered.

11. It builds the main ROP after all the functions are defined

• Finds the stack pivoting and ret gadgets.
• Implements VirtualProtect system call by using CreateEvent system call + 5 and executing the mov with the virtual protect system call number
• Inserts the shellcode that will load the plugin.dll with the privilege escalation exploit

As you can see, the hacker has used a clever method to worm its way into people’s endpoints by embedding an EPS vulnerability within a Word file. Today’s applications can have almost anything embedded in them - if you are opening a Microsoft Office file you never know if it has a video, image, or even active content inside. All the more reason endpoint protection solutions need to be application agnostic, like <shameless self-promotion> ahem, Morphisec Moving Target Defense </shameless self-promotion>.

 If you feel that our motto "Long live exploit prevention!" perfectly fits your security needs, take the next step and Schedule a Demo with our security experts.