使用 WPAD/PAC 和 JScript在win11中进行远程代码执行

介绍

事后看来，许多广泛部署的技术似乎是一个奇怪或不必要的冒险想法。IT 中的工程决策通常是在不完整的信息和时间压力下做出的，IT 堆栈的一些奇怪之处最好用“当时似乎是个好主意”来解释。在这篇文章的一些作者的个人观点中，WPAD（“Web Proxy Auto Discovery Protocol”——更具体地说是“Proxy Auto-Config”）就是其中之一。

在 Internet 早期的某个时刻——1996 年之前——Netscape 的工程师认为 JavaScript 是一种编写配置文件的好语言。结果是PAC——一种配置文件格式，其工作方式如下：浏览器连接到预配置的服务器，下载 PAC 文件，并执行特定的 Javascript 函数以确定正确的代理配置。为什么不？它肯定比（比方说）XML 更具表现力和更少冗长，并且似乎是向许多客户端提供配置的合理方式。

PAC 本身与一个称为 WPAD 的协议相结合——该协议使浏览器无需连接到预先配置的服务器。相反，WPAD 允许计算机查询本地网络以确定从中加载 PAC 文件的服务器。

不知何故，这项技术最终成为了 1999 年到期的IETF 草案，而现在，在 2017 年，每台 Windows 机器都会询问本地网络：“嘿，我在哪里可以找到要执行的 Javascript 文件？”。这可以通过多种机制发生：DNS、WINS，但——也许最有趣的是——DHCP。

近年来，浏览器漏洞利用已经从主要面向 DOM 转变为直接针对 Javascript 引擎，因此仅提及我们可以在没有浏览器的情况下通过网络执行 Javascript 就很有吸引力。初步调查显示，负责执行这些配置文件的 JS 引擎是 jscript.dll - 也支持 IE7 和 IE8 的旧版 JS 引擎（如果使用适当的脚本属性，在 IE7/8 兼容模式下仍然可以在 IE11 中访问）。这有好有坏 - 一方面，这意味着并非每个 Chakra 错误都会自动成为本地网络远程攻击，但另一方面，这意味着一些相当旧的代码将负责执行我们的 Javascript。

安全研究人员此前曾警告过WPAD的危险。但是，据我们所知，这是第一次证明针对 WPAD 的攻击会导致 WPAD 用户机器的完全入侵。

Windows 肯定不是唯一实现 WPAD 的软件。其他操作系统和应用程序也是如此。例如，Google Chrome 也有一个 WPAD 实现，但在 Chrome 的情况下，评估 PAC 文件中的 JavaScript 代码发生在沙箱内。而其他支持 WPAD 的操作系统默认不启用它。这就是为什么 Windows 目前是此类攻击最有趣的目标。

Web 代理自动发现

如上所述，WPAD 将查询 DHCP 和 DNS（按此顺序）以获取要连接的 URL - 如果没有来自 DNS 的响应，显然也可以使用 LLMNR 和 Netbios。WPAD-over-DNS 的一些特性会导致令人惊讶的攻击向量。

攻击场景：通过 DHCP 的本地网络

在最常见的情况下，机器将使用选项代码 252 查询本地 DHCP 服务器。DHCP 服务器回复一个字符串 - 例如“ http://server.domain/proxyconfig.pac ”，它指定了配置的 URL应该获取文件。然后客户端继续获取该文件，并将内容作为 Javascript 执行。

在本地网络中，攻击者可以简单地冒充 DHCP 服务器 - 通过 ARP 游戏或通过竞争合法的 DHCP。然后，攻击者可以提供托管恶意 Javascript 文件的 URL。

攻击场景：通过特权位置和 DNS 远程通过 Internet

除了本地网络攻击场景之外，WPAD 的查找也可能通过 DNS 发生，这会产生二次攻击场景。许多用户将他们的计算机配置为针对公共的、全球可见的 DNS 服务器之一（例如 8.8.8.8、8.8.4.4、208.67.222.222 和 208.67.220.220）执行 DNS 查找。在这种情况下，机器会将 DNS 查询（例如 wpad.local）发送到位于本地网络之外的服务器。处于网络特权地位的攻击者（例如网关或任何其他上游主机）可以监视 DNS 查询并欺骗回复，从而指导客户端下载并执行恶意 Javascript 文件。

像这样的设置似乎很常见 - 根据这个 Wikipedia 条目，DNS 根服务器看到的流量中有很大一部分是 .local 请求。

攻击场景：通过恶意 wpad.tld 在互联网上远程

WPAD 的一个特别奇怪之处在于它递归地遍历本地机器名称以查找要查询的域。如果一台机器名为“laptop01.us.division.company.com”，则按顺序查询以下域：

