至此，我们已经确定了一个可以由Safari自动启动的应用程序，但是我们还不知道如何正确地打开它。幸运的是，这很简单。

研究表明，iCloud文件共享可以生成一个公共共享链接。

创建公共iCloud共享链接

这些共享链接看起来如下所示：https://www.icloud.com/iclouddrive/01fooriERbarZSTfikqmwQAem。

只需简单地将“https”替换为“icloud-sharing”，就可以让Safari自动打开ShareBear，并将该文件作为参数。

evil.html

太好了，那么 ShareBear 现在做了什么？一些快速测试显示了这种行为：

ShareBear行为流程图

这种行为存在一个微妙但却极具影响力的设计漏洞。让我们研究一下如果用户之前没有打开过这个文件会发生什么，用户将看到一个类似于下面的提示。

ShareBear打开提示

这个无关紧要的小提示符，默认值为“Open”，看起来非常简单。如果用户同意，应该会打开图片example.png。但实际上，他们达成的协议远不止这些。

一旦用户点击“Open”，文件就会被下载到受害者的设备/Users/< user >/Library/Mobile Documents/com~apple~CloudDocs，然后通过 Launch Services 自动打开。这样用户就再也看不到这个提示符了。此后，ShareBear以及 Safari 中的任何网站将能够自动启动该文件。这个协议真正有漏洞的部分是，任何具有写入访问权限的人都可以更改文件。例如，在你同意打开文件后，文件的所有者可以更改整个字节内容和文件扩展名。然后ShareBear将下载并更新受害者设备上的文件，而无需任何用户交互或通知。

实际上，受害者已经允许攻击者在他们的设备上植入多个文件，并允许攻击者在任何时候远程启动它。PNG文件是一个可执行的二进制文件，只要我想，它就会自动启动。

根据我反馈的报告，苹果在macOS Monterey 12.0.1中修复了这一行为，但没有发布CVE，因为这顶多是一个设计漏洞。

躲避Iframe沙盒检测

在对 icloud-sharing:// 方案进行模糊测试时，我偶然发现了一个与 UXSS 搜索无关的有趣漏洞。在执行上述行为之前，ShareBear 似乎会检查“/iclouddrive/*”的 URL 路径。如果路径恰好是“/photos/*”，那么 ShareBear 会犯一个非常愚蠢的错误。它会告诉 Safari 打开一个指向 iCloud Web 应用程序的新选项卡，但它不会验证域名是否真的是 iCloud Web 应用程序。

在正常操作中，用户只看到网站“https://photos.icloud.com”。然而，由于该域名从未经过验证，我们可以欺骗 ShareBear 指示 Safari 打开任何网站的新标签页。

这种行为的影响可能并不明显。因为它似乎与通常调用window.open('https://example.com')没有什么不同。然而，有些情况下，网站是不允许这样做的。一个示例是是否启用了弹出窗口阻止程序。另一个更狡猾的例子是当你的网站位于沙盒 iframe 中时。

当你想在你的网站上嵌入不可信的第三方内容时，通常会使用sandbox iframe属性。例如，你可能想在你的博客上显示一个广告横幅，但你不希望这个广告能够运行JavaScript。

沙盒iframe的一个重要规则是，从该iframe打开的新窗口应该继承与iframe本身相同的限制。否则，逃离沙盒就像打开一个弹出窗口一样简单。

这个漏洞会诱使 Safari 打开一个没有任何沙盒限制的新标签！

网站被困在沙盒 iframe 中

所以ShareBear忽略了验证域，这给了我们一个简单的弹出框拦截程序和一个iframe沙盒逃逸。（在未分配 CVE 的情况下在 Safari 15.2 中修复）在BugPoC上的演示视频链接为https://bugpoc.com/poc#bp-S4HH6YcO PoC ID: bp-S4HH6YcO，密码：loVEDsquId01。请注意，这个演示只适用于Safari 15.2之前版本的macOS Monterey 12.1。

现在返回Camera/UXSS 搜索话题。

Quarantine 和Gatekeeper

我们的网站可以提示用户打开一个共享的PNG文件。如果用户同意，我们可以在将来的任何时候自动启动这个文件，即使我们改变了文件的内容和扩展名。

然后，攻击者可以在自己的设备上修改文件，而ShareBear将负责在受害者的设备上更新它。

攻击者的设备和受害者的设备上的操作过程：

