在开始今天的正文之前，先插播一条来自我们的读者，也是USENIX Security 2024论文Your Firmware Has Arrived: A Study of Firmware Update Vulnerabilities的第一作者武玉豪的读者来信，他提到在【G.O.S.S.I.P 阅读推荐 2023-11-22 Your Firmware Has Arrived】中指出的问题——CVE信息没有更新以及Dataset没有link目前已经修正了：
Dataset：https://github.com/WUSTL-CSPL/Firmware-Dataset
其实，这篇论文是2024年8月才会正式发表，目前信息不全也是完全能理解的，但是武玉豪真的是非常负责，我们G.O.S.S.I.P的读者都棒棒哒，希望G.O.S.S.I.P的读者能够全面占领各大安全会议，把它们变成我们的读者交流会！
每天pwn来pwn去，有没有听说过chrown？今天来读一篇Euro S&P 2023的论文Chrowned by an Extension: Abusing the Chrome DevTools Protocol through the Debugger API，看看Chrome浏览器的扩展（extension）中的安全问题。
先来了解一下背景知识：chrome浏览器为第三方扩展插件提供了一组API，这样插件才能实现各种功能（例如广告屏蔽）。由于这些API威力巨大，浏览器设置了特定的权限来对其进行限制，插件只有申请并得到允许，才能使用特定的功能。这其中，名为debugger的权限和尤为敏感（听起来就很危险），因为它允许插件去访问一种基于websocket的调试协议——Chrome DevTools Protocol（CDP，只允许访问一部分），而CDP是强大而危险的的黑魔法，大家可以访问如下网址了解更多信息：
https://chromedevtools.github.io/devtools-protocol/
作者研究后发现，使用debugger权限的API，也就是debugger API，在现实中可以绕过浏览器现有的权限模型，获取更多的资源，同时还能打破浏览器的隔离限制，访问一些第三方的目标。针对这些风险，作者具体提出了6种安全攻击（下表），那这些攻击究竟有什么危害，我们一起去看看论文的第四章里面的详细介绍。
在第一种攻击中，作者指出，所有的插件在使用debuggerAPI时，都必须调用chrome.debugger.attach()函数并且传入一个指定要访问的标签（tab）身份的ID（也就是tab ID），而系统维护了一个此类ID的列表，可以通过调用chrome.debugger.getTargets()函数来获取。同时，这个函数还返回了打开的每个标签对应的URL、favicon等信息，因此攻击者完全可以利用该函数（下面是一个示例）来轮询并监视浏览器的行为：
知道了上述信息，在第二种攻击中，debugger API可以注入（attach）所有的常规标签（regular tab，也就是用http和https协议访问的tab）来实施各种行为控制（比如下表中的读取cookie的行为）：
而且更严重的问题是，尽管用户可以要求结束调试（detach），但是插件可以在注入退出后立即重新注入（不需要任何用户同意）来实现“牛皮糖”的功能，而且如果知道了“无痕浏览模式”（incognito mode）中标签的tab ID，插件一样可以注入到这些标签上去，你想偷偷做点什么事情也会被发现哦！
第三种攻击针对的是所谓的security interstitial tab，也就是存在安全风险的一些标签（例如证书过期了但是用户坚持要访问的时候，浏览器就会启动一个这样的标签）。正常情况下，浏览器会对这种标签进行各种限制，防止其中可能存在的恶意代码产生不良后果，但是拥有debugger权限的API不受这个限制，可以直接静默地强制跳过警告，让用户无法察觉到启动的是一个security interstitial tab而不是一个普通标签。不过话说回来，编辑部倒是很想写一个这种插件自用，遇到证书过期的时候就自动点击“继续访问”（不是）。
第四种攻击是针对一些高权限的WebUI标签页（例如chrome://about和chrome://settings），正常情况下，浏览器插件是不允许访问这些标签，但是2013年3月引入的一个实验性的flag——extensions-on-chrome-urls允许插件显式地申请到chrome://*权限，从而访问WebUI标签。于是2018年开始，Chromium Security Team强制屏蔽了任何插件直接通过debugger API访问WebUI的行为。
但是，浏览器里面有一个官方的Screen Reader插件，它的功能是要朗读出页面上的信息，而Chromium开发组给这个插件开了条绿色通道，允许它访问WebUI标签。可是作者指出，在浏览器中插件的身份是用ID表示的，而ID是可以伪造的，一个恶意的插件可以使用和Screen Reader插件一样的ID来获得同样的权限。具体地操作方式是通过“加载解压缩的扩展”这种方式来实现，究竟怎么做呢？
通过“加载解压缩的扩展”这种方式加载的插件是没有公钥签名的，而标准的计算插件的ID的流程如下图所示，可以看到，在没有公钥的情况下，如果插件的manifest.json文件中声明了一个key属性，ID就会根据这个属性来计算，那么攻击者就可以操控这个属性（见下面的Listing 5），让浏览器计算出来一个和Screen Reader插件一样的ID（考考你，怎么做？）然后完成攻击！
进入到第五种攻击，对于插件本身来说，它们其实也是运行在一个chrome-extension://<extension-id>格式的标签中，不同插件之间如果需要互相访问，要通过一个message passing机制（具体信息参见 https://developer.chrome.com/docs/extensions/mv3/messaging/ 网页）来实施。但是在extensions-on-chrome-urls这个flag（对，就是前面说过的那个2013年立下的flag）开启之后，插件通过debugger API是可以附加到其他插件上，然后就可以拿到其他插件的权限（对，我就想附身到Screen Reader插件上），接下来的事情你懂的~ 作者在本文配套的代码中演示了注入LastPass插件和Mailvelope插件去分别盗取password和PGP private key的概念攻击！
最后一种攻击又是因为一个官方的高权限插件——Perfetto UI引起的：这个插件是Google官方引入的，主要功能是和web app交互并读取记录Chromium执行记录（execution trace），为了实现这个功能，插件被（Chromium内部直接硬编码）允许通过命令来访问Tracing CDP domain这个敏感的域，而对应的策略是允许Perfetto UI插件访问browser这个超级对象的target ID，那么攻击者可以利用第四种攻击的模仿策略，造出来一个模仿Perfetto UI插件ID的恶意插件，实现攻击。而且尽管在这种情况下，还是有一定的限制，但是作者指出了绕过限制的条件，这部分由于比较敏感，可能被黑产利用，我们不再详述，免得被定罪为传播危险知识！
总之，这篇论文介绍了很多实用危险的黑产安全知识，据说朝鲜黑客在2022年的攻击中也用了一些类似的技术，今天的阅读推荐，就建议大家阅后即焚吧！
论文：https://arxiv.org/pdf/2305.11506.pdf
配套代码：https://github.com/josemmo/chrowned
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-11-27 Chrowned!
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论