物联网开源组件安全：Node-RED白盒审计

文｜腾讯研发安全团队

Spine、martinzhou

Node-RED是IBM开源的低代码物联网编排工具，在物联网领域有广泛应用，包括研华WISE PaaS、西门子Iot2000、美国groov EPIC/groov RIO等工业IoT硬件也都预装了Node-RED。此外，它亦常被作为低代码开发平台使用。

基于腾讯自研SAST语义分析引擎“啄木鸟”，开展漏洞变体分析。我们对Node-RED平台进行了人工和自动化白盒代码审计，发现了多个通用高危漏洞（CVE-2021-21298、CVE-2021-21297、CVE-2021-3223、CVE-2021-25864等），并进一步探究了潜在利用方式及危害，本文将详述分析过程及典型案例。

Node-RED平台基于Express.js开发，我们从鉴权方式、http接口、客户端安全以及组件生态等多个维度入手开展分析。

Node-RED的鉴权方式依赖配置，默认没有任何鉴权，当开启鉴权后，会对接口进行鉴权。相关权限在settings.js文件中定义：

2.1.1 登陆机制

如果开启了鉴权功能，Node-RED会通过passport中的OAuth策略对用户进行登录校验并提供访问token，token通过浏览器的Local Storage存储。OAuth策略中使用账号密码进行登陆校验，通过bcrypt对用户密码进行校验。

此处可以认为不存在绕过方式。access token使用bearer策略进行校验，主要函数是：

Tokens采用map存储，此处存在一个潜在的安全风险：

2.1.2 权限机制

通过检测用户对象中的scope字段区分读写接口权限，当scope字段为 "*" 时，默认可以读写所有接口，admin默认权限就是 "*"。Node-RED在0.14版本之后对权限做了细分，详细可见：

https://nodered.org/docs/user-guide/runtime/securing-Node-RED#user-permissions，权限类型概述如下：

该接口就需要一个settings.write权限才能读取。如果接口声明未能和它的行为相符，或者存在漏洞，那么也可以认为是一个越权漏洞。

Node-RED中存在3类http接口：

上一节描述了Node-RED的接口鉴权机制，原生http接口未鉴权的较少，其中2和3类接口通过以下两种方式暴露：

因此，可以在源码中批量搜索来找未鉴权的接口。在对第三方组件分析、扫描过程中，我们发现很多插件都没有采用needsPermission方式鉴权，存在较大安全隐患。

Node-RED通过http头来实现鉴权，这意味着传统的CSRF攻击不再奏效，也有对应的CORS安全策略。

因此，主要关注的风险是XSS漏洞。从功能设计上看，Node-RED 前端只有一个大页面，使用JS操作dom的方式渲染后端数据，这种机制一定程度上收敛了产生XSS漏洞的风险。各组件面临的XSS风险及框架采取的预防措施，如下：

Node-RED的历史CVE数据显示，此前有过一个编号为CVE-2019-15607的XSS漏洞，修复提交记录为：https://github.com/Node-RED/Node-RED/commit/30c3004f27e86377613c06649f939e7f32746ca5。结合上述信息，我们认为主要存在两类风险：

1) 遗漏或不正确地使用内置过滤函数sanitize产生DOM XSS

Node-RED安全过滤方式为：调用RED.utils.sanitize对可能包含HTML特殊字符的变量做转义过滤。如：

这意味着，如果开发者忘记调用RED.utils.sanitize，就有可能出现XSS问题。在审计过程中，我们发现了一处相关风险，其位于

/@Node-RED/editor-client/src/js/ui/notifications.js第96-103行，在做innerHTML操作前由于未调用对msg变量做处理：

当在Node-RED的projects功能中，当用户尝试切换git分支，/editor-client/src/js/red.js会调用Red.notify弹出消息提示气泡。如分支名存在Payload，就会触发XSS漏洞，该问题已由官方确认并修复（https://github.com/node-red/node-red/compare/1.2.9...master）。

2) DOMPurify富文本过滤策略被绕过

主要涉及Markdown富文本编辑场景，虽然DOMPurify的过滤机制已十分完善，但历史上仍有绕过方式被披露，如：CVE-2020-26870。一旦该组件出现新的绕过方式，Node-RED亦可能受到影响。

