<% dim ModuleName,InfoID,ChannelShortName,CorrelativeArticle,InstallDir,ChannelDir,Keyword,PageTitle,ArticleIntro,Articlecontent Keyword=stripHTML("MS15-083,Windows SMB,内存损坏,漏洞分析") PageTitle=stripHTML("MS15-083:Windows SMB内存损坏漏洞分析") ArticleIntro=stripHTML("2015年8月11日微软发布了14个安全补丁,其中就包括一个SMB服务器补丁。在本文我将解释我是如何触发该漏洞的") Articlecontent=stripHTML("微软安全公告MS15-083  在所有的修复补丁中,我对“服务器消息块中的漏洞可能允许远程执行代码”很感兴趣。  “当服务器信息块(SMB)不当处理某些日志记录…") ModuleName = stripHTML("exploits") InfoID = stripHTML("212212") ChannelShortName=stripHTML("漏洞") InstallDir=stripHTML("http://www.77169.com/") ChannelDir=stripHTML("exploits") %> MS15-083:Windows SMB内存损坏漏洞分析 - 华盟网 - http://www.77169.com
您现在的位置: 华盟网 >> 漏洞 >> 最新漏洞 >> 其它漏洞 >> 正文

[组图]MS15-083:Windows SMB内存损坏漏洞分析

2015/9/23 作者:鸢尾 来源: 网络收集
导读 <% if len(ArticleIntro)<3 then Response.Write Articlecontent 'Response.Write "Articlecontent" else Response.Write ArticleIntro 'Response.Write "ArticleIntro" end if %>

  微软安全公告MS15-083

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

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

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

  安装补丁

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

  

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

  在“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”函数,以下为原始代码与新版本的差异比较:

  

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

  关注“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.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”的一部分。

  触发阶段–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由于停止维护,漏洞依旧存在

漏洞栏目相关内容

    没有相关漏洞