0x01 前言

在这篇文章中,我们将描述和演示了一个简单的技巧,我们会使用一个工具,利用智能手机或笔记本电脑的环境光传感器。从你的浏览器中提权敏感信息。

简而言之:

  1. 我们提供有关光传感器API和当前相关讨论的背景,以更广泛地将其公开给网站,让更多人认识到它。
  2. 我们展示用户设备的屏幕颜色如何影响光传感器的读数,并解释为什么这会带来危险的安全和隐私后果。如果提取浏览历史和窃取来自跨原始帧的数据,攻击者可以发现敏感文档和图像的内容(例如用于帐户恢复的QR码)。
  3. 我们讨论浏览器供应商和规格维护者应该采取怎样的对策来减轻风险。

该攻击在Android和带有光传感器的桌面设备(如MacBook Pro)的最新版本Firefox和Chrome都起作用。

这篇文章是@LukOlejnik和@arturjanc之间的合作测试编写的,他们构建了一些概念证明,并验证了这些概念。

0x02 背景:智能手机中的光传感器

今天,所有的智能手机和一些笔记本电脑都配备了环境光传感器。该传感器多数安装在设备的顶部区域,通常是靠近前置摄像头的位置。智能手机长期以来利用环境光读数调整显示亮度的优点,来节省电量,或者用于接近检测。有关光照条件的信息也可以被用来设计响应智能手机应用程序,或配置硬件本身。光传感器读数是一个敏感的数据,正如上一篇文章中所讨论的

环境光传感器返回的数据相当精确。测量的光强度为SI单位Lux,输出数据的范围为0(黑暗)至数万lux。从传感器读取的频率相对较高,允许以100-200毫秒的间隔读取。

为了更好地与设备上的应用程序竞争,可能网站很快就可以访问环境光读数了。目前W3C Device and Sensors Working Group正在进行讨论,可是否允许无需用户的许可下网站就可以访问光传感器。Chrome和Firefox的最新版本都有这个API的实现。

0x03 传感器隐私

这项研究是最近W3C讨论关于通用传感器API的讨论重点,其中一个主要提案假定访问某些传感器数据不用用户许可。作为回应,我们决定调查环境光传感器(ALS)被恶意利用的潜力,作为附注,我以前分析了ALS的安全和隐私方面,这可能会引入新的跟踪,分析和数据泄漏的新方法,如:一个例子讨论了“ 检测到两个人同时在同一个房间 ”,另一个分析了发现银行PIN码的可能性。

在这篇文章中,我们将把这些放在一边,并重点关注恶意攻击者如何使用传感器读数从用户的浏览器中读取分析私人数据。

现在,我们来谈谈这个攻击。

0x04 使用光传感器进行渗透信息

环境光读数如何准确地提取私人数据?我们的攻击基于两个观点:

稍后我们再详细介绍第二点,但简而言之,从屏幕发出的光可以用可测量的方式影响光传感器读数,允许网站确定用户屏幕的颜色(或者在最简单的情况下,将黑色屏幕与白色区分开来)。

第一点可能是更令人惊讶的一点,所有网站控制用户屏幕上显示的内容,那么为什么这会是有趣的数据呢?在两种主要情况下网站无法直接获取用户部分屏幕的颜色:

我们的攻击依赖于在屏幕上显示这些资源并检测其颜色,它一次只泄漏一点信息。下面是如何在实际中利用的展示(可以阅读我们早期的文章,了解更多详细内容):

检测访问链接

由于网站可以对访问和未访问的链接应用不同的样式(style),但无法检测链接如何给用户显示,因此我们使用传感器来识别其真实颜色:

  1. 设置链接样式:访问(白色),未访问(黑色)。
  2. 校准:显示白色背景,然后按照黑色背景识别用户环境中的光线水平; 但是如果传感器读数波动明显,这也是可能可以的,但更难。
  3. 通过一个个链接列表遍历,在整个屏幕中依次为一个大矩形填充显示它们。访问的链接将显示为白色,未访问为黑色。
  4. 记录光级别作为展示每个链接的响应方式,识别出链接的颜色。由于我们在步骤2中校准了屏幕,所以我们知道每个读取所代表的颜色。

最后,攻击者获取屏幕列表为白色的链接,并且知道用户以前访问过给定的哪些页面。

视频示例:https://youtu.be/Rg0LQ3npkP0

虽然在我们的概念示范证明中,我们依赖于假设在渗透期间光线条件不变的,但扩展演示来处理这些情况不应该是一个问题。在第一次演示中,我们要强调的是,光读出的数值可能会发生变化。但实际上,克服这个障碍并不困难。

窃取跨域资源