Node-RED一大特色是其丰富、灵活的第三方插件生态，截至目前，平台提供3063个可用模块。许多的工业控制公司也开发了针对自身产品的node和flow，如：Node-RED-contrib-groov。

安装后，插件与Node-RED融为一体，会直接影响到整个平台的安全，正所谓“牵一发动全身”。

上述分析过程中，我们在Node-RED中发现了多个安全风险：

同时，在多款Node-RED流行插件中发现了多个高危风险，最严重可导致运行Node-RED的服务器被getshell：

—— 从任意文件读取到getshell

在审计Node-RED的Projects功能时，我们发现了一处任意文件读取漏洞（CVE-2021-21298），位于/editor-api/lib/editor/projects.js内。如下代码片段中，opts.path的输入内容用户可控：

直接传入了

/runtime/lib/storage/localfilesystem/projects/Project.js

如果treeish为 "_" 时，会直接调fs.join，而后调用readFile，产生了任意文件读取漏洞。

无独有偶，此类问题在Node-RED的第三方插件中也屡见不鲜。尽管Node-RED框架提供了对接口进行权限保护的方式RED.auth.needsPermission，但出于功能需要，部分Node-RED第三方插件的接口并未设置鉴权。如果未对路径穿越字符做处理，恶意参数值经path.join处理被传入res.sendFile，攻击者就可以窃取服务器上的任意文件。

借助自研白盒代码扫描引擎，我们在Node-RED官方提供的可视化插件Node-RED-dashboard中，发现了一例此类风险案例，CVE编号为CVE-2021-3223。