• wpad.us.division.company.com
• wpad.division.company.com
• wpad.company.com
• wpad.com

这（根据此Wikipedia 条目）过去曾导致人们注册 wpad.co.uk 并将流量重定向到在线拍卖网站。进一步引用该条目：

通过 WPAD 文件，攻击者可以将用户的浏览器指向他们自己的代理，并拦截和修改所有 WWW 流量。尽管在 2005 年应用了针对 Windows WPAD 处理的简单修复，但它仅修复了 .com 域的问题。Kiwicon的一次演讲表明，世界其他地区仍然非常容易受到这个安全漏洞的攻击，在新西兰注册的一个示例域用于测试目的，以每秒几个的速度接收来自全国各地的代理请求。一些 wpad.tld 域名（包括 COM、NET、ORG 和 US）现在指向客户端环回地址，以帮助防范此漏洞，但仍有一些名称已注册 (wpad.co.uk)。

因此，管理员应确保用户可以信任组织中的所有 DHCP 服务器，并且该组织的所有可能的 wpad 域都在控制之下。此外，如果没有为组织配置 wpad 域，则用户将转到域层次结构中具有下一个 wpad 站点的任何外部位置，并将其用于其配置。这允许在特定国家/地区注册 wpad 子域的任何人通过将自己设置为所有流量或感兴趣的站点的代理，对该国家/地区的大部分 Internet 流量执行中间人攻击。

另一方面，IETF 草案明确要求客户只允许“规范”（例如非顶级域）。我们还没有调查客户在多大程度上实现了这一点，或者二级域（例如 .co.uk）是否是历史流量重定向案例的罪魁祸首。

无论哪种方式：如果一个人设法为给定组织的 TLD 注册 wpad.$TLD，则考虑中的 Javascript 引擎中的错误可以通过互联网远程利用，前提是该 TLD 没有被客户端实施明确列入黑名单。鉴于 1999 年的 IETF 草案引用了 1994 年的 TLD 列表 ( RFC1591 )，客户端不太可能已更新以反映新 TLD 的扩散。

我们为各种 TLD 注册 wpad.co.$TLD 的尝试（尚未）成功。

错误

我们花了一些时间寻找 jscript.dll 中的错误，并采用了手动分析和模糊测试。JScript 最初提出了一些挑战，因为许多用于触发 JavaScript 引擎中的错误的“功能”不能在 JScript 中使用，仅仅是因为它太旧而无法支持它们。例如：

• 没有多个数组类型（int 数组、float 数组等）。因此，不可能将一种数组类型与另一种混淆。
• 没有更新、更快的 JavaScript 引擎那么多的优化（“快速路径”）。这些快速路径通常是错误的来源。
• 无法在通用 JavaScript 对象上定义 getter/setter。可以调用 defineProperty 但仅限于对我们不起作用的 DOM 对象，因为 WPAD 进程中不会有 DOM。即使有，许多 JScript 函数在 DOM 对象上调用时也会简单地失败，并显示消息“JScript object expected”。
• 对象的原型一旦创建就不可能更改（即没有“__proto__”属性）。

但是，JScript 确实存在更多“老派”漏洞类别，例如 use-after-free。这篇旧的 MSDN 文章中描述了 JScript 的垃圾收集器. JScript 使用非分代标记和清除垃圾收集器。本质上，每当触发垃圾回收时，它都会标记所有 JScript 对象。然后它从一组“根”对象（有时也称为“清道夫”）开始扫描它们，并清除它遇到的所有对象的标记。所有仍被标记的对象都将被删除。一个反复出现的问题是堆栈上的局部变量默认不会添加到根对象列表中，这意味着程序员需要记住将它们添加到垃圾收集器的根列表中，特别是如果这些变量引用的对象可以是在函数的生命周期内被删除。

其他可能的漏洞类型包括缓冲区溢出、未初始化的变量等。

对于模糊测试，我们使用了基于语法的Domato模糊测试引擎，并专门为 JScript 编写了一个新语法。通过查看各种 JScript 对象的 EnsureBuiltin 方法，我们确定了要添加到语法中的有趣的内置属性和函数。JScript 语法已添加到 Domato 存储库中。

在模糊测试和手动分析之间，我们发现了七个安全漏洞。它们总结在下表中：

在发布这篇博文时，所有的错误都已被微软修复。

该表按触发漏洞所需的类和兼容模式对漏洞进行了细分。WPAD 中的 JScript 相当于在 IE7 兼容模式下运行脚本，这意味着，虽然我们发现了 7 个漏洞，但在 WPAD 中“仅”可以触发其中的 5 个。但是，当恶意网页进入 IE8 兼容模式时，其他漏洞仍然可以用于攻击 Internet Explorer（包括 IE11）。