转载

MS15-083–Windows SMB内存损坏漏洞

2015年8月11日微软发布了 14个安全补丁 ,其中就包括一个SMB服务器补丁。在本文我将解释我是如何触发该漏洞的。

微软安全公告MS15-083

在所有的修复补丁中,我对“ 服务器消息块中的漏洞可能允许远程执行代码 ”很感兴趣。

“当服务器信息块(SMB)不当处理某些日志记录活动,引发一个经过身份验证的远程代码执行漏洞,最终导致内存损坏。”

受影响的版本包括32位和64位的Windows Vista 和 Windows Server 2008,值得注意的是,这是自2011年以来微软发布的第一个SMB服务修复补丁。

安装补丁

下载“Windows6.0-KB3073921-x86.msu”补丁之后,我试图进行安装,没想到出现了这个

MS15-083–Windows SMB内存损坏漏洞

对此我感到有些意外,因为当安装好一个内核补丁后,操作系统都会进行重启。但在这个例子中,补丁安装程序并没有提示我进行重启。

在“c:/windows/system32/drivers”中我发现“srv.sys”和“srvnet.sys”都被变更了。

另外,我还注意到新的“srvnet.sys”文件日期为2011年4月,新的“srv.sys”文件日期显示正常。

差异阶段–Part 1

将新的“srv.sys”版本(v6.0.6002.19438)与2011年发布的 MS11-020 版本(v6.0.6002.18407)进行对比,惊奇的发现代码根本就没有任何改动!要说有改动也就是编译的字符串改动了。

我寻找着有关该补丁的一些信息,最终在twitter上找到Greg Linares发的一条有关“srvnet.sys”中代码变动的信息。

我联系上Greg之后确认了补丁安装程序的错误,同时感谢其指点,通过使用“expand.exe”命令手动解压了该补丁。

差异阶段–Part 2

补丁解压完成之后,我发现“srv.sys”和“srvnet.sys”的两个版本。将旧的srvnet.sys”版本(v6.0.6002.18462) 和新版本(v6.0.6002.23746)进行差异比较,两个版本都使用相同的补丁安装程序。

在其中我发现7个函数进行了重要改变,更多的则是改动很小:

RfsTableEnumerate  RfsTable64Enumerate  RfsTable64LookupAndEnumerate  SrvGraftName  SrvLibLogError  SrvNetWskEnableInterface  SrvNetWskOpenListenSocket

通过微软安全公告的描述“某些日志记录活动”,所以我重点关注了下“SrvLibLogError”函数,以下为原始代码与新版本的差异比较:

MS15-083–Windows SMB内存损坏漏洞

可以清晰的看到修复了一个整数溢出。

关注“IoAllocateErrorLogEntry”调用代码,可以看到这个修复防止了当日志消息大小大于255字节时“message size”被重新初始化为0。

如果这发生在未打补丁的版本上,没有足够的内存分配给日志消息记录就会产生一个堆溢出。出于某些原因,“message size”变量使用的无符号字符型传递参数是不正确的。在新版本代码中,该变量调整为无符号整型。

差异阶段–开盖有奖

检测“SrvLibLogError”函数在两个版本中的变化,我注意到在Windows 7, Windows 8, Windows 8.1 and Windows 10中这个漏洞依旧存在。

下图为“Windows 10” 64位中漏洞基本块图像,“srvnet.sys” v10.0.10240.16384部分:

MS15-083–Windows SMB内存损坏漏洞

另一方面要说的是,该问题在Windows 2008 R2中被静默修复。

尽管在这些操作系统中重现漏洞是被禁止的,阐明“SrvLibLogError”函数通过“srvnet.sys”输出,以及当使用SMBv1建立SMB连接依旧调用“srv.sys”是非常重要的。

这也意味着,任何Windows驱动(官方或者第三方)调用这个输出函数,这个漏洞将会重现。

利用该漏洞可能的方法

一旦检测到该漏洞,最大的挑战便是写exp找到正确的输出触发该漏洞,本例中我们借助SMB协议。

以下插图为所有的影响到“SrvLibLogError”函数的方法

MS15-083–Windows SMB内存损坏漏洞

在第六个论点中函数接收一个字符串列表进行记录,在第七个论点中其接收数字字符串进行记录。

顺着调用图表一直调用,我发现一个来自“SrvLibLogSpnError”函数的十分有趣的调用,位于相同的库(srvnet.sys)

继续查找,发现该输出函数仅通过函数进行调用,出现在“srv.sys”和“srv2.sys”.

MS15-083–Windows SMB内存损坏漏洞

这也就意味着可以使用SMBv1和v2协议进行攻击。有趣的是,在MS11-020补丁中也调用了“SrvLibLogSpnError”函数

触发阶段–Part 1

使用Windows 7通过执行类似“//192.168.60.60/shared”命令指向到Windows Server 2008,可以看到通过SMBv2当SMB服务接收到一个“Session Setup Request”包以及“NTLMSSP_AUTH”选项时,“srv2!SrvValidateSecurityBuffer”就被调用了。

以下为影响漏洞函数的第一个要求

MS15-083–Windows SMB内存损坏漏洞

