前言

  上周参加巅峰极客决赛的时候，靶场中很多中小型的网站都是用的IIS6的WEB容器，并且开着WEBDAV，但是直接用msf的iis_webdav_scstoragepathfromurl却无法利用成功，因此总结一下，以免下次再遇到这样尴尬的场面。

失败原因

  其实早在2017.03.31大佬zcgonvh已经给出了4种失败的原因了，当时没太在意，这次复现的过程中深刻的体会到了这些失败原因，并将大佬的4种失败原因分解成5种失败原因。

端口和域名绑定问题

  实际环境中，iis绑定的域名和端口可能不是默认的，比如：

•  默认绑定

•   非默认绑定

  If头信息中的两个url是要求和站点绑定相匹配的，否则只能收到一个502。这里所说的相匹配指的是if头中url的port必须与站点绑定的端口相匹配，而if头中的域名只需要和host头保持一致就好。

• 失败情况 ：POC中if头里面的域名及端口与绑定不一致时。

  上图是端口不匹配的情况，下图是域名不匹配的情况

•    成功情况 ：POC中if头里面的域名及端口与绑定一致时。（端口与实际端口一致，host的值与if中的域名一致）

物理路径

  根据CVE-2017-7269 IIS6.0远程代码执行漏洞分析及Exploit中提到：POC中If头中的第一个URL会被解析成物理路径，默认情况下是C:\Inetpub\wwwroot\，在覆盖缓冲区的时候填充的字符长度要根据物理路径的长度来决定，且物理路径长度 + 填充字符的个数 = 114。POC中的是按照默认的物理路径（19位）来计算填充字符的长度的，当物理路径的长度不为19位的时候就会收到一个500。（这里物理路径长度计算方法要加上最后的\）

物理路径长度<19位

•          失败情况 ：物理路径长度小于19位。

•   成功情况 ：物理路径长度小于19位，且增加POC中padding的长度。

  物理路径为c:\asp\其长度为7，因此POC需要增加12个a。

物理路径长度>19位

  直接引用zcgonvh大佬的原话：“ROP和stackpivot前面的padding实际上为UTF8编码的字符，每三个字节解码后变为两个字节的UTF16字符，在保证Exp不出错的情况下，有0x58个字符是没用的。所以可以将前0x108个字节删除，换成0x58个a或b。”

  所以大概的POC是这样的：

  物理路径为C:\Inetpub\wwwroot\test\长度为24位，因此需要padding 90位，其中红框中a或b的个数为90。

爆破物理路径长度

  这个漏洞利用的成功与否，也取决于是否知道物理路径的长度。物理路径的长度可以根据上面已知的信息，来进行爆破：

•   物理路径长度 + 填充字符的个数 = 114

•    长度不匹配时返回500。

  因为盘符占了3位字符（c:\），所以要爆破物理路径长度，可以将padding增加到111位，并依次减少，如果长度不匹配就返回500。判断长度的工具附在最后面。

多次执行错误shellcode

  多次执行错误的shellcode会覆盖很多不该覆盖的代码，从而导致正确的shellcode也执行也返回500，提示信息为：参数不正确，也可能什么都不返回。该问题在巅峰极客比赛中也遇到过，我们控制的靶机什么都没动一会儿就全站500了。

EXP执行成功后

  当exp执行成功一段时间之后(大概十分钟到二十分钟左右，其间无论有无访问，被windbg挂起的时间不算)，再对这个站点执行exp永远不会成功，同时返回400。

  遇到该问题的解决方案：

•          1.找旁站，因为每个池都是独立的w3wp进程，换一个可能在其他池的进行尝试

•          2.等待w3wp重启

Win03 x64

  Win03 x64并不多见，此类型的不能直接用网上的POC进行攻击。

总结

MSF-Exploit

CVE-2017-7269

  该exploit是我们比赛时albertchang找到的一个可以成功利用的exploit（后面我会提及那个不能用的exploit）。

  该exploit用法很简单，只需要填写域名和端口即可。

  但是其对非默认端口或非默认路径的站点却束手无策。

  看下此exploit的代码：

  可以看出这个exploit只是对POC进行了修改，将POC中的shellcode替换成了MSF的shellcode，因此在非默认绑定或者非默认物理路径的情况下利用不成功。

iis_webdav_scstoragepathfromurl完善前

  iis_webdav_scstoragepathfromurl是由zcgonvh大佬编写且国外的大佬完善过的，而我们这一小节写的是未进行完善的exploit。

  对于默认物理路径长度以及默认绑定情况：

  可以看到该exploit相比于第一个，增加了物理路径的长度和HttpHost两个字段，其中最主要的是物理路径的长度。

  对于默认物理路径长度以及默认绑定情况也可以利用成功，只需要修改物理路径的长度和端口即可，如下图。

  从代码看：

  可以看出来zcgonvh大佬在编写Exploit的时候，把关于绑定和物理路径长度的问题都解决了，唯一不智能的一点就是需要自己输入物理路径的长度。

iis_webdav_scstoragepathfromurl

  这个exploit是MSF自带的一个EXP，该EXP由zcgonvh大佬编写且国外的大佬完善过的，但是在比赛中以及这次写文章复现过程中都没有成功过一次。翻看了一下代码：

  该exploit相对于zcgonvh编写的Exploit来说，添加了自动爆破物理路径长度的功能，其爆破开始的最小值和最大值是可以设置的。

总结

物理路径长度爆破工具

批量检测工具

•          爆破物理路径长度并检测漏洞

•          指定物理路径长度检测漏洞

  下载地址：IIS6_WebDAV_Scanner

参考

CVE-2017-7269的几个技巧及BUG修正

CVE-2017-7269回显POC

CVE-2017-7269 IIS6.0远程代码执行漏洞分析及Exploit

CVE-2017-7269 IIS6.0远程代码执行漏洞分析及Exploit

文章来自Backer Talk原创作者 - AdminTony，如需转载需注明作者及本文链接

【Backer Talk】BSRC白客说栏目专注于安全知识分享，长期向安全爱好者征集漏洞分析、漏洞挖掘姿势分享等安全相关内容，欢迎惠赐作品！详情点击