返回目录：电脑蓝屏
2015年8月11日微软发布了14个安全补丁，其中就包括一个SMB服务器补丁。在本文我将解释我是如何触发该漏洞的。
微软安全公告MS15-083
在所有的修复补丁中，我对“服务器消息块中的漏洞可能允许远程执行代码”很感兴趣。
“当服务器信息块(SMB)不当处理某些日志记录活动，引发一个经过身份验证的远程代码执行漏洞，最终导致内存损坏。”
受影响的版本包括32位和64位的Windows Vista 和 Windows Server 2008，值得注意的是，这是自2011年以来微软发布的第一个SMB服务修复补丁。
安装补丁
下载“Windows6.0-KB3073921-x86.msu”补丁之后，我试图进行安装，没想到出现了这个
对此我感到有些意外，因为当安装好一个内核补丁后，操作系统都会进行重启。但在这个例子中，补丁安装程序并没有提示我进行重启。
在“c:windowssystem32drivers”中我发现“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”函数，以下为原始代码与新版本的差异比较：
可以清晰的看到修复了一个整数溢出。
关注“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”是非常重要的。
这也意味着，任何Windows驱动(官方或者第三方)调用这个输出函数，这个漏洞将会重现。
利用该漏洞可能的方法
一旦检测到该漏洞，最大的挑战便是写exp找到正确的输出触发该漏洞，本例中我们借助SMB协议。
以下插图为所有的影响到“SrvLibLogError”函数的方法
在第六个论点中函数接收一个字符串列表进行记录，在第七个论点中其接收数字字符串进行记录。
顺着调用图表一直调用，我发现一个来自“SrvLibLogSpnError”函数的十分有趣的调用，位于相同的库(srvnet.sys)
继续查找，发现该输出函数仅通过函数进行调用，出现在“srv.sys”和“srv2.sys”.
这也就意味着可以使用SMBv1和v2协议进行攻击。有趣的是，在MS11-020补丁中也调用了“SrvLibLogSpnError”函数
触发阶段–Part 1
使用Windows 7通过执行类似“192.168.60.60shared”命令指向到Windows Server 2008，可以看到通过SMBv2当SMB服务接收到一个“Session Setup Request”包以及“NTLMSSP_AUTH”选项时，“srv2!SrvValidateSecurityBuffer”就被调用了。
以下为影响漏洞函数的第一个要求
“_SmbServerNameHardeningLevel”变量的值不同于0，这个值我们可以在注册表“HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParametersSmbServerNameHardeningLevel”中查看，该值为“Server SPN target name validation level”策略相关的设定，也是“SMB hardening”的一部分。
触发阶段–Part 2
将值设置完毕之后，新的问题又出现了
“MapSecurityError”函数返回错误代码：0xc00000bb，这也意味着，如果这个值不为0，就不能调用记录函数。
阅读msdn文档，我意识到返回值得意思为“STATUS_NOT_SUPPORTED”
“MapSecurityError”函数接收“QueryContextAttributesW”函数的输出作为参数，位于“ksecdd.sys”
在第二份文档中，我意识到“ulAttribute”参数的值应该设置为0x1b，意思与“SECPKG_ATTR_CLIENT_SPECIFIED_TARGET”相同。
以下为这个常数的描述：
分析“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”参数返回这个值，就变得更加有趣了
使用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
事实上，如果我设置一个正确的值覆盖“previous chunk size”当释放当前块，那么也就不会触发漏洞了，目标也就不会崩溃了。
当我们知道如何绕过第一个BSoD，就可以通过使用各类堆技术实现远程利用的艺术。
利用想法
为了利用这个漏洞，我可以使用一个比较老套的技术“堆合并”。
此外，如果我能够准确控制远程配置，我可以覆盖一个内存对象，这样就获得多个写入的机会。
还有一个选择就是覆盖函数指针的低部分。
我可以覆盖的最大内存大小超过了分配的块，接近2300bytes
在这个漏洞，最重要的利用过程就是利用失效或者Windows内核崩溃，目标将会自动重启。
很明显，利用很棘手。但是我不确定微软给出的漏洞利用性是否正确。
后记
2015年9月8日再次更新了这个漏洞补丁
目前补丁安装程序正常运行
但是，进修复了“SrvLibLogError”函数
另一方面Windows XP和Windows 2003由于停止维护，漏洞依旧存在