改变polymorphic文件

然后，攻击者的网站可以使用与显示原始提示符相同的 icloud-sharing:// URL自动启动这个新更新的文件。

这似乎非常接近我们强制下载和打开一个恶意webarchive文件的目标，我们可以将puppy.png的内容替换成一个webarchival文件，并将其重命名为“evil.webarchive”，不幸的是，讨厌的macOS Gatekeeper不允许这样做。

Gatekeeper预防策略

看来 ShareBear 正确地为下载的文件提供了 'com.apple.quarantine' 属性，并且根据 Apple 的说法，“Gatekeeper 阻止了被隔离的可执行文件和其他类似文件（shell 脚本、webarchive等）打开或执行。”要深入了解 macOS 如何处理此属性，以及 Gatekeeper 如何执行代码签名，请查看本文。

就渗透测试而言，此操作系统保护引入了两大限制：

1.我们不能运行自己的应用程序；

2.我们不能直接打开webarchive文件；

侧边栏——虽然我们不能运行自己的应用程序，但启动现有的、经过批准的应用程序是微不足道的。只需使用fileloc指向本地应用程序(这种技术很常见)。这种攻击有时被称为“任意文件执行”，并且经常被误解，因为它看起来很可怕。

指向 macOS 计算器的 fileloc

使用icloud-sharing://方案启动fileloc

虽然这种攻击可能看起来很可怕，但启动一个已经批准的应用程序不会有太大的影响。让我们专注于打开webarchive。

快捷键

上述打开本地应用程序的技术让人想起老式的符号链接攻击，它基本上只是使用“快捷方式”来欺骗软件打开它不期望的东西。

多年来，许多不同的操作系统和应用程序在快捷方式方面进行了重新设计。现在，术语“快捷方式”可以指一个Unix符号链接、一个macOS别名、一个windows的链接文件、一个Safari的webloc、一个Edge的书签等。

我希望我可以使用这个技术来绕过Gatekeeper，打开一个webarchive文件。这个想法对我来说似乎很有希望，因为我想要打开的实际应用程序是Safari(一个已存在的、已批准的应用程序)。Gatekeeper 对我启动 Safari 没有问题，当我尝试打开任何以“.webarchive”结尾的文件时，它只会感到不安。

因此，我需要找到一个启动Safari的快捷方式文件类型，然后告诉Safari打开一个不同的文件。经过反复试验，我发现了古老的 Windows URL 文件！

evil.url 文件指向本地 webarchive

启动 evil.url 成功打开 Safari 并指示它加载 webarchive 文件而无需请求 Gatekeeper 许可！(CVE-2021-30861) 只有一个小漏洞，我需要知道 webarchive 文件的完整路径。假设 webarchive 是通过 ShareBear 下载的，它将存在于 /Users/< user >/Library/Mobile Documents/com~apple~CloudDocs中，其中包括受害者的用户名（不是一个非常可扩展的攻击）。

幸运的是，有一个巧妙的技巧可以规避这个要求——我们可以使用 DMG 文件将 webarchive 文件挂载到已知的 /Volumes/ 目录中。

使用icloud-sharing://方案挂载dmg

现在我们确切地知道 webarchive 文件所在的位置。这意味着下面的 evil.url 文件每次都可以使用。

evil.url 文件指向一个已知位置的本地 webarchive

使用 icloud-sharing:// 方案启动 evil.url 以打开 evil.webarchive

就像这样，我们在任何我们想要的地方执行 JavaScript 代码。上面的屏幕录像在 https://google.com 中注入了“alert(origin)”。

让我们将其组合成最后一次攻击。

完整的攻击链

使用ShareBear为我们下载和打开一个webarchive文件，可以分为3个步骤：

1.诱骗受害者给予我们植入polymorphic文件的权限。

2. 把 puppies.png 变成 evil.dmg 并启动它。

3. 将 evil.dmg 变成 evil.url 并启动它。

当然把文件A转换成三个不同的有效载荷需要一些服务器端协调。另一种(不那么有趣的)实现这种攻击的方法是让受害者同意打开一个已经有所有文件的共享文件夹。

通过查看 iCloud 共享文件夹对 UXSS 进行屏幕录制

在上面的屏幕录制中，受害者同意查看一个包含一些PNG图像的文件夹。这个文件夹还有两个隐藏文件：.evil。dmg & .evil.url。

