DSH 插件市场供应链真实投毒案例解析

原创

i3eg1nner
i3eg1nner

SecureNexusLab

2026年11月2日 10:34
北京

去阅读

awesome-dsh-plugin 社区插件市场中 npm 包 dsh-plugin-blender-3d 在迭代两个余月后，于 2026-10-26 发布的 0.2.1 版本中植入 postinstall 钩子，执行下载自 S3 的二阶段载荷：普通用户权限下释放 XMRig 挖矿程序，root 或免密 sudo 环境下尝试运行持久化 agent。同日同一发布者另一包 @walknpm/[email protected] 携带字节级相同的脚本，表明投毒已流水线化。由于市场索引的版本机制完全跟随 npm latest，三条默认安装路径中有两条解析至恶意版本，仅备选 tarball 命令指向干净版本；该版本下载量约 1,231 次。归因倾向于 npm 发布凭据泄露。事后威胁情报显示，这并非孤立事件，而是自 9 月起针对 dsh 前缀包的持续投毒浪潮中的一起（见 0x10）。

0x00 插件市场

DSH 插件实为 npm 包：安装经 pnpm 写入 profile 依赖树，postinstall 以当前用户权限执行；官方文档明确 Host 插件在 DSH 进程内运行、位于 workspace 沙箱之外，具备文件、凭据与网络访问能力。

awesome-dsh-plugin 为社区精选清单，解决 3,700+ 包规模下的发现问题，本质是以中心化信任置换分布式搜索成本；收录存在一定的安全审计，但对npm版本不存在限制。当用户在插件市场中安装该插件时默认安装最新版

0x01 异常起点

awesome-dsh-plugin 最新版 manifest 中的 postinstall: sh scripts/miner.sh 构成异常信号：Blender 建模插件不应在安装期执行 shell 脚本。

0x02 版本溯源

对照 npm 发布记录与 tarball 逐文件比对：

