2015年8月11日微软发布了 14个安全补丁 ,其中就包括一个SMB服务器补丁。在本文我将解释我是如何触发该漏洞的。
在所有的修复补丁中,我对“ 服务器消息块中的漏洞可能允许远程执行代码 ”很感兴趣。
“当服务器信息块(SMB)不当处理某些日志记录活动,引发一个经过身份验证的远程代码执行漏洞,最终导致内存损坏。”
安装补丁
下载“Windows6.0-KB3073921-x86.msu”补丁之后,我试图进行安装,没想到出现了这个
对此我感到有些意外,因为当安装好一个内核补丁后,操作系统都会进行重启。但在这个例子中,补丁安装程序并没有提示我进行重启。
在“c:/windows/system32/drivers”中我发现“srv.sys”和“srvnet.sys”都被变更了。
另外,我还注意到新的“srvnet.sys”文件日期为2011年4月,新的“srv.sys”文件日期显示正常。
将新的“srv.sys”版本(v6.0.6002.19438)与2011年发布的 MS11-020 版本(v6.0.6002.18407)进行对比,惊奇的发现代码根本就没有任何改动!要说有改动也就是编译的字符串改动了。
我寻找着有关该补丁的一些信息,最终在twitter上找到Greg Linares发的一条有关“srvnet.sys”中代码变动的信息。
我联系上Greg之后确认了补丁安装程序的错误,同时感谢其指点,通过使用“expand.exe”命令手动解压了该补丁。
补丁解压完成之后,我发现“srv.sys”和“srvnet.sys”的两个版本。将旧的srvnet.sys”版本(v6.0.6002.18462) 和新版本(v6.0.6002.23746)进行差异比较,两个版本都使用相同的补丁安装程序。
在其中我发现7个函数进行了重要改变,更多的则是改动很小:
RfsTableEnumerate RfsTable64Enumerate RfsTable64LookupAndEnumerate SrvGraftName SrvLibLogError SrvNetWskEnableInterface SrvNetWskOpenListenSocket
通过微软安全公告的描述“某些日志记录活动”,所以我重点关注了下“SrvLibLogError”函数,以下为原始代码与新版本的差异比较:
可以清晰的看到修复了一个整数溢出。
关注“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部分:
另一方面要说的是,该问题在Windows 2008 R2中被静默修复。
尽管在这些操作系统中重现漏洞是被禁止的,阐明“SrvLibLogError”函数通过“srvnet.sys”输出,以及当使用SMBv1建立SMB连接依旧调用“srv.sys”是非常重要的。
一旦检测到该漏洞,最大的挑战便是写exp找到正确的输出触发该漏洞,本例中我们借助SMB协议。
以下插图为所有的影响到“SrvLibLogError”函数的方法
在第六个论点中函数接收一个字符串列表进行记录,在第七个论点中其接收数字字符串进行记录。
顺着调用图表一直调用,我发现一个来自“SrvLibLogSpnError”函数的十分有趣的调用,位于相同的库(srvnet.sys)
继续查找,发现该输出函数仅通过函数进行调用,出现在“srv.sys”和“srv2.sys”.
这也就意味着可以使用SMBv1和v2协议进行攻击。有趣的是,在MS11-020补丁中也调用了“SrvLibLogSpnError”函数
使用Windows 7通过执行类似“//192.168.60.60/shared”命令指向到Windows Server 2008,可以看到通过SMBv2当SMB服务接收到一个“Session Setup Request”包以及“NTLMSSP_AUTH”选项时,“srv2!SrvValidateSecurityBuffer”就被调用了。
以下为影响漏洞函数的第一个要求
“_SmbServerNameHardeningLevel”变量的值不同于0,这个值我们可以在注册表“HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters/SmbServerNameHardeningLevel”中查看,该值为“Server SPN target name validation level”策略相关的设定,也是“SMB hardening”的一部分。
将值设置完毕之后,新的问题又出现了
“MapSecurityError”函数返回错误代码:0xc00000bb,这也意味着,如果这个值不为0,就不能调用记录函数。
阅读 msdn文档 ,我意识到返回值得意思为“STATUS_NOT_SUPPORTED”
“MapSecurityError”函数接收“QueryContextAttributesW”函数的输出作为参数,位于“ksecdd.sys”
在 第二份文档 中,我意识到“ulAttribute”参数的值应该设置为0x1b,意思与“SECPKG_ATTR_CLIENT_SPECIFIED_TARGET”相同。
以下为这个常数的描述:
分析“ksecdd!QueryContextAttributesW”函数的代码,我确认已经不支持该常数了。
再次浏览微软公告页面,发现了一个参考链接“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
EPA安装完成之后,“SmbServerNameHardeningLevel”注册表键设置为1或者2,启用“File Sharing”选项并关闭“Password protected sharing”选项。“QueryContextAttributesW”函数返回0(“STATUS_SUCCESS”)
当“QueryContextAttributesW”函数的“pBuffer”参数返回这个值,就变得更加有趣了
使用Wireshark进行嗅探,我意识到“pBuffer”参数返回“Target Name”的属性“NTLMv2 Response”结构,包含在“Session Setup AndX Request”包中。
基于连接的SMB版本,这是第三个或者第四个SMB客户端发送的数据包
当我意识到这点,我开始构建和发送“Session Setup AndX Request”数据包,就象这样:
再然后就这样了
微软标记的该漏洞的可利用性分数
现在,我们来看看触发这个漏洞之后到底发生了什么
当尝试释放 “IoAllocateErrorLogEntry”函数分配的当前块(CURRENT CHUNK),“nt!ExFreePoolWithTag”产生了一个内核异常错误。
最重要的是注意到的是产生堆溢出的池类型(NonPagedPool),这里给出一个 完整的池类型列表
再细看下
“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
当我们知道如何绕过第一个BSoD,就可以通过使用各类堆技术实现远程利用的艺术。
为了利用这个漏洞,我可以使用一个比较老套的技术“堆合并”。
此外,如果我能够准确控制远程配置,我可以覆盖一个内存对象,这样就获得多个写入的机会。
还有一个选择就是覆盖函数指针的低部分。
我可以覆盖的最大内存大小超过了分配的块,接近2300bytes
在这个漏洞,最重要的利用过程就是利用失效或者Windows内核崩溃,目标将会自动重启。
很明显,利用很棘手。但是我不确定微软给出的漏洞利用性是否正确。
2015年9月8日再次更新了这个漏洞补丁
目前补丁安装程序正常运行
但是,进修复了“SrvLibLogError”函数
另一方面Windows XP和Windows 2003由于停止维护,漏洞依旧存在
*参考来源: corese ,译者/鸢尾,转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)