I love it when a plan comes together, malware analysts too. Recently I had to analyze some pieces of malware droppers, all of them were using the CVE-2010-3333 vulnerability for Microsoft Office (Stack-based buffer overflow in Microsoft Office allows remote attackers to execute arbitrary code via crafted RTF data, aka “RTF Stack Buffer Overflow Vulnerability.).
Unfortunately, I had only a few Microsoft office versions and none was correctly exploited by the malwares, I had to make a choice:
- Install all the existing versions of office to test them 1 by 1 (I’m not that rich)
- Try to extract the payload from the file (from easy to very hard ;) )
- Fix the exploit for my Microsoft Office installation
I’ve chosen to fix the exploit, this quick note will cover this subject with a basic example (fixing program execution flow), a more complicated example could be the subject for a next paper (ROP Chain rewrite to fix the exploit).
Tools
- Ollydbg
- ImmunityDbg
- mona.py
Analysis
As soon as I open the document in my analysis machine, it crashes (dwwin.exe)
To quickly spot the error, I set Ollydbg to Just-in-time debugging (menu Options->Just-in-time debugging) And reopened the document:
The “Access violation when executing (7893D47B)” error leads us to a non-mapped memory area access (our friend c00000005), the program crashes, end of story.
Without having to analyze the CVE-2010-3333, we already have a good overview of what’s happening here.
EIP (top right): points to an unmapped memory area (7893D47B)
ESP (bot-right): points to nops followed by some opcodes → follow in dump / disassemble → (bot-left): dropper shellcode
What the attacker probably wanted to find at the address “7893D47B” is a jmp ESP/ push esp+ret or some gadget that allows the program to execute the shellcode stored on the stack. To fix this exploit, we just have to find a way to replace the “7893D47B” call to a known jmp esp address, this would redirect the program execution flow to the shellcode.
A nice thing about the CVE-2010-3333 exploit is the way the shellcode is stored in the file (cleartext hexcode). To find where the address is written, we can simply grep it (grep -i ‘7BD49378’ file.doc) → Little endian
Ok, we find where the address is stored, now we just have to update it with an address pointing to a gadget like “jmp esp”. To do this we simply open winword and attach it with immunity, then we run the mona.py command to find jumps (in the log window (Alt-L) with mona.py installed in the pycommands folder !mona jump -r esp)
By default the jump command skips aslr and rebase modules. Mona finds 280 matching address (really effective :p, thanks to the corelan team), we just select one (0x77C35524) and fix the document (sed ‘s/7bd49378/2455c377/’ file.doc > fixedfile.doc).
Now we can open winword, attach it to our debugger and set a breakpoint at 77C35524, finaly we open the document.
BAZINGA, it works ;) We can now analyze the dropper further by stepping into the shellcode.
The shellcode + malware analysis are out of the scope for this paper, the payload is multi-layered encoded (mutliple XOR layers to decrypt the payload). This example is quite basic, but the methodology is the same to fix exploits bypassing DEP with ROPChains, you just have to spend more time to identify ROPChain components.
Mortis