ounter(lineounter(lineounter(lineounter(line0.1.0  2026-08-24  无安装钩子0.1.1  2026-08-25  无安装钩子0.2.0  2026-08-25  无安装钩子0.2.1  2026-10-26  新增 postinstall ← 异常点

17 个文件中 15 个逐字节一致，差异仅为 package.json 一行与新增的 3,514 字节脚本。钩子为两个月后突然引入，且刻意维持其余字节不变

npm 元数据

版本 diff 与脚本哈希

0x03 载荷分析

脚本自述 \"rig2 stealth miner — background, idempotent, quiet. Runs on npm postinstall.\"，行为分三层。

「下载」：经预签名 URL 从 S3 拉取伪装为 CloudFormation 模板缓存的 gz 载荷至 /tmp/.smh 并解压。

「分支执行」：root 直接运行 agent；免密 sudo 环境提权运行；普通用户自内置 base64 tar 释放 XMRig，配置矿池 networkservicesupp.flashhub.net:8443（TLS，rx/0），线程数 min(nproc, 4)。

「隐匿」：锁文件保证单实例，进程随机更名为 edid-mon、irqstatsd 等系统组件样式，载荷隐藏于 /tmp/.sm*。

样本本身至此分析完毕；后续问题在于该包如何到达用户主机，此问题要求先行厘清 DSH 插件的分发结构。

脚本关键片段（已脱敏）

0x04 分发结构

0x05 版本解析矛盾

清单 YAML 载明 v0.2.0，实际安装却为 0.2.1，矛盾指向被误解的机制。追溯索引生成过程：清单 nightly 任务探测 npm，将 dist-tags.latest 写入 npm-map 并生成线上 index.json——索引版本完全跟随 npm latest，且为不回写仓库的构建产物，与 YAML 分属两条数据流。故 tarball 字段仅为备选分发产物而非版本锁。此机制意味着：攻击者无需触碰清单，仅发布新版本，中心化源即于次日将恶意版本推送至全部默认安装路径。

页面安装命令

包卡片与下载量

0x06 同源关联

0.2.1 发布 26 秒后，同一 npm 账号发布 @walknpm/[email protected]，携带字节级相同脚本（SHA-256 均为 50df0597...c5050118），共用同一 S3 与矿池基础设施。同一脚本、26 秒间隔、跨包复制，排除独立失误，确认为可复用的投毒流水线；两包须一并处置。

0x07 归因边界

可用的证据仅为行为模式：其一，账号干净迭代两个余月后一次性植入完整链路；其二，26 秒跨包复制指向脚本化批量发布。据此推断「更可能为 npm 发布凭据泄露后遭第三方接管」，而非维护者自始投毒。此为推断而非结论，确认需 npm 侧发布日志与 2FA 记录。两种归因下的防护对策一致：不以发布者历史清白为信任依据，仅验证版本的实际行动。

0x08 处置结果

报告以 issue 形式提交至清单仓库，维护者对全部证据独立复核——npm 元数据、版本差异、脚本哈希——结论一致，随即处置。

「清单侧」：条目 walkzzz__dsh-plugin-blender-3d.yml 已删除，共享的 stars/screenshots 等数据无残留；build-site 重新部署后，线上 index.json 与 catalog.json 均不再包含该包（本文复核确认），DSH Discover 的安装路径就此关闭。

「npm 侧」：0.2.1 已从版本列表移除，latest 回退至干净的 0.2.0（npm view 复核确认，现存版本仅 0.1.0 / 0.1.1 / 0.2.0）。此时 npm i dsh-plugin-blender-3d 解析到的已是干净版本；但 10-26 至下架窗口期内经默认路径安装过的主机，仍需自行排查。

「机制缺口」：维护者确认现有收录 gate 仅检查 dsh.bundle 声明、仓库存活与描述，从未检查 npm 发布版本的 install scripts——这正是本次投毒穿透发现层的原因。将\"npm latest 的 preinstall/postinstall/install 非空即拦截或标红\"固化为自动检查已列入维护者待办。

0x09 同构印证：裸包名碰撞事件

前文的风险均由\"按包名安装\"这一解析行为衍生，一个自然的追问是：除版本跟随外，裸包名本身是否已造成过实际冲突？社区内的另一起独立事件给出了印证。

开发者 zhujiuyi 的配额查询插件 dsh-balance-meter 在准备发布时发现：npm 上同名包已于 2026-08-13 被第三方注册（maintainer ghost1118，repository 指向 zhu1090093659/dsh-web-ui），且社区清单中同时存在另一位开发者 Ghost011118 的同名插件条目——两个 dsh-balance-meter.yml 指向不同的 GitHub 仓库。此时若用户执行 dsh plugin add dsh-balance-meter，解析到的是 npm 名字持有者的包，与清单条目指向的仓库无任何绑定关系。经核查，该第三方包本身无安装钩子、无可疑行为——「这是一次幸运的碰撞，而非投毒」；但结构缺口与 blender-3d 事件完全同源：安装解析只认 npm 包名，既不校验名字归属，也不绑定清单所指仓库。若名字持有者发布恶意版本，后果与前文无异。

作者的处置直接而有效：commit bb6edb838（2026-10-14，与 @deepseek-ai/[email protected] 发布同日）将包名与 Cordis 配置键全量重构为带作用域命名，次日 commit 27b8eb1f 定格为 @zhujiuyi/dsh-balance（避免 @dsh 前缀暗示官方），并于 2026-10-19 注册发布；README 安装节明示\"别装 dsh-balance-meter（不带作用域），那个名字在 npm 上属于别人\"，并同步提供 tarball 与 git 直装路径。作用域命名将\"名字所有权\"嵌入包名本身，从根上消解了碰撞面——这正是无作用域裸包名应吸取的教训。

两起事件合观，同一结构缺口的两个侧面均已显形：blender-3d 演示了\"版本不受约束\"的后果，balance-meter 演示了\"名字不受绑定\"的风险。这种插件层供应链风险需要注意。

0x10 浪潮印证：这不是孤立事件

事后核对威胁情报（radar.offseq.com，检索 dsh-）得到一个必须修订前文叙事的事实：blender-3d 并非孤例，而是一波「针对 dsh 前缀 npm 包的持续投毒浪潮」中的一起。经逐包 npm 复核：

新时代的供应链投毒还有很多种可能，攻防对抗也不会停下