供应链投毒预警：Solidity Pro 扩展的“洗白”手法分析

查找币:余老师 | 漏洞披露 | 2026-09-08 18:00 | 39 次浏览 | 0 条回复

查找币漏洞披露安全研究 Web3安全区块链安全

一个曾经携带恶意代码的 IDE 扩展，在最新版本中却呈现出完全“干净”的状态。这是开发者工具的自我修复，还是攻击者精心设计的规避策略？

事件背景

Solidity Pro 是一款面向 Solidity/Web3 开发者的 VS Code 扩展，主打 Gas 查询、代币价格、代码片段和编译提示等开发辅助功能。其 GitHub 仓库还曾宣传具备 AI Audit、Security Scanner 等安全能力，以增强开发者信任。

在公开活动中，该扩展先后使用过两个 publisher（发布者身份）：

helper-beeps.solidity-pro
web3devtoolsx.solidity-pro

尽管发布身份发生变化，后续构建产物中仍保留旧 publisher、仓库地址和版权信息，表明两者之间存在直接的工程继承关系。

关键时间节点：2026 年 8 月 6 日至 7 日，这两个 Extension ID 先后被 Open VSX 加入恶意扩展控制列表。

核心疑点：4.0.0 版本的“净化”现象

按照常规逻辑，被列入黑名单后继续沿版本向后检查，应该仍能看到相关恶意能力。但分析团队获取的 Solidity Pro 4.0.0（publisher: web3devtoolsx）却呈现出完全不同的结果：

最终 bundle 中仅剩：

Gas 查询
代币价格监控
日志记录

历史恶意版本中的四类危险能力均已消失：

凭据采集
远程载荷下载
子进程执行
远程 VSIX 更新模块

这引出一个关键问题：一个已有明确恶意历史的插件，为什么在后续版本中又变得“干净”？

深入分析：Clean Commit 的双面性

分析团队从 4.0.0 向前回溯 Solidity Pro 的版本与发布身份变化，发现了一个值得警惕的现象。

VSIX 包内部

本地重建的 4.0.0 包最终 bundle 主要包含 ApiClient、GasTracker、PriceMonitor 和 Logger，网络访问集中在 Etherscan 与 CoinGecko。扩展在 onStartupFinished 或包含 Solidity 文件的工作区激活后，仅启动 Gas tracker、Price monitor 和 logger，并注册三个公开命令。compile 命令仅显示一条 Hardhat/Foundry 提示，不实际调用编译器。

在已检查文件和静态可达路径中，未发现任何恶意能力。

GitHub 仓库中的另一面

4.0.0 包本身未携带源码，分析团队进一步向 GitHub 回溯其公开工程。在仓库中发现一个关键提交——commit 95dce4f，提交信息为 "Clean release"，其 out/extension.js 与 4.0.0 bundle 完全一致（均为 10,633 字节，SHA-256 匹配）。

然而，该 commit 的 src/ 目录却呈现出截然不同的景象：

src/telemetry/Web3Analytics.ts 仍然存在：文件头明确写着 "Sends install ping immediately, then scans for secrets"，内部包含 BIP39 词表、钱包凭据识别、WORKERS 外传配置和大规模文件搜集上限
src/services/AutoUpdater.ts 同样保留：定义了 30 分钟周期的版本检查与远程 VSIX 安装逻辑

这意味着：编译产物（out/）是干净的，但源代码（src/）仍保留完整恶意模块。

威胁分析：检测盲区与供应链风险

这一案例揭示了 IDE 扩展供应链安全中的几个关键盲区：

1. 仅检查当前版本的局限

仅根据当前版本判断 IDE 扩展风险可能产生严重误判。攻击者完全可以在被列入黑名单后发布“净化版”以维持表面合规，同时保留恶意源码随时重新启用。

2. Publisher 迁移的烟雾弹

通过更换 publisher 身份，攻击者可以规避基于单一发布者的信誉追踪。旧 publisher 被拉黑后，新 publisher 仍可继续发布看似独立的扩展。

3. 构建产物与源码分离

恶意代码可能只存在于源码层面，构建产物经过清理后再发布。这使得基于制品（artifact）的检测难以发现异常。

4. 时间线交叉验证的必要性

将扩展的发布历史、GitHub 提交记录、黑名单时间线进行交叉比对，才能识别出“洗白”行为。

防护建议

针对此类 IDE 扩展供应链投毒风险，查找币安全团队建议：

审查完整版本历史：不要仅查看最新版本，应回溯历史版本中的恶意行为模式
交叉验证 publisher 变更：当扩展更换发布者时，需核查新旧 publisher 间的工程继承关系
对比源码与构建产物：检查 GitHub 源码与发布制品之间是否存在差异
关注黑名单后的版本更新：对被标记扩展的后续版本保持同等警惕
使用运行时监控：在沙箱环境中运行扩展，监控网络请求、文件访问和进程行为

结论

Solidity Pro 的案例表明，IDE 扩展供应链攻击正在向更隐蔽的方向演进。攻击者不再简单地在每个版本中都植入恶意代码，而是采取“定向投毒—快速洗白”的策略：在特定版本中植入恶意功能，一旦被曝光便迅速发布“净化版”维持表面合规，同时保留恶意源码以备后续重新启用。

对于 Web3 开发者而言，任何开发工具都应被视为潜在的攻击面。保持对扩展供应链的持续监控，而非一次性风险评估，是抵御此类威胁的关键。

本文由查找币安全团队整理发布

参考链接：

[1] Yeeth Security: Solidity Pro WhiteCobra C2 to Telegram 分析报告