坐火车太无聊，我溜入微软 VS Code官方GitHub仓库，但没敢发动供应链攻击

VS Code 的issue 管理函数中存在一个漏洞，缺乏认证检查将使研究员获得 push 访问权限并写入仓库。这名研究员负责任地报告了该漏洞并获得赏金，但并未透露赏金数额。

研究员 RyotaK 在乘坐火车时从 VS Code 的持续集成 (CI) 脚本中发现了一个漏洞，可使其进入微软 VS Code 的 GitHub 官方仓库和 commit 文件。他写道，“在火车上时非常无聊所以决定读一下 VS Code 代码。不久后我注意到 VS Code 为 CI 脚本设立了一个单独的仓库，名为 vscode-github-triage-actions。于是我决定读一读。”

不久之后，他注意到该脚本中存在一行有意思的代码，可被用于执行代码攻击：

RyotaK 通过邮件访谈指出，“当然，存在一个命令注入漏洞，不过要求控制 ‘commit’ 变量或 ‘release’ 变量。”他之后意识到这个 commit 变量可被攻击者控制，原因有二：

1、closedWith 命令中缺乏认证检查（即并未检查用户是否有权将 commit 哈希和 issue 相关联），以及

2、有缺陷的正则表达式用于验证结束注释中指定的 closedWith 命令。

closedWith 命令用于在结束 commit 前关联 commit 哈希和该 issue。

然而，有缺陷的正则表达式（如下所示）用于验证结束注释且 CI 脚本中缺乏认证检查意味着，任何用户即可关联 commit 和 issue，并在 closedWith 值中注入代码。

由于VS Code 易受攻击的 CI 工作流一天运行一次，时间是在午夜左右，因此RyotaK 提前仔细策划了 PoC exploit，以便在晚上不会出现任何危险的错误。

为此，RyotaK 浏览了 GitHub Actions 代码文件，了解持续集成和持续交付（CI/CD）工作流。他指出，“幸运的是，GitHub Actions 的工作流文件发布在 GitHub 上，因此我了解了 GitHub Actions 中的内部运作方式。由于 actions/checkout 是在使用易受攻击的工作流前一步执行的，因此GitHub 令牌具有对该仓库的写权限。于是我计划使用该令牌。”通过将这个基础的 PoC exploit 注入在午夜时分运行的 VS Code 的 CI 脚本中，研究员获得了一个反向 shell。

此外，RyotaK 获得 VS Code 仓库的 GitHub 授权令牌，使其能够对该仓库具有写权限。最终，获得该令牌后，RyotaK 在该仓库中发布了一个 PoC commit。

虽然该仓库的master branch 具有基于账户的 branch 保护措施，无法通过 GitHub Actions 令牌绕过，因此可以使用该令牌将文件推送到 release branch。

值得注意的是，RyotaK 是根据微软漏洞奖励计划提供的“安全港”指南执行 PoC exploit的。他提到，“微软允许通过安全港诊断漏洞情况。本文描述了基于该安全港发现/报告漏洞的过程，但并非推荐大家实施越权漏洞诊断。”

之后，RyotaK 获得具体数额未透露的赏金。

能使攻击者入侵安全的软件代码库的缺陷或可为进一步执行复杂的软件供应链攻击铺路。

RyotaK 的这一惊人发现是在 SolarWinds 供应链攻击事件已成为各大新闻头条的情况下披露的。RyotaK 指出，自己在高阶威胁行动者实施利用之前负责任地发现该漏洞并报告给微软。攻击者本科将恶意代码上传到 VS Code 仓库中。

在目标供应链攻击中损坏源代码编辑器和 IDE 可为用户、开发人员和客户造成灾难性后果，这些人后续可能会接收到使用受污染 IDE 构建的应用程序。最近，安全研究团队发现由于联合国域名的 .git 目录保护不当，Git 凭据遭暴露，使得他们能够克隆联合国环境计划署的整个 Git 仓库并最终访问超过10万名员工的记录。

建议用户加固 CI/CD 工具的安全，积极审计脚本中是否存在可遭攻击者利用的缺陷，从而避免遭受软件供应链攻击。

博客原文地址：

https://blog.ryotak.me/post/vscode-write-access/