安全狗研究httpsys远程执行代码漏洞.pdf

安全狗分析 HTTP.SYS 远程执行代码漏洞 在 2015 年 4 月安全补丁日，微软发布了 11 项安全更新，共修复了包括 Microsoft Windows 、 Internet Explorer 、 Office 、 .NET Framework 、 Server 软 件 、 Office Services 和 Web Apps 中存在的 26 个安全漏洞。其中就修复了 HTTP.sys 中一处允许远 程执行代码漏洞，编号为：CVE-2015-1635 （MS15-034 ）。 据称 ，利用 HTTP.sys 的安全漏洞，攻击者只需要发送恶意的 http 请求数据包 ，就可能 远程读取 IIS 服务器的内存数据，或使服务器系统蓝屏崩溃。 根据公告显示 ，该漏洞对服务器系统造成了不小的影响 ，主要影响了包括 Windows 7、 Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2 在内的主流服务器操作系统。 安全狗安全研究团队的小伙伴们在得知这一漏洞情况后，也对其进行了深入挖掘研究 ， 下面就将相关信息结果分享给大家。 1. 首先对补丁文件做了二进制比对 以下是 Windows 7 修复前后 HTTP.SYS 的变化。 值得注意的经验是，每个函数名中都有’range’。 这不禁让我想起了之前 Apache HTT Pd ‘Range’ 头漏洞, （参见 RFC2616 章 14.35 节）。 漏洞数据由 ‘range’ 头带入已经毋庸置疑。下面要做的是深入研究其产生的原因。如 IDA 自动分析出的的 HTTP!UlpParseRange 函数的调用关系图所示： 这里我使用 Vmware 搭建了一个未打补丁的 Windows 7 SP1 作为测试目标 ，并且启用了 内核调试器, 对所有关键函数设置断点，收集关键数据和内核信息。 在断点被触发之后, 堆栈信息会被打印出来, 接着程序继续执行. 我们使用了之前的 Apach e Rangedos 测试样本针对目标服务器做了攻击性测试, 调试器捕获到了下面这些信息： 标准的 Apache RangeDos 脚本确实产生了效果，下面让我们更进一步的来看一下 HTT P!UlpParseRange 函数的实现: 在旧代码的调试中发现函数在此处调用了一个很大的整数。 而新版本的代码调用了 HTTP!RtlULongLongAdd 来检查是否有整数溢出。注意这个， HTTP. sys 内的函数调用 5 个参数而不是 3 个参数。重复之前的测试脚本, 就会发现系统返回的错 误代码是 0xC000000D(STATUS_INVALID_PARAMETER)而不再是， STATUS_INTEGER_O VERFLOW 。 修正之后的一个简单的 POC 测试脚本如下(此脚本仅用来解析证明模块内部对 Range 头参 数的解析过程)。 接着让我们在未打补丁的模块上下断点。 非常明显了。EAX 是 0x7A69 (Poc 中设置的 range 上限 31337), EDI 是 0x539 （Poc 中 设置的 range 下限 1337）。 在老代码中，如果我们的下限是 0 ，则上限不会做如此的改 变。在上限非常大的时候(整数临界值), 我们加 1, 就会发生整数溢出。 HexRays 的输出 更加明了: *(_QWORD *)v18 = __PAIR__(v22, v23) – __PAIR__(v21, v20) + 1.让我们来试试看。 这时候可以看到上限已经非常的大了(0xFFFFFFFF)。代码接着执行。 We can see that EAX is predictably small now. Now that we have some indic ation of what the pre-patch block is doing, let’s look at the patch again. 最后 EAX 在加 1 之后溢出变成了 0. 让我们再看看打过补丁的模块: 使用同样的手法, 我们得到了一个不同的错误信息. 有趣的是很多情况下都会产生这个