安全黑客
当前位置:安全黑客文章资讯安全资讯安全新闻
日期:2018-12-01 23:30:00  来源:本站整理

解析XP版永恒之蓝中的一个Bug[安全新闻]

赞助商链接



  本文“解析XP版永恒之蓝中的一个Bug[安全新闻]”是由安全黑客为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:

永恒之蓝漏洞刚出来时,我可以顺利搞定Windows 7,但在攻击Windows XP时我一直没有成功。我尝试了各种补丁和Service Pack的组合,但利用程序要么无法成功,要么会导致系统蓝屏。当时我没有深入研究,因为FuzzBunch(NSA泄露工具集)还有待探索许多点。
直到有一天,我在互联网上找到了一个Windows XP节点,我想尝试一下FuzzBunch。令人惊讶的是,在第一次尝试时,漏洞利用竟然成功了。
那么问题来了,为什么在我的“实验”环境中,漏洞利用无法成功,而实际环境中却可以?
这里先揭晓答案:在单核/多核/PAE CPU上NT/HAL的实现有所区别,因此导致FuzzBunch的XP系统攻击载荷无法在单核环境中使用。
 
0x01 多条利用链
大家需要知道一点,EternalBlue(永恒之蓝)有多个版本。网上已经有人详细分析了Windows 7内核的利用原理,我和JennaMagius以及sleepya_也研究过如何将其移植到Windows 10系统上。
然而对于Windows XP而言,FuzzBunch包含一个完全不同的利用链,不能使用完全相同的基本原语(比如该系统中并不存在SMB2以及SrvNet.sys)。我在DerbyCon 8.0演讲中深入讨论过这方面内容(参考演示文稿及演讲视频)。
Windows XP上,KPCR(Kernel Processor Control Region)启动处理器为静态结构,为了执行shellcode,我们需要覆盖KPRCB.PROCESSOR_POWER_STATE.IdleFunction的值。
 
0x02 载荷工作方式
事实证明,漏洞利用在实验环境中没有问题,出现问题的是FuzzBunch的攻击载荷。
ring 0 shellcode主要会执行如下几个步骤:
1、使用现在已弃用的 KdVersionBlock技巧获得nt及hal地址;
2、解析利用过程中需要用到的一些函数指针,如hal!HalInitializeProcessor;
3、恢复在漏洞利用过程中被破坏的KPCR/KPRCB启动处理器结构体;
4、运行DoublePulsar,利用SMB服务安装后门;
5、恢复正常状态执行流程(nt!PopProcessorIdle)。
单核分支异常
在IdleFunction分支以及+0x170进入shellcode处(经过XOR/Base64 shellcode解码器初始处理之后)设置硬件断点(hardware breakpoint)后,我们可以看到搭载多核处理器主机的执行分支与单核主机有所不同。
kd> ba w 1 ffdffc50 "ba e 1 poi(ffdffc50)+0x170;g;"
多核主机上能找到指向hal!HalInitializeProcessor的一个函数指针。

该函数可能用来清理处于半损坏状态的KPRCB。
单核主机上并没有找到hal!HalInitializeProcessor,sub_547返回的是NULL。攻击载荷无法继续运行,会尽可能将自身置零来清理现场,并且会设置ROP链来释放某些内存,恢复执行流程。

注意:shellcode成功执行后,也会在首次安装DoublePulsar后执行此操作。
 
0x03 根源分析
shellcode函数sub_547无法在单核CPU主机上正确找到hal!HalInitializeProcessor的地址,因此会强制终止整个载荷执行过程。我们需要逆向分析shellcode函数,找到攻击载荷失败的确切原因。
这里内核shellcode中存在一个问题,没有考虑到Windows XP上所有可用的不同类型的NT内核可执行文件。更具体一点,多核处理器版的NT程序(比如ntkrnlamp.exe)可以正常工作,而单核版的(如ntoskrnl.exe)会出现问题。同样,halmacpi.dll与halacpi.dll之间也存在类似情况。
NT迷局
sub_547所执行的第一个操作是获取NT程序所使用的HAL导入函数。 攻击载荷首先会读取NT程序中0x1040偏移地址来查找HAL函数。
在多核主机的Windows XP系统中,读取这个偏移地址能达到预期效果,shellcode能正确找到hal!HalQueryRealTimeClock函数:

然而在单核主机上,程序中并没有HAL导入表,使用的是字符表:

一开始我认为这应该是问题的根本原因,但实际上这只是一个幌子,因为这里存在修正码(correction code)的问题。shellcode会检查0x1040处的值是否是位于HAL范围内的一个地址。如果不满足条件,则会将该值减去0xc40,然后以0x40增量值在HAL范围内开始搜索相关地址,直到搜索地址再次到达0x1040为止。

最终,单核版载荷会找到一个HAL函数,即hal!HalCalibratePerformanceCounter:

目前一切操作都没有问题,可以看到Equation Group(方程式组织)在能够检测不同类型的XP NT程序。
HAL可变字节表
现在shellcode已经找到了HAL中的一个函数,会尝试定位hal!HalInitializeProcessor。shellcode内置了一张表(位于0x5e7偏移处),表中包含1字节的长度字段,随后为预期的字节序列。shellcode会递增最开始发现的HAL函数地址,将新函数的前0x20字节与表中字节进行对比。
我们可以在多核版的HAL中找到待定位的5字节数据:

[1] [2]  下一页


  以上是“解析XP版永恒之蓝中的一个Bug[安全新闻]”的内容,如果你对以上该文章内容感兴趣,你可以看看安全黑客为您推荐以下文章:
  • 解析XP版永恒之蓝中的一个Bug
  • 本文地址: 与您的QQ/BBS好友分享!

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    免责条款 - 广告合作 - 下载声明 - 欢迎投稿 - 友情连接 - 网站地图 -
    Copyright © 2012-2013 www.110hack.com. All Rights Reserved .