Node-ipc 热门包作者投毒“社死‘’，谁来保护开源软件供应链安全？

Original 奇安信开源卫士代码卫士

收录于合集

聚焦源代码安全，网罗国内外最新资讯！

专栏·供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

Node-ipc 简介

Node-ipc 是用于本地和远程间通信的 nodejs 模块，支持Linux、Mac 和 Windows 系统。它还支持底层unix和UDP的windows 套接字，并保护TLS 和TCP 套接字的安全。它是解决Node.js 中复杂多进程 Neutral Networking 的很好的解决方案。截止 9.2.2版本，该模块使用 peacenotwar 模块。该模块的周下载量超过109万次。

事件概述

但今天，多个国家的开发人员在使用时发现无法拉取 vue-cli 依赖node-ipc 的 peacenotwar 包。如果用户使用的是俄罗斯的IP地址，则所有文件会被爱心图标替换，然后未经用户同意，在桌面和OneDrive文件夹写入“WITH-LOVE-FROM-AMERICA.txt” 。peacenotware 模块的作者RIAEvangelist 被指投毒供应链。

恶意代码如下：

‍

为此，Vue 项目维护人员@sodatea澄清指出：

（1）Vue CLI 依赖于 node-ipc v9.x版本。

（2）Node-ipc 9.2.2 增加了peacenotwar模块，该模块会在未经用户同意的情况下，将“WITH-LOVE-FROM-AMERICA.txt” 写入用户Desktop 和 OneDrive 文件夹。

（3）目前发布 4.5.16和5.0.3版本锁定该依赖版本。

（4）受影响用户是在2022-03-15T05:40:26.758Z至2022-03-15T13:17:57.076Z期间创建项目的用户，或者在这个时间段更新了项目依赖的用户。

（5）删除俄罗斯和白俄罗斯 IP 地址文件的恶意代码并不包含在增加了 peacenotwar 模块的 9.2.2版本中。

@sodatea 表示，解决该问题的最佳方法是npm注册表直接下架这些恶意代码，并表示npmmirror.com 已采取措施将有问题的版本重定向到最新的安全版本 cnpm/bug-versions#181。

Node-ipc 作者“社死”现场还原

用户@MidSpike 指出，深挖 node-ipc 仓库中最新commit，反混淆代码后发现，如果主机机器的ip地址是俄罗斯或白俄罗斯，则用户文件被覆写。

用户@GalvinGao评论称，随后该文件似乎被删除，且受影响的v10.1.3版本被删除或被下线，目前已经不存在于npm 上。他认为，这种行为非常可以。不管文件是有意还是无意引入，使用该包的安全问题已经存在。

有眼尖的用户发现上述用户的评论被 node-ipc 包作者@RIAEvangelist 删除。

@RIAEvangelist 回应称，“代码是不可能运行的，并不存在威胁，不过确实看起来比较恐怖。”

@MideSpike 回应这一说法称，“问题是你将代码推送到了仓库中，它不应该和 node-ipc 混合，这种行为应被视作恶意行为。”其他用户则质问其为何删除明显可表明所增加代码删除/覆写用户文件的帖子？

@RIAEvangelist 回应称，“我可以证实没有恶意代码。而且，我也不认为你理解你所指代的代码。这个代码不可能覆写用户文件。虽然看起来可能会覆写，但如果你看下它是如何运行的，就会发现不会发生你说预期的情况。”

当有人表示，“社区应该 fork node-ipc，因为它的所有人不再受信任。”

@RIAEvangelist 回应，“Forking 一直是个选择，版本锁定也如此。急着下结论称某个人不值得信任也很容易。代码审计、阅读许可证和文档可能会得出更好的评估。”

但随即有用户@hax证实称，“我测试了代码，可以确认，如果响应提示ip地址来自俄罗斯，则代码就会覆写文件（每次运行的可能性是1/4）。”

@RIAEvangelist则指出，“俄罗斯或白俄罗斯，而且前提是API是有效的，但实际并非如此。”

@hax 回应称，“是的，API秘钥现在无效了，但申请一个或重置非常容易。”这时，@MidSpike 指出，“在我测试期间，这个API 秘钥是有效的。不要对我们说谎。”

