漏洞预警:利用WPAD/PAC与JScript实现Windows 10代码执行

阅读量215934

|评论4

发布时间 : 2017-12-19 13:11:31

x
译文声明

本文是翻译文章,文章原作者 Ivan Fratric, Thomas Dullien, James Forshaw and Steven Vittitoe,文章来源:googleprojectzero.blogspot.com

原文地址:https://googleprojectzero.blogspot.com/2017/12/apacolypse-now-exploiting-windows-10-in_18.html

译文仅供参考,具体内容表达以及含义原文为准。

 

引言

有很多应用广泛的技术却往往看起来是一个奇怪的主意。IT届的不少工程决策是在信息不完善与时间压力下进行的,因此系统中的很多古怪问题就显得“当时看来是个好主意”。本篇文章中探讨的WPAD(“Web代理自动发现协议”,更具体地说是“代理自动配置”)正是其中之一。
互联网之初——在1996年的时候,Netscape的工程师认为JavaScript是编写配置文件的最好的语言,因此PAC成为配置文件的格式,其工作原理如下:浏览器连接到预先设定的服务器,下载PAC文件,并执行特定的JavaScript以确定正确的代理配置。不过它也有其优势,比方说它就比XML更具表现型且不那么冗杂,而且可以向许多客户端提供配置信息。
PAC本身加上了一个名为WPAD的协议,它使得浏览器不需要预先设定服务器来连接。WPAD可让计算机查询本地网络以确定加载PAC文件的服务器。
不知何故,这项技术最终写进1999年的IETF草案。直到现在,每台Windows计算机都会询问本地网络:“嘿,我在哪里可以找到一个Javascript文件来执行?”。这可以通过多种机制来实现:DNS,WINS,也可以是DHCP。
近年来,浏览器的利用已经从主要面向DOM发展到直接面向JavaScript引擎,所以假如我们可以在不借助浏览器的情况下通过网络来执行Javascript那就是个很好的方向。最初的调查显示,负责执行这些配置文件的JS引擎是jscript.dll——同时也支持IE7和IE8的传统JS引擎(如果使用适当的脚本属性,在IE11中仍然可以在IE7 / 8兼容模式下访问)。这是把双刃剑——一方面,这意味着不是每一个Chakra的错误都会导致远程攻击,但另一方面,这意味着一些相当老的代码将负责执行我们的Javascript。
安全研究人员先前已警告WPAD的危险性。但是,就我们所知,这是第一次发现对WPAD的攻击。
Windows并不是唯一使用WPAD的,其他操作系统和应用程序也在用。例如Google Chrome也有一个WPAD实现,但在Chrome的情况下,是在一个沙箱内执行PAC文件的JavaScript。而其他支持WPAD的操作系统默认是不启用它的。这就是为什么Windows是目前这种攻击最倾向的目标。

 

WPAD(Web Proxy Auto-Discovery)

详情见原文

 

漏洞情况

我们花了一些时间手动分析与模糊测试jscript.dll中的漏洞。最开始遇到了一些困难,因为很多用于触发JavaScript引擎中的错误的“特性”不能在JScript中使用,仅仅是因为它太老了没法支持这些特性。例如:
  • 缺乏数组类型(int数组,float数组等),因此混淆数组类型是不可能的。
  • 没有现代JavaScript引擎优化(“快速路径”),这些快速路径往往会导致漏洞。
  • 不能在通用JavaScript对象上定义getter/setter。可以调用defineProperty但DOM对象于我们没有帮助,因为在WPAD过程中不会出现DOM。即使它存在,当调用一个带有“预期的JScript对象”消息的DOM对象时,很多JScript函数也会报错。
  • 对象创建后改变对象原型是不可能的(即没有“__proto__”属性)。
不过JScript确实会受到一些老漏洞的影响,比如释放后利用。JScript的垃圾回收器在这篇MSDN文章中有介绍。从本质上讲,无论何时垃圾收集被触发,它都会标记所有的JScript对象。然后从一组“根”对象(有时也称为“清道夫”)开始扫描它们,并清除掉扫描到的对象上的标记。在最后仍被标记的对象都会被删除。一个经常出现的问题是默认情况下,堆栈上的局部变量不会被添加到根对象列表中,这意味着程序员需要时刻牢记将它们添加到垃圾回收器的根列表中。
其它可能出现的漏洞类型包括缓冲区溢出,未初始化变量等。
模糊测试上我们使用了基于语法的Domato模糊测试引擎,并专门为JScript写了一个新的语法。我们通过查看各种JScript对象的EnsureBuiltin方法来识别可为我们所用的内置属性和方法,并添加到语法中。JScript语法现在已经添加到github的Domato项目仓库中。
在模糊测试与手动分析后,我们确定了七个安全漏洞。如下表所示:
漏洞类型
影响IE8模式的漏洞
影响IE7模​​式的漏洞
释放后利用
134013761381
堆溢出
未初始化变量
溢出
总计
7
5
在发布这篇博客的时候,所有的错误已经被微软修复了。
WPAD中的JScript相当于在IE7兼容模式下运行脚本,这意味着尽管我们发现了7个漏洞,但WPAD中只能触发5个。但是,其他漏洞在IE8兼容模式下被恶意网页使用时,仍然可以利用Internet Explorer(包括IE11)。

 

利用

详情见原文

 

结论与防护

执行不可信的JavaScript是非常危险的,在非沙盒JavaScript引擎中(如jscript.dll)更是如此。我们找出了7个安全漏洞,并在安装了Fall Creator Update的Windows 10 64位计算机上成功进行利用,可触发本地网络(或其他地方)任意代码执行。
现在漏洞已经修复了,这是否意味着我们可以收工回家睡觉?可惜并不是。尽管我们花费了相当多的时间和精力来找寻jscript.dll漏洞,但是我们并不认为我们发现了所有的漏洞。事实上,可能不只有7个,也可能会有8个甚至更多。
那么,微软可以做些什么来提高这类漏洞的利用难度呢:
  • 默认禁用WPAD。实际上,目前Windows是唯一一个默认启用WPAD的。
  • 为WPAD服务内的JScript增加沙盒环境。
如果您想自行采取安全措施,那么唯一能够阻止这类漏洞的方法就是完全禁用WinHttpAutoProxySvc服务。有时候,由于其他服务依赖于WPAD,所以在“服务”设置中无法禁用它(选项将变灰),但可以通过修改相应的注册表项来完成。在注册表“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc”位置下,将“Start”的值从3(手动)更改为4(禁用)。
以下是在搜索“禁用WPAD”时在网上找到的一些方法,但这些方法在我们的实验中都无法阻止攻击:
  • 在控制面板中关闭“自动检测设置”
  • 设置“WpadOverride”注册表项
  • 将“255.255.255.255 wpad”放在hosts文件中
本文翻译自googleprojectzero.blogspot.com 原文链接。如若转载请注明出处。
分享到:微信
+10赞
收藏
安全客
分享到:微信

发表评论

Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全KER All Rights Reserved 京ICP备08010314号-66