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

查找币:余老师 | 漏洞披露 | 2026-09-08 18:00 | 2 次浏览 | 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 查询 - 代币价格监控 - 日志记录 **历史恶意版本中的四类危险能力均已消失**： 1. 凭据采集 2. 远程载荷下载 3. 子进程执行 4. 远程 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 扩展供应链投毒风险，查找币安全团队建议： 1. **审查完整版本历史**：不要仅查看最新版本，应回溯历史版本中的恶意行为模式 2. **交叉验证 publisher 变更**：当扩展更换发布者时，需核查新旧 publisher 间的工程继承关系 3. **对比源码与构建产物**：检查 GitHub 源码与发布制品之间是否存在差异 4. **关注黑名单后的版本更新**：对被标记扩展的后续版本保持同等警惕 5. **使用运行时监控**：在沙箱环境中运行扩展，监控网络请求、文件访问和进程行为 ## 结论 Solidity Pro 的案例表明，IDE 扩展供应链攻击正在向更隐蔽的方向演进。攻击者不再简单地在每个版本中都植入恶意代码，而是采取“定向投毒—快速洗白”的策略：在特定版本中植入恶意功能，一旦被曝光便迅速发布“净化版”维持表面合规，同时保留恶意源码以备后续重新启用。对于 Web3 开发者而言，任何开发工具都应被视为潜在的攻击面。保持对扩展供应链的持续监控，而非一次性风险评估，是抵御此类威胁的关键。 --- **本文由查找币安全团队整理发布** *参考链接：* - [1] Yeeth Security: Solidity Pro WhiteCobra C2 to Telegram 分析报告

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

查找币安全研究院

主题延伸阅读