@MidSpike 指出node-ipc 作者的行为非常危险，这种行为不止是开玩笑行为，而且可实际损害俄罗斯开发人员的计算机或服务器。

而@RIAEvangelist则仍然嘴硬称，“我想没有人在撒谎。”

随后用户@liudonghua123 亮出代码，“代码不会说谎。如果你想要做点事情，不要背后搞鬼。”

随后@RIAEvangelist 哑口无言,没有进一步回应。

投毒供应链引发众怒

针对此事，由用户表示，“有人用行动表明开源是有国界的。供应链污染并非良策。”

GitHub用户@jukrb0x情绪激动，对该事件发表了四点看法：

（1）将不不相关代码和恶意代码写入开源用户来传播自己的个人情绪的行为，从来都不是抗议和提倡反战的正确方法。

（2）你让node社区为此蒙羞。有人star或fork你的项目，就是等于你在投毒无辜的开发人员和网络，你的个人道德永远不应该成为供应链中的主角。你为自己所开源的代码负责，即使没有相关底线，但我认为像你一样的人没有作为真正抗议人员或战斗人员的道德底线，你是一个笑话，就像幼儿园孩子一样幼稚。

（3）我只想问你，俄乌战争是当前发生的唯一战事吗？你到底是一个真正的反战人士，还是只是宣扬自己的个人政治信仰？你这么做太幼稚了。

（4）这个案例表明，nodejs 包系统中存在漏洞，你的所做作为已经导致信任链破产。你只是***，开源社区以你为耻。

用户@hax 指出，“提交恶意代码、删除披露这一行为的注释、撤销已被暴露的API四月并狡辩称因为API秘钥无效所以代码不工作的行为，让我认为这个人不再值得信任。我强烈建议npmmirror 不仅把Node-ipc 列入黑名单，而且还要把他所提交的所有数据包全部列入黑名单。”

如何保护开源软件供应链安全

实际上针对供应链投毒的事件层出不穷。比如曾在2018年发生的event-stream 投毒事件。项目作者由于时间和精力有限，将其维护工作交给了另一位开发者 Right9ctrl，该开发者获得了 event-stream 的控制权，将恶意代码注入。据报道，该恶意程序在默认情况下处于休眠状态，当 BitPay 的 Copay 钱包启动后，就会自动激活，它将会窃取用户钱包内的私钥并发送至 copayapi.host:8080。event-stream包是一个Node.js 流数据的 JavaScript 软件包，每周下载量在200万次以上，截止到目前为止已经有大约800万次的下载量，持续时间为2.5个月。

使用越来越广泛的开源项目已成为软件基础设施的核心组成部分，开源项目自身的开发安全也愈发重要。代码托管服务器、Git账户、社区账户、制成品仓库等各个开发环节都有可能成为不法黑客的攻击目标。这次node-ipc 库中被植入恶意代码就是一个典型的案例。

除event-stream 事件外，近期还发生多起开源软件供应链安全事件，比如Log4Shell 事件、Linux “脏管道”事件、周下载量超过700万次的 JavaScript 流行库 ua-parser 账户遭接管事件、影响多家大厂的依赖混淆事件、SolarWinds事件、PHP源代码事件等等。

供应链安全风险是各个层面、各个环节、各个维度的。其最大的挑战就在于供应链的复杂性。首先，针对供应链各环节，需要有检测安全风险的能力；第二，供应链安全是动态的，需要持续监测，并配有安全运营机制。

当前，从软件供应链安全的角度来看，国内监管机构已陆续推出相关标准及政策，但针对关键基础设施和重要信息系统相关的企业和单位，并没有制定具体的举措和细则要求。

打好软件供应链安全治理“团体赛”，需要整个开源生态在供应链的各个环节建立一系列的安全准则和最佳实践，切实保障整个网络空间的安全。例如，在代码最终交付之前，采用应用安全的静态、动态分析方案，尽可能避免造成后门或漏洞；在供应链的各个环节中，引入完整性校验技术及流程，避免遭意外或恶意篡改。

代码卫士试用地址：https://codesafe.qianxin.com/

开源卫士试用地址：https://oss.qianxin.com