此处功能设计的本意是：通过RED.httpAdmin.get('/ui_base/gs/*'暴露接口，提供静态资源。

首先，使用req.params[0]获取参数值。随后，拼接出访问的目标文件路径并使用Express框架提供的res.sendFile方法，将相关内容发送给客户端。

由于并未对req.params[0]是否包含字符“..”做判断，产生路径穿越漏洞。另一款流行插件Node-RED-contrib-huemagic中也存在类似问题，编号为CVE-2021-25864，该插件用于与Philips Hue系列物联网设备交互。

进一步分析发现，该类路径穿越造成的任意文件读取漏洞，背后存在更严重的隐患。根据Node-RED的设计，认证凭据直接保存在本地文件中，攻击者可进一步读取管理员密钥，绕过鉴权保护。

所有用户登录生成的Access Token均存放在.sessions.json文件中，settings.userDir默认为$HOME/.Node-RED，由于可以读取目标服务器上的任意文件，$HOME变量不难预测。

Node-RED的UI后台借助Local Storage中存储的access_token票据鉴权，在.sessions.json中取得管理员凭证后直接设置相关字段，即可绕过登录鉴权：

攻击者登录后台后，可借助Node-RED平台提供的http-in、function、exec等节点，创建一个shell flow，实现对目标服务器的持久控制。

——i18next导致的原型链污染

3.2.1 从功能说起

说到JS特有的漏洞，大家肯定第一时间能想到原型链污染。其往往隐藏于一些JS的底层库中，像Lodash、Jquery等库都被爆出过该漏洞，在挖掘Node-RED的漏洞时，我们很幸运找到了一个能导致原型链污染的依赖。

在描述具体详情前，我们需要了解Node-RED的 i18n 功能的实现，作为一个全球都有使用的平台，加上其本身作为low-code平台的特殊场景，Node-RED支持了插件自定义语言。

为了实现插件自定义的语言加载，开发者使用了 i18next 作为他们的i18n实现。i18next本身也是一个易拓展的框架，可以定义不同的backend来自定义翻译文件加载过程。i18next维护着一系列官方backend实现，例如i18next-http-backend，能通过http加载翻译文件，详细列表可见https://www.i18next.com/overview/plugins-and-utils#backends。

而Node-RED自己实现了一套翻译文件读取的backend，如下图。

每个插件可以设置自己的locales目录，一个具体的目录内容如下：

其中目录名是语言名称，json文件存放的是对应语言的翻译。Node-RED通过统一的API访问不同插件的翻译文件，接口形式如下：

其中namespace对应Node-Red的插件类，language对应语言。

可以提供namespace和language来查询对应的翻译文件，访问

http://127.0.0.1:1880/locales/runtime?lng=zh-CN 来获取 namespace 为 runtime、language为zh-CN的json文件，也就是 `runtime/zh-CN/runtime.json` 文件，然而此处 backend 实现有一个“小问题”：

lng和ns参数直接传入了readFile，此处存在目录穿越漏洞，但限定死了后缀，这个file也就是每个插件自定义的固定json文件名。看上去此处目录穿越十分鸡肋，其实不然。

3.2.2 深入依赖

不可忽视的是，i18next就像一个黑盒，虽然Node-RED自己实现了一个读取翻译文件的backend，然而主要的语言管理以及翻译功能，都是i18next提供的，也就是说 i18next内部也必须管理这些资源，我们大致画一个流程图来解释i18next的文件读取工作流程。

在用户发送请求后，i18next会去backend请求对应语言的所有资源，backend返回资源后，i18next会通过addResourceBundle缓存对应资源，最后Node-RED调用getResourceBundle返回用户需要的部分。

问题出现在addResourceBundle中，这个接口适配了两套调用。一套是addResourceBundle(language, namespace, data)，另一套是 addResourceBundle(language, data)。

注意以下代码片段第三行的if逻辑，`lng` 可以通过 "." 来分割成ns和path两个变量。到这里还可以发现，i18next内部是通过path来实现存取bundle的，所以可以仔细看setPath和getPath两个函数。

在setPath中，调用了getLastOfPath这个函数，JS审计经验丰富点的话就可以看出这是个很明显的原型链污染。

至此，结合3.2.1中的“鸡肋”路径穿越，我们可以给出漏洞利用的POC：

http://127.0.0.1:1880/locales/x?lng=__proto__.test./../zh-CN/

这里的lng能确保读到翻译的json文件，而且会在addResourceBundle中被解析成 ["__proto__", "test", "/", "", "/zh-CN/"]的path, 从而导致test属性被污染。

可惜的是，这个漏洞仅仅能污染key，value并不可控，算是一个小遗憾吧。虽然Node-RED本体可能很难利用，但Node-RED拥有丰富的插件生态，该漏洞同样能影响到插件，从而造成更大的危害。

3.2.3 小结

综上，Node-JS在提供能小至函数级的依赖，给开发者以便利的同时，也面临着大量底层库误用和漏洞导致的问题，这点值得警惕。

除人工审计外，我们还基于自研的SAST语义分析引擎，自定义漏洞变体分析规则，对Node-RED及其第三方开源插件进行了自动化检索分析，下面分享任意文件读取及原型链污染的实现思路。

我们应该秉持知其然、知其所以然的观念，从研发角度去看漏洞是如何产生的，否则在白盒检测层面就永远抓不住规律而浮于表面。以 express 为例，以下是一个很自然，但并不正确的静态文件serve的思路。

从最原始的需求下来，研发往往会认为这个需求是简单的，几行代码就能解决，但如果研发顺着这个思路，那很可能就会写出一个漏洞。

安全的做法是要限制读取的目录，在这个流程中有以下几种做法。

4.1.1 方法一：

校验 path.join 的结果是否还在资源目录内，用 JS 的 indexOf 方法判断最终路径是否是资源目录开头。例子如下：

或者也可以校验用户传入的参数中是否包含 ".."

4.1.2 方法二：

res.sendFile 可以设置 option 作为第二个参数，可以设置其中的 root 选项来限制读取的目录，但这个参数却是默认缺省的，而且语义上是有区别的，如果设置了root选项，默认是从root开始读取相对路径而非绝对路径。

如果研发使用了sendFile的options，意识到sendFile存在root选项，那么无论是测试也好，读文档也好，能很快的发现不需要自己拼接，从而省略 path.join 的过程。例子如下：

有意思的是sendFile还有个特性，当传入的路径中包含 ../ 或者 ..\ 的时候，是会直接拒绝访问的，但因为 path.join 调用，导致 ../ 被去掉了，如果把 path.join 直接换成加号，在linux上其实一点问题没有。

4.1.3 方法三：

直接采用第三方包实现，方便安全，如serve-static：

综上，针对以上思路的文件读取漏洞很大程度上是依赖路径拼接这个关键点，所以我们编写规则时要加强对其的检测。通过分析以上漏洞产生的成因，可归纳出漏洞形成的条件，整理成一个检测流程：

1. 设置 source点和sink点

2. 通过污点传播分析，获得传播路径

3. 如果 sink 为 res.sendFile，过滤路径中不含 路径拼接函数 的路径

4. 过滤路径中包含 值判断 以及 存在 options 设置 的路径

以下表格详细列出了以上检测流程中各个实体代表的值：

前两步会比较简单，通过数据流的方式就能得到结果，后两步需要额外判断变量值。通过这套流程检测出来的规则误报率会很低，但也有一些缺陷。

可能导致误报的原因包括接口权限，自定义过滤方式等。同时，因为第三步对路径拼接函数的检测，会导致部分漏报，但这部分比例不会很高。

原型链污染的检测和文件读取的检测存在很大的区别，它更像是C++数组越界写的JavaScript“翻版”，导致原型链污染的根源总会是以下这一行。

但这里要满足一个条件，一个是obj必须是object原型对象。在白盒层面我们该怎么判断这个obj的值呢？笔者这里也没有找到一个完美的方法，只能从漏洞pattern入手。

如果obj是object的原型对象，那么我们可以从来源考虑：

在参考了几个实际的漏洞后，发现以下这个pattern是最常见的，其中key是我们可控的字符串，往往来源于一个数组，且该语句和导致原型链污染的语句往往会在一个大循环内，就像案例中描述的那个 getLastOfPath 一样。

那么在这种情况下我们可以定义

例如以下代码：

第二行触发了Store("a")，所以 a 会被加入StoreSet中，同理，因为第一行符合key可控，所以触发了Load("a")，a也会被加入LoadSet中，当一个函数中的变量符合同时在两个Set中的条件时，我们认为它是可疑的。

但仅仅这样还不够，这里有三个问题：

1. 语句之间的先后关系

2. 怎么判断key是否是输入，也就是isInput函数的具体实现

3. 怎么判断是否做了安全检查

首先看第一个问题：

如果我们这样写，好像并没有问题，但是它们在for循环中又会有问题，所以我们需要判断语句间的先后关系。当我们发现 a 变量是可疑的时候，我们可以找到 a 变量相关语句，然后再在CFG上寻找先后关系。因为是单函数分析，所以并没有太大开销问题。

第二个问题比较麻烦，也是可能导致漏报的点。

因为该漏洞出现的函数很可能就是一个普通的逻辑函数。这个Input不能直接指向用户输入，这个输入还可能是来自于参数，尤其是一些JS的第三方底层库。如果分析过一些原型链污染漏洞，也可以总结出一个pattern：

发生原型链污染漏洞的key来源大多是来自于单个实参（参数本身是object，例如json对象），像以上例子这个key可能会来自于a，b，c，d中的任意一个。

所以我们还需要对key做一个数据流反向追踪，观察是否满足以下条件：

• key来源于单个形参

• 没有其他形参参与到key的运算

这里我们要把第三个问题考虑进去，也就是过滤问题，针对原型链污染漏洞，基本的防护方法大致如下

我们会发现基本都是对Load前key的判断，所以这里在反向追踪数据流时，有第三个条件就是不能有一些 判断 过程，具体可以是hasOwnProperty，indexOf 或者 != 等操作。

小结一下，具体的检测流程为：

新技术领域的背后也有“传统安全战场”。结合人工审计和自研语义分析引擎，我们对IBM开源的低代码物联网编排工具Node-RED进行了白盒审计，发现并协助修复闭环了多处高危安全风险。

我们认为，当类似的开源Web组件被引入物联网领域，安全风险并没有随之消失，考虑到使用场景及更新门槛，出现漏洞带来的影响反而可能变大了，因而提出了更高的研发安全要求。

依托自身安全能力，腾讯研发安全团队也将持续帮助业界开源组件提前消灭安全风险。本文中提及的漏洞均已修复，建议Node-RED的用户及时升级规避风险。

同时，相关开源团队可加强安全建设，相关材料可参见TSRC分享的《“安全需要每个工程师的参与”-DevSecOps理念及思考》。