“_SmbServerNameHardeningLevel”变量的值不同于0,这个值我们可以在注册表“HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters/SmbServerNameHardeningLevel”中查看,该值为“Server SPN target name validation level”策略相关的设定,也是“SMB hardening”的一部分。

触发阶段–Part 2

将值设置完毕之后,新的问题又出现了

MS15-083–Windows SMB内存损坏漏洞

“MapSecurityError”函数返回错误代码:0xc00000bb,这也意味着,如果这个值不为0,就不能调用记录函数。

阅读 msdn文档 ,我意识到返回值得意思为“STATUS_NOT_SUPPORTED”

“MapSecurityError”函数接收“QueryContextAttributesW”函数的输出作为参数,位于“ksecdd.sys”

在 第二份文档 中,我意识到“ulAttribute”参数的值应该设置为0x1b,意思与“SECPKG_ATTR_CLIENT_SPECIFIED_TARGET”相同。

以下为这个常数的描述:

MS15-083–Windows SMB内存损坏漏洞

分析“ksecdd!QueryContextAttributesW”函数的代码,我确认已经不支持该常数了。

这里就矛盾了,因为补丁修复“Windows Vista”和“Windows 2008”中的漏洞,但是这些能够影响到漏洞函数的方法却无法在这些系统中实现!

触发阶段–Part 3

再次浏览微软公告页面,发现了一个参考链接“Extended Protection for Authentication” (EPA).

为了寻找更多有价值的信息,我在“Security Research and Defense Blog”中发现一篇名为 Extended Protection for Authentication 的文章。

部分阅读:

“微软发布了几个非安全的更新实现身份验证保护延长的机制,用以维护在Windows平台上的身份认证凭证....”

从第一个博客链接中我下载并安装了EPA support for Windows 2008:https://technet.microsoft.com/library/security/973811

触发阶段–Part 4

EPA安装完成之后,“SmbServerNameHardeningLevel”注册表键设置为1或者2,启用“File Sharing”选项并关闭“Password protected sharing”选项。“QueryContextAttributesW”函数返回0(“STATUS_SUCCESS”)

当“QueryContextAttributesW”函数的“pBuffer”参数返回这个值,就变得更加有趣了

MS15-083–Windows SMB内存损坏漏洞

使用Wireshark进行嗅探,我意识到“pBuffer”参数返回“Target Name”的属性“NTLMv2 Response”结构,包含在“Session Setup AndX Request”包中。

基于连接的SMB版本,这是第三个或者第四个SMB客户端发送的数据包

MS15-083–Windows SMB内存损坏漏洞

当我意识到这点,我开始构建和发送“Session Setup AndX Request”数据包,就象这样:

MS15-083–Windows SMB内存损坏漏洞

再然后就这样了

MS15-083–Windows SMB内存损坏漏洞

利用阶段

微软标记的该漏洞的可利用性分数

MS15-083–Windows SMB内存损坏漏洞

现在,我们来看看触发这个漏洞之后到底发生了什么

MS15-083–Windows SMB内存损坏漏洞

当尝试释放 “IoAllocateErrorLogEntry”函数分配的当前块(CURRENT CHUNK),“nt!ExFreePoolWithTag”产生了一个内核异常错误。

最重要的是注意到的是产生堆溢出的池类型(NonPagedPool),这里给出一个 完整的池类型列表

再细看下

MS15-083–Windows SMB内存损坏漏洞

“nt!ExFreePoolWithTag”函数检测到下一个头为CORRUPTED。在本例中,我们看到当前块为0x8c7913b8,下一个为0x8c791478,这就说明下一个头为“41 41 41 41 41 41 41 41”

当前块的头为有效值会发生什么?

分析当前块的头,不难发现以下规律:

9 bits (previous chunk size / 8) + 7 bits (misc) + 9 bits (current chunk size / 8) + 7 bits (allocated|free|misc) + 4 bytes (TAG)

我控制着写入的所有数据,所以我可以设置下一个块第一个字段为有效值。

比如,如果“IoAllocateErrorLogEntry”函数分配256 bytes给块(0×100的16进制值),那么“previous chunk size”的下一个块的头为0×100 / 8 = 0×20

事实上,如果我设置一个正确的值覆盖“previous chunk size”当释放当前块,那么也就不会触发漏洞了,目标也就不会崩溃了。

当我们知道如何绕过第一个BSoD,就可以通过使用各类堆技术实现远程利用的艺术。

利用想法

为了利用这个漏洞,我可以使用一个比较老套的技术“堆合并”。

此外,如果我能够准确控制远程配置,我可以覆盖一个内存对象,这样就获得多个写入的机会。

还有一个选择就是覆盖函数指针的低部分。

我可以覆盖的最大内存大小超过了分配的块,接近2300bytes

在这个漏洞,最重要的利用过程就是利用失效或者Windows内核崩溃,目标将会自动重启。

很明显,利用很棘手。但是我不确定微软给出的漏洞利用性是否正确。

后记

2015年9月8日再次更新了这个漏洞补丁

目前补丁安装程序正常运行

但是,进修复了“SrvLibLogError”函数

另一方面Windows XP和Windows 2003由于停止维护,漏洞依旧存在

*参考来源: corese ,译者/鸢尾,转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)

正文到此结束
Loading...