更麻烦的是,攻击者可以提取像素完美的跨原始图像和框架:基本上,发现给定的站点或图像如何寻找被攻击的用户(在我们的演示中,我们专注于图像,因为它们更容易提权出来)。在极端情况下,例如在使用帐户恢复QR码进行帐户紧急访问的网站(https://victim.com/account-code.png)上,这可能会让攻击者劫持受害者的帐户。

视频示例:https://youtu.be/LF8Wi1UVj7U

这种攻击类似于Pixel Perfect Timing论文中的技术,工作原理如下:

  1. 内嵌一张受攻击的域名的图像,这将是一个不同的身份验证用户(如登录的用户头像或安全码)的资源。
  2. 使用SVG过滤器创建图像的单色表示(SVG中的过滤器在跨域资源上工作)。
  3. 缩放图像,使每个像素展开可以填满整个屏幕。
  4. 迭代图像中的所有像素,将其显示在用户的屏幕上,并记录该像素的光传感器读数。
  5. 从每个像素读数构图结果图像。

AlsQrExfil

这允许从跨域内嵌框架iframing(没有X-Frame-Options头或帧祖先内容安全策略指令)的任何文档中提权出所有图像资源和数据。

0x05 攻击细节和其它考虑

现在我们已经展示了如何攻击,那么我们再讨论一下实际利用这种技术的一些考虑。

检测速度

由于我们一次只提取一点信息,所以漏洞利用的主要限制因素是检测速度。原则上,浏览器传感器可以提供60 Hz的读取速率。然而,这并不意味着我们实际上可以每秒提取60位 ,这是因为最终的检测限制与传感器检测到的屏幕亮度变化速率有关。在我们的实验中,我们测量了屏幕亮度读数,读出延迟为200-300ms,为了完全可靠的利用,假设每500ms一个位更现实。

按照这个速度,示例检测时间如下:

用户不可能会忍受一个在黑白之间来回切换很长时间,而且只是检测很短的文本字符串的网站。然而,在用户离开设备,用户不适用的某些情况下(例如,晚上将设备放在桌子上),攻击者将能够提取更多的数据; 使这个实用的恶意网站可以使用screen.keepAwake API来无限制地保持显示。

将来,光传感器可能能够测量强度或特定的颜色饱和度(红色,绿色,蓝色),这将允许攻击者可以更快速的攻击。

传感器读数精度

虽然光传感器本身提供了准确的读数,但实际这种技术的最难点是测试期间照明条件不停的变化,以及用户会拿着设备移动的可能性(尤其是移动手机)。

我们发现结果的准确性受到诸如屏幕亮度(较亮的屏幕有助于攻击),传感器上方反射表面的接近度和角度(放在平行表面的话,电话机产生的反射光是良好结果;缺乏反射表面使得攻击更加困难),以及周围环境光线的数量(较暗的环境,杂音较少,使检测更容易)的因素影响。

浏览器支持

攻击在两个现代浏览器中运行:Firefox和Chrome目前运行的旧API被称为环境光事件,在我们的演示中也使用了这一点,它在Firefox中未经许可即可使用,但在Chrome目前仍需要启用chrome://flags#enable-experimental-web-platform-features标志。这个旧的API将很快被一个新的Ambient Light Sensors API所替代,该API目前在Chrome后面实现了一个标志(chrome:// flags#enable-generic-sensor),这在我们的功能上目的是一样的。

视频示例:https://youtu.be/SI8Uf-VCixs

我们已经提交了FirefoxChrome的提交了安全/隐私错误报告。

0x06 总结

防御方法

目前的提案认为,使用以下保护措施是足够的:

据我们所知,这些预防措施意味着基于研究结果的漏洞报告的回应,这表明可以使用陀螺仪恢复音频信号。我们的理解是,Chrome提案试图将“ 陀螺仪误用 ”的解决方案也应用于其它传感器,但是这对于所有传感器来说是不可能的。根据具体和专门的风险威胁模型的尝试可能不正确。

对于光传感器,限制频率不会阻止我们的攻击 ; 甚至频率低至1Hz,攻击者也是可以发出相同类型的攻击,只有因素二会使攻击变慢。

只要能保证屏幕颜色不会影响传感器的输出级别就可,限制输出的精准度可能是更好的解决方案。可能在某些其他情况下攻击也可能实现(亮屏、反射面离屏幕很近),但在实践中这将变得更加困难。

也许最容易的解决方案是要求用户向访问传感器的网站授予权限,就像其他功能(如地理位置)一样。将安全和隐私考虑放到缓解光传感器(Ambient Light Sensor) API规范中来记录这种攻击的风险也是一种方法。,

用户建议

在Firefox中,关闭传感器:在about:config页面中把device.sensors.enabled设置为“ false ”。在Chrome中,大多数用户应该是安全的,除非他们手动启用了前面提到的一个实验标志。

网页开发者推荐

为了保护文档不被不受信任的站点绑定,请设置X-Frame-Options:Deny HTTP header。这也可以防止其他攻击,如劫持攻击。

目前无法减轻对图像的攻击,因为它们不受X-Frame-Options限制。

所演示的攻击显示,环境光传感器看似无害的数据输出可能会让恶意站点违反同源策略,窃取跨域数据并提取有关用户浏览历史的信息。

在这里我们可以看到,从隐私工程的角度来设计规范和系统是一个复杂的过程:不应轻率做将敏感API暴露给网络而没有任何保护的决定。另一个风险是,没有规范作者和浏览器供应商将基于不适用于特定新功能的一般原理和研究结果的做同样的安全决策(类似于陀螺仪读数的保护但这对于光传感器数据进行同意的保护可能不行)。

 

*作者:Lukasz Olejnik

源链接

Hacking more

...