GlassWorm恶意软件卷土重来：揭示开源供应链安全的根本弱点

在宣称被根除仅数周后，GlassWorm 再度入侵开发者代码，其利用的仍是此前相同的 Unicode 隐匿技术及区块链 C2 机制。这款曾被认为已清除的普遍性、高规避性恶意软件，已重新渗透进开发环境。

就在开源 OpenVSX 项目宣布 GlassWorm 被“完全遏制并清除”两周多一点之后，这款自传播蠕虫再次瞄准了 Visual Studio Code 扩展——这些用于增强开源 VS Code 功能的插件，提供新功能、调试器及其他改善开发者工作流程的工具。Koi 的研究人员发现了新一轮感染浪潮，并识别出另外三个受感染的扩展。

GlassWorm 于去年 10 月首次被发现，它利用不可显示的 Unicode 字符，使得恶意代码在 VS Code 环境的代码编辑器中不可见。如今，该蠕虫更进一步，已蔓延至 GitHub 代码库，通过在人工智能生成的提交中隐藏负载，伪装成看似合法的代码更改。

该恶意软件由一个位于俄罗斯的攻击组织投放，正在全球范围内感染受害者，包括美国、欧洲、亚洲、南美洲的众多个人开发者与企业，以及中东的一个“主要政府实体”。

Koi 研究人员指出：“攻击者使用的基础设施依旧相同，并且仍在全面运作。”他们补充道：“这不再仅仅是关于受感染的扩展。这关乎真实的受害者、面临风险的关键基础设施，以及一个正在兑现我们警告的蠕虫：它正通过开发者生态系统进行传播。”

研究人员指出，所有这三个 GlassWorm 扩展的代码在编辑器中对人眼“实质上仍然不可见”。它们以不可打印的 Unicode 字符编码，看似空白，实则作为 JavaScript 执行。

攻击者在 Solana 区块链上发布了新交易，其中概述了用于分发恶意负载的更新远程命令与控制端点。研究人员指出，尽管交易是新的，但服务器保持不变。

他们写道：“这凸显了基于区块链的 C2 基础设施的韧性——即使负载服务器被关闭，攻击者也能以极低的成本发布新交易，所有受感染的机器都会自动获取新位置。”

开发者还报告称，他们的 GitHub 代码库在正常的开发活动中，遭到了看似“项目特定”的人工智能生成代码提交的渗透。这些提交包含了与 VS Code 攻击中相同的隐匿 Unicode 恶意软件。此外，攻击者还在窃取 GitHub 凭证，并利用蠕虫技术将提交推送到其他代码库。

威胁情报公司 SOCRadar 的首席信息安全官 Ensar Şeker 指出：“看到 GlassWorm 如此迅速地卷土重来，虽然令人深感忧虑，但并不出乎意料。”

他强调，攻击者在供应链蠕虫被清除后重新浮出水面的方式尤其危险。“当攻击者控制了传播机制并利用多个市场节点时，仅仅删除部分扩展是不够的。”

值得注意的是，攻击者似乎对其自身基础设施的管理变得松懈，留下了一个暴露的端点。Koi 的研究人员利用此端点获取并展示了部分数据和受害者名单。他们还从攻击者的键盘记录器数据中发现，对方使用开源 C2 框架浏览器扩展 RedExt，并成功获取了攻击者在多个消息平台和加密货币交易所使用的用户 ID。

Beauceron Security 的 David Shipley 认为，这些漏洞源于技术、流程和市场驱动因素。他指出，OpenVSX 社区似乎缺乏资源来手动审查提交的代码，而是依赖自动化工具和发布者协议。

Shipley 表示，这个问题凸显了开源市场模式的“根本性弱点”：免费或低成本的运营模式意味着没有足够的资源，也缺乏一致的激励来应用应对当前威胁环境所需的安全级别。

“简而言之，当你没有因手动代码审查而获得足够报酬时，你就不会去做，”他指出。“当你没有能够识破精妙攻击手段的‘思考者’进行检查时，精妙的攻击就会乘虚而入。”

Shipley 建议，安全团队应重新评估 OpenVSX 的价值主张。如果他们愿意手动审查开源注册表中的代码并设置相关警报，则可以降低风险。否则，应考虑从审查控制更严格的精选来源获取代码。

Shipley 说：“软件供应链和开源领域现在是全球网络安全‘捉鬼游戏’中的‘鬼’，并且将在未来很长一段时间内持续扮演这一角色。”在经济重新平衡以支持更多安全投入之前，或者该模式在“不安全的重压下崩溃”之前，这种情况预计会持续。

他表示：“不存在能够 100% 可靠地阻止这类威胁的自动化 AI ‘魔法仙尘’。在攻击者意识到这是一种非常可行的攻击传播方式之前，自动扫描或许尚可应付。”

SOCRadar 的 Şeker 对此表示同意，他认为核心问题不在于恶意软件本身，而在于供应链威胁的“系统性转变”。

他说：“软件供应链现在不仅包括依赖项，还包括其工具链、市场以及整个开发生态系统。你必须将开发者的基础设施视同生产基础设施一样进行保护。”

开发者与安全团队应关注关键信号：包含不可见 Unicode 字符的恶意扩展的上传；利用区块链备忘录和谷歌日历等合法服务作为隐蔽 C2 通道以逃避检测；以及受感染的开发者机器被用作代理节点以发起进一步感染。

Şeker 建议，企业应减少攻击面，仅允许来自受信任发布者的组件，尽可能禁用自动更新，并维护已安装扩展的清单。同时，应监控来自工作站的异常出站连接、针对开发者级别令牌的凭据收集活动，以及代理或 VNC 服务器的创建。此外，安全团队应将应用于第三方库的“同等严格标准”应用于自身的开发者工具链。

Şeker 表示：“当恶意行为者将你的 IDE 视为攻击跳板时，你的供应链暴露面就会急剧扩大。”

他最终警告道：“这些并非典型的供应链攻击，你无法通过修补单个库就万事大吉。它们被设计成能够持久潜伏。”