HTTP.sys远程代码执行(CVE2015-1635)分析复现

文章目录

漏洞描述

远程执行代码漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中，当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。
若要利用此漏洞，攻击者必须将经特殊设计的 HTTP 请求发送到受影响的系统。 通过修改 Windows HTTP 堆栈处理请求的方式，安装更新可以修复此漏洞。
利用HTTP.sys的安全漏洞，攻击者只需要发送恶意的http请求数据包，就可能远程读取IIS服务器的内存数据，或使服务器系统蓝屏崩溃。

漏洞影响的操作系统

安装了微软IIS 6.0以上的：

• Windows 7
• Windows Server 2008 R2
• Windows 8
• Windows Server 2012
• Windows 8.1
• Windows Server 2012 R2

漏洞原理

HTTP报头RANGE字段

在原来网络不是很好的时候，下载大型文件很不容易，如果下载中断 ，那么只能重头开始下载，为了解决这个问题 HTTP/1.1引入的范围请求。即请求这个文件x~y的字节，指定范围，在请求报文的首部添加

Range字段

，此字段指定资源的

byte范围

，告诉服务器，请求资源是哪个范围的内容，让断点续传和并行下载得以实现。

416响应码

服务器发送416响应码的情况发生于断点续传时Range字段所传递的数据范围不符合要求。错误状态码意味着服务器无法处理所请求的数据区间。最常见的情况是所请求的数据区间不在文件范围之内。
一则 416 应答消息包含有一个 Content-Range 首部，提示无法满足的数据区间（用星号 * 表示），后面紧跟着一个“/”，再后面是当前资源的长度。例如：

bytes */1150 

触发机制

漏洞的触发流程和原理：

1. upper(range结束的offset) = 0xFFFFFFFFFFFFFFFF时，UlpParseRange或UlAdjustRangesToContentSize会触发整数溢出,导致绕过UlAdjustRangesToContentSize的Length检查。
2. Length 可控，但是Length = 0xFFFFFFFFFFFFFFFF – lower（range开始的offset)+1 ， lower必须要小于要获取目标文件的数据长度contentlength。

HTTP请求的处理实际是先通过w3wp发起的进程上下文内http先解析HTTP请求包，组合成紧凑的http回应包后，通过UlSendData->UxTpTransmitPacket->UxpTpEnqueueTransmitPacket排入队列，然后再由工作线程UlSendCacheEntryWorker将其发送出去。
在这个过程中，如果range指定的数据开始offset小于紧凑的数据包头部的总长度，那么这里在计算最后的发包读取数据时，还会触发一个整数溢出，即0xffffffff(-1，已经被变为32位数）- lower + 1 + header size，如果lower < header size，那么将会导致最后32位整数溢出计算出一个较小的数值，这样导致不会BSOD（如果精确控制响应包大小和文件大小，即使这样还是有可能触发BSOD）
因此这里我们让lower 大于回应包大小，就比较容易可以控制BSOD了
这个漏洞难道只能BSOD吗？说好的远程代码执行呢？再深入看下漏洞触发的细节，看上去似乎不能远程代码执行，但是远程读取服务器内核内存数据是有可能的。
在UlpSendCacheEntry->UlBuildFastRangeCacheMdlChain中，http.sys会为HTTP回应头和缓存来源buffer/length（我们可控）创建MDL，那么，对于我们的超长length，就会创造一个巨大的mdl，接着放入UxTpTransmitPacket的数据包对象中，通过tcpip->netio，最后解析MDL，将数据最终发出去。
此时是可以超过缓存的空间，读取缓存内存往后的数据，如果缓存内存后面是连续的0xffffffffffffffff – lower(4GB?)左右内核内存（通常是X64)，就有可能实现信息泄露。
不过首先是很难有连续的4G内存，同时通过IIS也很难一下获得如此多的数据，那么只能设法降低这个内存要求：length = 0xFFFFFFFFFFFFFFFF – lower ，且lower < contetnlength才行，我们可以想办法提高content length，达到降低Length的目的，例如在服务器上寻找一个接近4GB大小的文件。
还有一个产生较小的Length实现信息泄露的方法，在上一节BSOD里有讲到，就是扩大回应包的数据长度+减小文件大小，利用32位的整数溢出，构造一个比文件大小要大的复制长度，泄露cache buffer后面的内核数据。这需要进一步研究和控制了。

漏洞复现

使用msf模块MS15-034进行复现
打开msfconsole应用：

msfconsole

查看MS15-034相关模块信息

search ms15-034

auxiliary/dos/http/ms15_034_ulonglongadd

auxiliary/scanner/http/ms15_034_http_sys_memory_dump

这里有两个模块，第一个模块是对靶机进行DOS攻击，第二个模块是查看靶机的内存信息

msf6 > use auxiliary/scanner/http/ms15_034_http_sys_memory_dump 
msf6 auxiliary(scanner/http/ms15_034_http_sys_memory_dump)> show options

设置目标靶机的ip，端口，run
由于此次是在真实环境下进行，所以这里会使用马赛克

msf6 auxiliary(scanner/http/ms15_034_http_sys_memory_dump)>set rhost ip手动马赛克
rhost => ip手动马赛克
msf6 auxiliary(scanner/http/ms15_034_http_sys_memory_dump)>set rport 81
rport =>81
msf6 auxiliary(scanner/http/ms15_034_http_sys_memory_dump)> run

由于蓝屏EXP非常危险，所以在真实环境这里就不进行演示了。
参考学习地址：https://www.secpulse.com/archives/6058.html