一款被投毒的 VS Code 扩展偷走了 GitHub 自家 3,800 个内部仓库

GitHub 正在调查其内部仓库被未授权访问的事件，并确认攻击者已经从其中约 3,800 个仓库里成功外泄了数据。入侵入口是一名员工安装的一款被投毒的 Visual Studio Code 扩展，攻击者由此获得了该机器的立足点，再从这台机器上伸向了本应留在公司自家围墙之内的内部代码。

GitHub 现在划出的那条边界，也就是内部仓库与面向客户的平台之间那条线，是这起事件停留在受控事故、还是演变成全球供应链危机之间唯一的隔挡。GitHub 上聚集着约一亿名开发者，现代互联网赖以运转的开源代码也有相当一部分长在这里。公司说的「内部」，指的是它自己的平台代码、它的工具、它的运营配置，也就是 GitHub 用来构建并运行自身的那批材料。客户的组织、企业以及客户存放在 GitHub 上的公开和私有仓库，按公司自己的说法,处在这次入侵的影响半径之外。

这条区分线在公司发到官方 X 账号上的那则声明里承担了相当大的分量。「虽然我们目前没有任何证据显示存放在 GitHub 内部仓库之外的客户信息受到影响」,声明写道,「我们仍在密切监控基础设施,留意是否存在后续动作」。措辞很准确,而入侵公告中的准确措辞,通常意味着调查仍在推进。「没有受影响的证据」并不等于「没有受影响」。大型平台的事件常常随着取证追上攻击者的活动而越查越大,内部系统与面向客户的系统之间那条线,也极少是一道干净的物理墙。它是一组访问控制、凭据和服务账号的集合,需要一个一个地推敲。

这段故事里最该让每个开发者警醒的部分,是攻击的机制。Visual Studio Code 是地球上占比最高的代码编辑器,几乎进了每一家大型工程组织。它的扩展市场建立在社区信任之上:任何人都可以发布,大多数工程师装插件的随意程度,和在浏览器里加一个书签差不多。一款经由这个通道分发、在开发者机器上跑起来的被投毒扩展,会把这名开发者会话能触达的一切都交给攻击者:仓库、令牌、包注册中心、内部服务。这一次具体用的是哪款扩展,公司还没有公开,但这套模式并不新。开发者工具领域的人气扩展 Nx Console 也遭遇过类似的入侵。

自称 TeamPCP 的团伙认领了这次入侵,并把数据集挂到地下论坛上,底价五万美元起售。他们使用的口径——「这不是赎金」——本身就是一个信号。他们没有打算直接勒索 GitHub。他们是在把偷来的内部源码,当成其他犯罪分子处理信用卡转储那样的商品,卖给有买家的市场。最终拿到这份 3,800 个仓库归档的人,会从中梳出嵌在代码里的凭据、硬编码的秘密、有助于攻击 GitHub 自身基础设施的细节,以及一切可以用来攻破下游目标的线索。同一团伙还被关联到打中 PyPI 上 durabletask 包的 Mini Shai-Hulud 蠕虫,这恰好把这则报道的真正底色勾出来:针对软件开发供应链的攻击,已经从理论场景变成日常手艺。

按 GitHub 自己的描述,事件控制的反应很快。被入侵的设备被隔离。恶意扩展被下架。公司表示已经轮换了关键密钥,并优先处理影响最大的凭据;一旦调查范围扩大,就会通过既有的事件响应通道通知受影响的客户。这家微软子公司没有公开被入侵设备的 GitHub 员工身份,也没有点出扩展的名字,更没有给出攻击者在被发现前持续访问了多长时间。这些细节通常要等到首次披露之后数周才出现的更长的事后报告里。

对行业其余的人而言,实操层面的结论比威胁情报的包装要简单得多。任何工程组织都距离同样的事件只差一次不上心的扩展安装。任何在某条论坛帖子里看到一款 VS Code 扩展推荐就装上去的人,跟落在 GitHub 这位员工身上的风险是一模一样的。真正起作用的防御措施已经讲得很清楚,只是大家落实得不齐: 把扩展安装限制在经审核的允许清单内,把开发者工作站和生产凭据隔开,以较高频率轮换密钥。这次事件会把它们推上很多原本一拖再拖的公司的优先级排序顶端。

GitHub 没有给出公开复盘的时间表。这种规模的平台上发生的这种量级的调查,通常需要几周才能看清楚全貌,后续更新会经由公司的官方渠道按部就班放出。下一步值得盯的是: 这份 3,800 个仓库的归档究竟会不会出现在挂牌列表里;以及地下市场拿到目录、看上几天之后,价格底线会朝哪个方向移动。