最近，npm 生态接连发生了两件值得关注的事情。
一边，是针对阿里巴巴开发环境的 npm 木马攻击；另一边，是 npm 开始强化软件包发布审核机制。
npm 供应链安全正在变得越来越重要。
阿里遭遇定向 npm 木马攻击
安全公司 Socket 最近披露了一起针对阿里巴巴开发环境的 npm 供应链攻击。
攻击者注册了一批与阿里内部私有包名称高度相似的软件包，例如：
| 公共 npm 包 |
阿里私有包 |
lib-mtop |
@ali/lib-mtop |
aone-kit |
@ali/aone-kit |
aone-sandbox |
@ali/aone-sandbox |
这些包并不是简单地把所有恶意代码塞进一个模块里，而是将攻击逻辑拆散在多个依赖和远程配置中。
部分模块单独看起来甚至具备正常功能，例如 解析配置、执行表达式 等，但当多个组件组合起来后，就会形成 完整 的攻击链。
其中一个关键环节是 Node.js vm 沙箱逃逸。
恶意代码可以通过宿主对象获取 Function 构造器，进一步访问 Node.js 的 process 对象，并恢复模块加载能力。
最终，攻击链会下载并运行 RAT，也就是 远程访问木马。
该 RAT 具备 远程命令执行、文件上传下载、信息收集 和 持久化 等能力，同时还针对 Windows、macOS 和 Linux 分别准备了不同的攻击方式。
Socket 还发现，这套攻击工具具备与钉钉相关的横向移动能力。
npm 新增人工审核机制
与此同时，npm 也开始调整软件包发布阶段的安全机制。
其中一个重要变化是 Publish-time Malware Scanning。
新的 npm 软件包版本在正式发布之前，会先经过恶意软件扫描。
根据检测结果，版本可能会：
- 正常发布；
- 因存在风险被暂时拦截；
- 进入进一步人工审核；
- 被确认恶意后直接阻止发布。
更准确地说是：
所有新版本都会经过自动恶意软件检测，其中可疑版本才可能进入人工审核。
除此之外，npm 还推出了 Staged Publishing（分阶段发布）。
过去执行：
npm publish
版本就会直接公开。
现在维护者可以先将版本上传到暂存状态，对最终 tarball 和构建产物进行检查，再通过 2FA 人工确认后正式发布。
也就是说，发布流程可以从：上传 → 公开
变成：上传 → 检查 → 人工确认 → 公开
需要注意的是，这里的人工确认由软件包维护者完成，并不是 npm 官方逐个审核所有软件包。
写在最后
这两件事其实反映了同一个趋势。
一方面，npm 供应链攻击正在变得更加复杂。
攻击者不再只是发布一个明显的恶意包，而是开始模仿企业内部依赖、拆分攻击代码，并针对具体开发环境设计完整攻击链。
另一方面，npm 也开始把安全检测向发布阶段前移，通过自动恶意软件扫描、可疑包人工审核和分阶段发布等机制，提高恶意版本上线的门槛。
这些措施无法彻底解决供应链攻击，但至少说明 npm 已经开始从“恶意包上线后再处理”，逐步转向“发布前先检查”。
对于依赖数量庞大的 JavaScript 生态来说，这一步迟早都得走。相关讨论也可以在 云栈社区 继续展开。
相关链接：
发表于 1 小时前
|
查看: 5|
回复: 0
