-
-
[翻译]Egg-Hunting With New PowerPoint Zero-Day Exploit
-
发表于: 2010-1-15 20:01
-
作者：Dennis Elser
译者：youstar
时间：2010.1.15
说明：本来是准备看看Egg-Hunting技术的，但是无意中搜索到这篇文章，顺便翻译了一下，翻译完才发现没怎么讲
继续找。翻译得很差，因为英语太次了，希望以后能有所进步!
正文：
As a follow-up to my colleagues’ blog post about the newest Office exploits, here is an analysis of one of the Microsoft PowerPoint Zero-Day exploits that once again are used in targeted attacks to infect victims with a trojan horse. The malicious presentation files abuse a new, yet unpatched hole in Microsoft PowerPoint and causes it to execute code infiltrated by the attackers. This blog post shows how the shellcode works and what it does, right after an innocent victim opens the malicious file – if the attacker gets their way of course!
作为我同事博客最近报道的Office利用新闻的继续，这里是对微软幻灯片的一个0 day利用程序进行分析，这个利用程序再次用于有针对性的攻击感染了特洛伊木马的受害者。这种恶意的演示文件滥用新的但Microsoft PowerPoint尚未修补的漏洞，执行攻击代码。本博客阐述了当无辜的受害者打开了恶意文档后shellcode是如何工作的和做了些什么，当然这也是攻击者达到的目的。
For size reasons, the code is split up into several parts that are scattered among the malicious PowerPoint file. Part one of the shellcode consists of an “egghunter”, which is used to relocate the remaining part of the shellcode in memory. In order to do that, it first sets up an exception handler that prevents crashes when accessing bad memory locations, then goes on a hunt for the shellcode’s prepended egg (0xD1CF11E0). Once that egg (which is a marker for the beginning of the shellcode’s second part) is found in memory, code execution is transfered to the code following it.
因为大小的缘故，代码被分成几部分然后分散在恶意的PowerPoint文件中，Shellcode的第一部分包含一个“egghunter”，这部分被用来重建在内存中剩下的shellcode代码。为了达到这个目的，它首先建立了一个异常处理程序防止程序访问错误的内存地址崩溃，接着继续寻找shellcode的预置egg（0xD1CF11E0）。一旦在内存地址中发现egg（这个部分在shellcode的第二部分被标记），执行代码就传过去接在接在他代码的下面。
Part two of the shellcode begins with a loop that looks for a writable memory block of at least 1KB in size (starting at address 0×30000000). Another loop then XOR decodes another part of the shellcode into that memory location and branches to it. Once decoded, a filename (”fssm32.exe”) can be seen in the disassembly. In order to either download or drop a second-stage executable, shellcode needs access to operating system API functions. The ones it needs are going to be imported by parsing OS internal structures, such as the Process Environment Block, to locate kernel32.dll, then parsing the library’s PE header to locate the desired function pointers.
Shellcode的第二部分以一个循环开始，用于寻找至少1kB的可写的内存块（以0×30000000为开始地址）。另外一个循环异或解码shellcode的另外一部分到内存中并进行分支（翻译不妥），一旦解码成功，可以在汇编中看到一个名为(”fssm32.exe”)的文件，为了下载或者释放第二个可执行程序，shellcode需要访问操作系统的API函数。这些需要通过对操作系统内部结构进行分析然后导入，比如说进程环境块，加载kernel32.dll，然后解析库文件的PE头从而找到想要的函数地址。
As shellcode mostly needs to fit into a size-limited block of memory, this piece of exploit not only has its code split into several parts for it to work reliably, it also uses 32bit hashes of API functions to import, rather than a list of respective function names which would consume more space. The shellcode’s ROR-13 hashing algorithm iterates over any exported API function name and compares it against its given list at run-time. Applying the same technique when statically analyzing shellcode, the list of imported functions becomes readable. Looking at the now readable list, it does not contain any function which would indicate the shellcode to download a file but rather drop an embedded one from the PowerPoint file and execute it.
由于shellcode主要是需要适应大小受限的内存块，利用程序的片不仅需要把代码分成多个部分为了更可靠的运行，也使用32位API函数散列接口，而不是各自函数列表消耗更多的空间。这个shellcode对导出的API函数名称进行ROR-13哈希算法迭代，并与运行时的列表进行对比。在静态分析shellcode的时候运用相同的技术，输入的函数列表变得易读。现在看看这个可读的列表，他没有包含任何表明这个shellcode是下载者的函数，而这个文件的事实上是从PowerPoint中释放一个文件并执行它。
Using a hex-search for typical indicators of an executable file, such as an “MZ” or “PE” header doesn’t yield any feasible results – which is not astonishing at all. Of course, the attackers responsible for having built the exploit intended to prevent their cover being blown by something as obvious as an executable that is embedded into a PowerPoint presentation file! By looking more closely at the shellcode, there is another suspicious XOR-decoding loop.
使用十六进制搜索可执行文件的典型标记，比如说一个“MZ”或者“PE”头不会产生任何可行的结果，这一点也不惊奇。当然攻击者很负责地构造利用程序来防止操作很明显地被发现，比如说把一个可执行程序嵌入进PowerPoint演示文稿文件。通过对shellcode更进一步哦研究，发现一个另外一个可疑的异或解码循环。
The loop decrypts a given memory block using an 8bit XOR key.By incorporating the same decryption-loop into a Python script and applying it to the PowerPoint file (see screenshot below), both an MZ- and PE header surface in the hex editor. It’s the embedded executable that was assumed to hide between the PowerPoint “slides” – the malware can finally be extracted.
通过一个8位异或对给定的内存块进行循环解密。通过一个python脚本合并相同的解密环并运用到PowerPoint文件中（请看下图），在16进制编辑器中很明显有MZ-和PE头标志，这就是嵌入的可执行文件并隐藏在PowerPoint的“slides”之间—恶意程序最终能够执行。
McAfee VirusScan products detect this threat as Exploit-PPT.k trojan, McAfee Anti-Malware Gateway Edition (former Secure Computing) detects the new exploits as Heuristic.Exploit.OLE2.CodeExec.PGPG.
McAfee病毒扫描产品检测到了威胁并作为Exploit-PPT.k 木马处理，McAfee反恶意软件网关版（先前的Secure Computing公司）检测了新的利用程序并判定为Heuristic.Exploit.OLE2.CodeExec.PGPG。
原文地址：
http://www.avertlabs.com/research/blog/index.php/2009/04/07/happy-easter-egg-hunting-with-new-powerpoint-zero-day-exploit/
文档下载：
Egg-Hunting With New PowerPoint Zero-Day Exploit.rar
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
|
|
|
|
