在过去的周末,我抽出几个小时来研究Justin Steven在 2021 年 8 月发现的这个Visual Studio Code .ipynb Jupyter Notebook 漏洞的利用情况。
.ipynb
Justin 发现了一个影响 VSCode 对 Jupyter Notebook ( ) 文件的内置支持的跨站点脚本 (XSS) 漏洞。
他的分析详细说明了这个问题,并展示了一个概念证明,它从磁盘读取任意文件,然后将其内容泄露到远程服务器,但这并不是一个完整的 RCE 漏洞利用。
我找不到一种方法来利用这个 XSS 原语来实现任意代码执行,但是更熟练的 Electron 开发人员可能能够做到这一点。[…]
鉴于我们专注于 ElectronJs(和许多其他网络技术),我决定研究潜在的利用场所。
作为第一步,我查看了应用程序的整体设计,以便识别BrowserWindow/BrowserView/Webview
VScode 使用的每个配置。在ElectroNG的帮助下,可以观察到应用程序使用单个BrowserWindow
with nodeIntegration:on
。
这使用类似于协议BrowserWindow
的协议加载内容。不幸的是,我们的注入发生在嵌套的沙盒 iframe 中,如下图所示:vscode-filefile
特别是,我们的sandbox
iframe 是使用以下属性创建的:
默认情况下,sandbox
使浏览器将 iframe 视为来自另一个来源,即使它src
指向同一个站点。由于该allow-same-origin
属性,此限制被解除。只要 webview 中加载的内容也托管在本地文件系统(在 app 文件夹中),我们就可以访问该top
窗口。有了它,我们可以简单地使用类似的东西执行代码top.require('child_process').exec('open /System/Applications/Calculator.app');
那么,我们如何将我们的任意 HTML/JS 内容放在应用程序安装文件夹中呢?
或者,我们可以引用该文件夹之外的资源吗?
答案来自我在最新的 Black Hat USA 2022 简报中观看的一个演示文稿。在利用CVE-2021-43908时,TheGrandPew和s1r1us使用路径遍历来加载 VSCode 安装路径之外的任意文件。
vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F/somefile.html
与他们的利用类似,我们可以尝试利用 apostMessage
的回复来泄露当前用户目录的路径。实际上,我们的有效负载可以与触发 XSS 的 Jupyter Notebook 文件一起放置在恶意存储库中。
经过几个小时的反复试验,我发现我们可以通过在事件img
期间强制执行来获取触发 XSS 的标签的引用onload
。
有了这个,所有的成分都准备好了,我终于可以组装最终的漏洞利用了。
为了在文件中传递这个有效载荷,.ipynb
我们仍然需要克服最后一个限制:当前的实现会导致格式错误的 JSON。注入发生在 JSON 文件(双引号)中,我们的 Javascript 有效负载包含带引号的字符串以及用作提取路径的正则表达式的分隔符的双引号。
经过一番修改,最简单的解决方案是使用反引号 ` 字符而不是所有 JS 字符串的引号。
最终pocimg.ipynb
文件如下所示:
通过使用该文件打开一个恶意存储库,我们最终可以触发我们的代码执行。
http://mpvideo.qpic.cn/0bc3meakeaaaiiajrcc3orrvayodujqqbiqa.f10002.mp4?dis_k=336f6a7707b8d77b31691b70e975e86b&dis_t=1672736327&play_scene=10400&vid=wxv_2639572356012670978&format_id=10002&support_redirect=0&mmversion=false 内置的 Jupyter Notebook 扩展选择退出 Visual Studio Code 1.57 中引入的工作区信任功能提供的保护,因此不需要进一步的用户交互。作为记录,此问题已在 VScode 1.59.1 中修复,Microsoft 为其分配了CVE-2021-26437。
原文来源: