This afternoon, we posted Security Advisory 969136 describing a new vulnerability in PowerPoint while parsing the legacy binary file format. Unfortunately, we discovered this vulnerability being used to deploy malware in targeted attacks. We expect this blog post will:
- Help you protect your organization from being exploited, and
- Help you analyze suspicious PowerPoint files.
The malware samples we have seen exploiting this vulnerability are the first reliable exploits we have seen in the wild that infect Office 2003 SP3 with the latest security updates. Office 2003 SP3 (released Sept 2007) had a good run being safe from the bad guys but we missed this bug while back-porting fixes found in the Office 12 fuzzing effort to Office 2003 SP3. SP3 was a massive security push that we recommend all Office 2003 customers apply (this vulnerability notwithstanding).
There are a couple workarounds you can apply in your environment to protect yourself from potential attacks using this vulnerability. First, the vulnerable code cannot be reached by PowerPoint files in the newer XML file format. If your environment has mostly already migrated to using PPTX, you can temporarily disable the binary file format in your organization using the FileBlock registry configuration described in the security advisory. Alternatively, you can temporarily force all legacy PowerPoint files to open in the Microsoft Isolated Conversion Environment (MOICE). The steps to enable MOICE are listed in the advisory. In addition to the defense-in-depth sandbox MOICE uses during the conversion, the PowerPoint converter is not vulnerable to this bug so it is safe to use MOICE to “wring out” the unsafe record configuration.
Finally, we wanted to share some tricks to analyze exploits we have seen for this vulnerability. If you have access to any of the samples listed in the MMPC blog post, you can follow along with this mini tutorial to extracting trojans from targeted attacks. This is a dynamic analysis method that does not even require you to recognize assembly. However, you will need a vulnerable version of Office (Office 2003 SP3 in this case) and WinDbg.
Start by setting the Image File Execution Option to set a default debugger for “POWERPNT.EXE”:
- Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
- Create a new key called “powerpnt.exe” (no quotes)
- Click on the new “powerpnt.exe” key and create a new REG_SZ value for called “Debugger” and set its value to “windbg.exe” (make sure you have windbg.exe in your PATH)
Next, double click on the malicious PowerPoint file. You will see the WinDBG window pop up asking you for commands. Set these breakpoints:
- bp kernel32!CreateFileW “.printf \”CreateFileW(\%mu) RetAddr 0x\%08x\\n\”, poi(esp+0x4), poi(esp);dds esp L1; g”
- bp kernel32!CreateFileA “.printf \”CreateFileA(\%ma) RetAddr 0x\%08x\\n\”, poi(esp+0x4), poi(esp);dds esp L1; g”
- bp kernel32!LoadLibraryW “.printf \”LoadLibraryW(\%mu) RetAddr 0x\%08x\\n\”, poi(esp+0x4), poi(esp);dds esp L1″
- bp kernel32!LoadLibraryA “.printf \”LoadLibraryA(\%ma) RetAddr 0x\%08x\\n\”, poi(esp+0x4), poi(esp);dds esp L1″
- bp kernel32!WinExec “.printf \”WinExec(\%ma) RetAddr 0x\%08x\\n\”, poi(esp+0x4), poi(esp);dds esp L1″
This causes the relevant parameters from CreateFile, LoadLibrary, and WinExec to be printed out as they are called. This way, we will be able to see which files the exploit creates, with complete path. Eric Landuyt from DataRescue employed this method to analyze a piece of malware (Hi Eric!). In our scenario, we apply it to shellcode. We also set a breakpoint on “WinExec” because we know that this particular shellcode will use WinExec to execute the trojan file. Sometimes shellcode uses CreateProcess instead. It is important to note that we did not put a “g” for the WinExec breakpoint because we do not want it to execute. We just want the path. To continue the process, hit “g” to let PowerPoint execute. Now, you will see a lot of messages coming up on the screen because PowerPoint actually uses CreateFile/LoadLibrary for legitimate purposes; the shellcode will use it too, but it will be towards the end. Here is an example output:
CreateFileA(C:\DOCUME~1\user\LOCALS~1\Temp\~AC0810.tmp) RetAddr 0x7c802039
00133598 7c802039 kernel32!GetStartupInfoA+0x14b
CreateFileW(C:\DOCUME~1\user\LOCALS~1\Temp\~AC0810.tmp) RetAddr 0x7c801a4f
00133574 7c801a4f kernel32!CreateFileA+0x2b
WinExec(C:\DOCUME~1\user\LOCALS~1\Temp\~AC0810.tmp) RetAddr 0x7c802039
001335ac 7c802039 kernel32!GetStartupInfoA+0x14b
eax=7c86114d ebx=7c802039 ecx=00000000 edx=7c802039 esi=001860f8 edi=001861f8
eip=7c86114d esp=001335ac ebp=00186087 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00200202
7c86114d 8bff mov edi,edi
It is easy to see from the output where the trojan was placed. You are at a breakpoint now so you can safely grab the malicious EXE file and perform whatever analysis you’d like.
Sure enough, ~AC0810.TMP is a malicious PE binary:
You can apply this same fast, simple, generic technique in analyzing EXE malware, PDF, IE, and other types of exploits. Let us know if you have feedback or other analysis techniques you would like to share.
– Bruce Dang and Jonathan Ness, MSRC Engineering
*Postings are provided “AS IS” with no warranties, and confers no rights.*
Update (April 3, 2009): Minor edit to the LoadLibrary breakpoint commands. Thank you to Julio Auto for pointing this out.