JavaScript) Drive-By,无需 0Days即可进行黑客攻击
Google Chrome 中的远程代码执行链允许攻击者在主机上执行代码,其成本可能高达 25 万美元到 50 万美元。如今,这种能力通常只为政府和间谍机构所拥有。但不久前,普通脚本小子也能使用类似的能力。
Java 驱动
2008 年,当我刚刚开始接触编码和安全时,我了解到一种称为“驱动下载”的技术,特别是“Java 驱动”。当时,您可以将 Java 小程序(用 Java 编程语言编写的小应用程序)嵌入到网页中。虽然这些小程序旨在增强 Web 功能,但它们也允许攻击者在用户的机器上运行任意代码。
与未签名的小程序相比,签名的小程序在安全沙箱和权限级别方面存在很大差异。本质上,签名的小程序可以以与桌面应用程序相同的访问级别运行,即使它们在浏览器中运行。
但是,由于签名缺乏受信任的证书颁发机构的认可,因此无法验证签名。这会导致弹出安全警告,使用户至少有 50% 的机会做出错误的选择。单击“运行”按钮可能会立即危及您的系统。
这不是一个漏洞,只是一个坏主意。
JavaScript Drive-By
2022 年,我开始研究文件系统访问 API。此 API 允许网站读取和写入用户选择的文件,但 Chrome 认为是系统文件的文件有一些值得注意的例外。我甚至报告了一个与它处理符号链接的方式有关的漏洞,谷歌已经修复了它。
但即使在漏洞修复后,有些事情仍然困扰着我。这个 API 太强大了。要了解原因,我们必须首先了解操作系统的安全边界。这个 API 绕过了 Windows 和 macOS 的安全机制,但出于本文的目的,我将重点介绍 macOS。
值得注意的是,此问题不仅影响 Google Chrome,还影响所有基于 Chromium 的浏览器,例如 Microsoft Edge、Brave 和 Opera,因为它们都共享相同的底层架构和 API。
Gatekeeper
macOS 上的 Gatekeeper 是一项安全功能,可防止用户运行不受信任的软件。它涉及三个主要步骤:
文件隔离:于 2007 年推出,在执行从互联网下载的文件之前会警告用户。
Gatekeeper:基于 OSX Lion (10.7) 中的文件隔离构建,它会检查下载的应用程序是否来自已识别的开发人员,并阻止那些不是的开发人员。
公证:在 macOS Catalina (10.15) 中引入,它要求应用程序在运行前经过 Apple 扫描和批准。
此外,macOS 包含一个应用程序沙盒,以限制应用程序对系统资源和用户数据的访问。Chrome 浏览器不使用此沙盒功能,这也是文件系统访问 API 如此危险的另一个原因。
当用户使用文件系统访问 API 与网站交互时,系统会提示他们批准写入权限。此时,用户成为唯一的防线。如果他们错误地授予对错误文件的访问权限,则所有先前的安全边界都将被绕过。虽然文件系统访问 API 正确地添加了 com.apple.quarantine 属性,表明该文件是从互联网上下载的,不应信任,但 macOS Gatekeeper 的一个限制是,当由另一个应用程序执行时,它不会重新检查此二进制文件,在我们的例子中,该应用程序是 Google Chrome 本身。
这让人回想起旧的 Java 驱动下载,一次误点击可能会导致系统受到损害。
绕过 Chrome 阻止列表
Chrome 确实根据阻止列表限制对文件和目录的写入访问权限。但是,我发现如果用户拖放文件,Chrome 似乎不会根据阻止列表对其进行检查。
话虽如此,我认为修复此绕过不会解决文件系统访问 API 的根本问题。有太多文件可以覆盖以获取代码执行,你总会错过一个。
与 Java 小程序类似,没有可以指出的漏洞,因此,本文的其余部分将重点介绍如何滥用文件系统访问 API 来攻击他人。
利用和符号链接
成功的利用取决于我们说服用户授予我们对特定目标文件的写访问权限的能力。许多文件都可以用来实现代码执行,但我最喜欢的是 Google Chrome Helper。
Google Chrome Helper 充当 Chrome 与任何已安装插件之间的中介,通过启动外部内容(如视频播放器、扩展程序或嵌入内容)的进程来促进其运行。执行某些操作(如 window.print() 命令)时,可能会创建一个 Google Chrome Helper 进程来管理这些操作所需的必要外部交互和资源。这就是为什么覆盖它可以让我们立即执行代码。
下一步是编造一个令人信服的故事或理由,让用户在授予此访问权限时感到安全。我发现最好的方法是使用符号链接 - 本质上是重定向到另一个文件或目录的指针。符号链接非常适合此目的,因为大多数人不了解它们是什么,即使是那些了解的人也经常忽略它们。它们非常适合此目的,因为它们从用户的角度创造了一种安全的假象。很容易假设没有风险:“我只是授予网站对我从中下载的文件的写访问权限 - 可能出什么问题?”
概念验证
随着 Web 平台提供更多高级应用程序(如 IDE、3D 编辑器等),授予文件读写权限变得越来越容易被接受。
为了展示影响,我开发了两个概念验证,鉴于人工智能的炒作,我选择了第一个,它是一个自称是浏览器人工智能助手的网站,与我们的目标文件“Google Chrome Helper”配合得很好。
第二个 PoC 是一个虚假的基于 Web 的 IDE,称为“邪恶代码编辑器”。在此演示中,系统会提示用户下载示例项目并打开它以熟悉编辑器。
您可以在以下位置找到这两个代码:
https://github.com/ron-imperva/javascript-drive-by
如随附视频所示,如果用户按照这些步骤操作,攻击者可以在他们的机器上执行任意命令。在我们的例子中,我们只是打开计算器,但任何命令都可以在 Chrome 和 macOS 沙箱之外执行。
我们在这里利用的唯一漏洞是绕过 Chrome 阻止列表,该列表通常会阻止对 macOS 上 /Applications 文件夹的读写访问。但是,可以使用阻止列表中没有的许多其他文件来实现类似的结果。
负责任的披露和结论
我们向 Google 报告了阻止列表绕过,他们验证了这个错误并表示他们已经意识到了这一点并正在努力修复。在撰写本文时,此绕过仍未修补。由于已经超过 10 个月,我们决定发布漏洞详细信息和概念验证代码。
我们认为,Google 可以解决这个问题的一种方法是删除文件系统访问 API 修改的文件的执行权限。我们向 Chromium 团队推荐了这个解决方案,但在撰写本文时,它仍在积压中等待考虑。
Google 通知我们,他们计划将文件系统访问 API 限制在 Chrome 应用程序包中,这应该可以缓解本博文中讨论的特定攻击。这些变化预计将在 Chrome 132 中实现。
总之,网络技术的快速发展继续突破了在线可能性的界限。然而,正如文件系统访问 API 相关风险所表明的那样,这一进步也带来了一系列挑战,凸显了功能性和安全性之间的微妙平衡。
就像 Java 驱动下载的旧时代一样,即使在今天,几次错误的点击也可能导致严重的安全问题。在允许访问您的文件之前,请保持警惕并三思而后行。