该网站使用icloud-sharing:// URL方案自动启动两个隐藏文件，成功绕过Gatekeeper，并打开一个webarchive文件。请注意，在受害者同意查看共享文件夹后，不会向他显示额外的提示。上面的示例 webarchive 文件将代码注入 https://www.icloud.com 以窃取受害者的 iOS 摄像头记录。

当然，这只是一个例子，这种UXSS攻击允许攻击者将任意代码注入到任意源。在劫持 https://zoom.us 或 https://facetime.apple.com 等受信任的视频聊天网站时，注入 JavaScript 代码以打开网络摄像头同样容易。

UXSS 劫持 Zoom 网站以打开网络摄像头

漏洞修复

那么苹果是如何解决这些漏洞的呢?

第一个修复是让ShareBear只显示文件而不是启动它们(在macOS Monterey 12.0.1中修复，没有分配CVE)。

第二个修复是阻止WebKit打开任何被隔离的文件(在Safari 15中修复为CVE-2021-30861)。

总结

在我发现 evil.url 技巧之前，我实际上找到了一种不同的方法来欺骗 Launch Services （间接）打开一个 webarchive 文件。我在 Safari 的最新公开版本 (v14.1.1) 中发现了这个漏洞。在向 Apple 报告此漏洞几天后，他们告诉我 beta 版 Safari v15 没有这个漏洞。似乎不相关的代码重构使 v15 无法渗透。

通过启动服务打开Safari的明显方法是使用本地html文件。一旦打开，这个页面将有file:// URI 方案。这样，JavaScript被允许导航到其他file:// URI 。

本地HTML文件导航到另一个本地文件

那么，如果我们要导航到的文件是一个webarchive，会发生什么呢？此时，Safari只是挂着。

Safari拒绝出现webarchive的屏幕记录

当目标文件是webarchiving时，这种挂起发生在我能想到的所有类型的页面导航(anchor href, iframe src, meta redirect等)。

然后我发现了这个漏洞：

本地HTML文件导航到本地webarchive文件

当 file:// URL 中有主机值时，Safari 忘记执行 webarchive 检查！有趣的是，这个漏洞似乎是在 Apple 修复我的旧 file:// 漏洞 (CVE-2020-3885) 时引入的。

当苹果公司通知我Safari Beta v15不存在漏洞时，我重新检查了一下，还是发现了 evil.url。

在我完成 UXSS 链后，还有一件事困扰着我，它不能用来窃取本地文件。当然，UXSS 可用于通过将代码注入 https://dropbox.com 或 https://drive.google.com 来间接窃取文件，但无法获取受害者硬盘上的文件。

我前面提到的出色的Blackhat Presentation启发了我去寻找其他系统应用程序，它们可以在比Safari更优越的环境中运行我的JavaScript。在深入研究了一段时间后，我偶然发现了一个模糊的文件类型，它可以识别我的macOS脚本编辑器，名为“脚本添加”(.osax)。这些文件（或者更确切地说是“捆绑包”）包含一个嵌套的基于 xml 的文件，称为“Dictionary Document”(.sdef)。这个字典文档用于显示AppleScript应用程序使用的、人类可读的、开发人员定义的术语。

重要的发现是允许这些基于 xml 的文件包含 HTML。事实证明，HTML呈现器也有一个JavaScript引擎，而且这个引擎不强制执行 SOP！（在 macOS Big Sur 11.6.2 中修复为 CVE-2021-30975）这意味着窃取 /etc/passwd 很容易。

evil.sdef 显示 /etc/passwd 的内容

幸运的是，Gatekeeper 不介意我们打开脚本添加文件。所以我们只需将 evil.sdef 打包到 evil.osax 中，然后通过 ShareBear 将其发送给受害者。然后我们的 icloud-sharing:// URI 可以在脚本编辑器中自动启动它。

ShareBear 打开 evil.osax 窃取 /etc/passwd 的屏幕录像

所以现在除了UXSS，这个攻击还可以绕过沙盒限制和窃取本地文件！

最后的话

这个项目是对一个应用程序中的设计缺陷如何使其他各种不相关的漏洞变得更加危险的有趣探索。这也是一个很好的例子，说明即使macOS启用了Gatekeeper，攻击者仍然可以通过欺骗已批准的应用程序进行恶意操作来实现许多恶意操作。

参考及来源：https://www.ryanpickren.com/safari-uxss