本文我们将介绍通过 Safari UXSS 获得未经授权的摄像头访问权限，以及如何进一步利用一个共享 iCloud 文档攻击你访问过的每个网站。
本次是利用发现的Safari中的7个0 day漏洞（CVE-2020-3852，CVE-2020-3864，CVE-2020-3865，CVE-2020-3885，CVE-2020-3887，CVE-2020-9784和CVE- 2020-9787），其中三个用于构造利用链劫持访问摄像头。
简而言之，该漏洞使苹果认为恶意网站实际上是值得信赖的网站，它通过利用Safari如何解析URI，管理Web Origin以及初始化 Secure_Contexts的一系列漏洞来实现劫持。如果恶意网站将这些漏洞利用串在一起，则可以使用JavaScript 直接访问受害者的网络摄像头，而无需征求许可。任何具有创建弹窗功能的JavaScript代码都可以发起此攻击。
而在本次尝试中。我成功地利用了iCloud Sharing和Safari 15的一系列漏洞，来获得了未经授权的摄像头访问权限。虽然这个漏洞确实需要受害者点击“打开”从我的网站弹出的窗口，，但它导致的不仅仅是多媒体权限劫持。这一次，该漏洞使攻击者可以完全访问受害者曾经访问过的每个网站。这意味着除了打开你的摄像头之外，我的漏洞还可以破解你的 iCloud、PayPal、Facebook、Gmail 等帐户。
本次共使用了4个发现的0 day漏洞(CVE-2021-30861、 CVE-2021-30975， 另外2个并没有CVE)，其中 2 个被用于黑入摄像头。我已向苹果报告了这个漏洞链条，并获得了100500美元的赏金。
背景介绍
苹果通过增加摄像头访问的难度，修复了我上一次报告的漏洞链(CVE-2020-3852 + CVE-2020-3864 + CVE-2020-3865)。在这次赏金计划中，该漏洞链会让苹果认为恶意网站实际上是值得信赖的网站，它通过利用Safari如何解析URI，管理Web Origin以及初始化 Secure_Contexts的一系列漏洞来做到这一点。如果恶意网站将这些漏洞利用串在一起，则可以使用JavaScript 直接访问受害者的网络摄像头，而无需征求许可。任何具有创建弹窗功能的JavaScript代码都可以发起此攻击。iOS和macOS中的摄像头安全模型非常严格，简而言之，必须为每个应用程序明确授予摄像头/麦克风许可，这由操作系统通过标准警报框处理。但是这个规则有一个例外。苹果自己的应用程序可免费使用摄像头，因此，Mobile Safari从技术上无需询问即可访问摄像头。此外，诸如MediaDevices Web API（通常用于WebRTC传输）之类的新网络技术使网站可以利用Safari的许可直接访问摄像头。但当时苹果认为此漏洞属于“ 无用户交互的网络攻击：对敏感Data的零点击未授权访问 ” 类别， 并奖励了我75000美元。
现在多媒体访问只允许协议为“https:”，并且域匹配你保存的设置。这意味着巧妙地格式漏洞的 URI 将不再适用，之前我专门讲了file:我使用的下一个方案是file:。该方案不包含有意义的主机名，我深入探究RFC，实际上偶然发现了file: URI的一个变化中确实包含主机名的URI。这种URI实际上指定了一个远程服务器，类似于FTP，但是此规范未定义对存储在远程计算机上的文件的检索机制，搜索了一段时间后，我找不到任何实际上支持这种的URI类型的用户代理。
file：//host.example.com/Share/path/to/file.txt
出于好奇，我检查了Safari如何在内部解析普通文件URI。
果然主机名为空，接着我使用JavaScript指定主机，看看会发生什么。
该页面竟将该URI视为有效，并重新加载了相同的内容。这意味着我只是使用了一个技巧就更改了document.domain（CVE-2020-3885）。
果然，Safari认为在skype.com上，可以加载一些恶意的JavaScript。当你打开本地HTML文件时，摄像头，麦克风和屏幕共享都会受到损害。Safari似乎也使用这种惰性主机名解析方法来填充密码的自动完成功能，因此，如果你接受自动完成功能，就可以窃取纯文本密码。
此攻击需要受害者打开本地HTML文件。另外，它在iOS上不起作用，因为通过Mobile Safari下载的本地文件在没有JavaScript引擎的情况下以预览样式的嵌入式视图显示。
现在我们需要真正将我们的恶意代码注入目标源，换句话说，我们需要找到一个通用跨站脚本 (UXSS) 漏洞。
那么UXSS与通常的XSS区别是什么？因为同源策略，即使一个漏洞页面存在XSS，我们可以访问用户会话信息却无法访问其他域的相关的会话信息，而因为UXSS是利用浏览器本身或者浏览器扩展程序的漏洞，所以对于攻击发起时浏览器打开或缓存的所有页面（即使不同域的情况）的会话信息都可以进行访问。简单的说，UXSS不需要一个漏洞页面来触发攻击，它可以渗透入安全没有问题的页面，从而创造一个漏洞，而该页面原先是安全无漏洞的。
因为UXSS攻击不需要页面本身存在漏洞，同时可能访问其他安全无漏洞页面，使得UXSS成为XSS里危险和最具破坏性的攻击类型之一。
同样，我们可以建立一个网站，它可以跳转到https://zoom.com打开摄像头，跳转到https://paypal.com转账，并劫持https://gmail.com来窃取电子邮件。
在继续之前，我应该澄清一个事情。本文讲的这个漏洞与我的上一篇讲的Safari摄像头被攻击到底有什么不同？该漏洞会专门针对存储的多媒体权限。它没有给我在任意原点上执行代码的能力。查看我的攻击图，看看哪些来源被使用。换句话说，本文的攻击链只会让我利用Skype的摄像许可，但不会让我窃取Skype的cookie。
首先让我们尝试在Safari最新版本(撰写本文时为Safari v15 beta版)中找到一个UXSS漏洞。和往常一样，第一步首先是要做大量的研究。
攻击计划
在阅读了大量关于Safari UXSS漏洞补丁的文章后，我决定将研究重点放在webarchive 文件上。webarchive 文件是 Mac 系统 Safari 浏览器的存档文件，是保存网页内容的特殊文件格式Mac OS X 系统带有文件转换功能，可以把 webarchive 文件变成 html 文件。当用户在本地保存网站时，这些文件是由Safari创建的，作为HTML的替代品。
Safari浏览器将网站保存为webarchival文件
这些文件的一个令人吃惊的特点是，它们指定了内容应该呈现的网络来源。
Webarchive文件格式
这是一个很棒的技巧，可以让Safari重建保存的网站的上下文，但正如Metasploit开发者在2013年指出的那样，如果攻击者能够以某种方式修改这个文件，他们就可以有效地实现设计好的UXSS。
根据 Metasploit 的说法，苹果并不认为这种攻击场景真的可以实现，因为“webarchive必须由客户端下载并手动打开。”当然，这个决定是在近十年前做出的，当时浏览器安全模型还没有今天那么成熟。
苹果决定支持这种超级强大的文件类型，这样攻击就会尝试在受害者的设备上强行打开它们。攻击可以分为两个步骤：
1.强行下载一个恶意的 webarchive 文件；
2.强行打开它；
直到最近，还没有任何保护措施来阻止第一步。在Safari 13之前，网站在下载任意文件之前甚至不会向用户显示任何警告。所以植入webarchive文件很容易。自从出现了Safari 13以上的版本，每次下载前都会提示用户。
而强行打开wearchive文件则更加困难，但仍然可以通过以某种方式导航到 file:// URI 方案来管理。当Safari的存在漏洞页面出现在file:// scheme中时，就会发现如何故意调用漏洞页面来改变它的路径名，这种攻击方法被戏称为“Errorjacking”，先后出现过两种变体（1，2）。另一种在当时有效的方法是简单地将标记设置为 file://。
但到了2022年，该技巧就不灵了。不仅默认情况下会阻止自动下载，而且webarchive文件被macOS Gatekeeper认为是恶意应用程序。这意味着用户甚至不能自己手动打开国外的webarchive。目前，苹果似乎已经改变了他们在2013年对这些文件有多危险的看法。
Safari 13以上版本中的下载提示
Gatekeeper预防策略
尽管如此，webarchive文件看起来还是太有趣了，让人无法放弃。让我们来探索一下，这种老式的攻击攻击方式是如何在最新的 Safari 和 macOS 版本上发生的。
探索自定义 URI 方案
通过深入研究 IANA 注册的官方 URI 方案，我在上一个 Safari 摄像头攻击项目中取得了成功。该项目在很大程度上受到 RFC 和公共文档的指导。但是我忽略了整个自定义 URL 方案的世界。这些非官方和大部分未记录的方案通常被第三方 iOS/macOS 应用程序用作深度链接的一种形式。
有趣的是，Apple Help Viewer (help://)、FaceTime (facetime-audio://) 和 Apple Feedback (applefeedback://) 等多个系统应用程序也支持自定义 URI 方案。在 Safari 的网站上滥用这些方案并不是一种新技术。事实上，一段时间以来，攻击一直在寻找使用自定义方案来启动并利用其中的漏洞系统应用程序的方法。攻击范围包括烦人的拨打电话、协助社会工程到任意文件执行。
为了帮助对抗这些攻击，Safari 的现代版本会在盲目启动辅助应用程序之前警告用户。也就是说，除非它们是 Blackhat 演示中确定的硬编码异常之一。
Safari 将在没有提示的情况下启动的自定义 URI 方案
所有这些方案都在 Launch Services 中注册，因此你可以通过以下命令列出它们：
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep -B6 bindings:.*: | grep -B6 apple-internal
在仔细研究了苹果的内部方案后，并将它们与Safari信任的方案进行交叉比对后，我发现了一个吸引我眼球的方案——“icloud-sharing：”。这个方案似乎是由一个名为“ShareBear”的iCloud共享应用程序注册的。
关于 icloud-sharing的 LaunchServices数据
我对ShareBear很感兴趣，因为分享iCloud文件似乎是下载和发布webarchive文件的可行途径。我找不到任何关于这个计划的公开文档或研究，所以我就自己开始研究它。
还没有评论，来说两句吧...