Securing Node-RED Applications

Abstract

Trigger-Action Platforms (TAPs) play a vital role in fulfilling the promise of the Internet of Things (IoT) by seamlessly connecting otherwise unconnected devices and services. While enabling novel and exciting applications across a variety of services, security and privacy issues must be taken into consideration because TAPs essentially act as persons-in-the-middle between trigger and action services. The issue is further aggravated since the triggers and actions on TAPs are mostly provided by third parties extending the trust beyond the platform providers. Node-RED, an open-source JavaScript-driven TAP, provides the opportunity for users to effortlessly employ and link nodes via a graphical user interface. Being built upon Node.js, third-party developers can extend the platform's functionality through publishing nodes and their wirings, known as flows. This paper proposes an essential model for Node-RED, suitable to reason about nodes and flows, be they benign, vulnerable, or malicious. We expand on attacks discovered in recent work, ranging from exfiltrating data from unsuspecting users to taking over the entire platform by misusing sensitive APIs within nodes. We present a formalization of a runtime monitoring framework for a core language that soundly and transparently enforces fine-grained allowlist policies at module-, API-, value-, and context-level. We introduce the monitoring framework for Node-RED that isolates nodes while permitting them to communicate via well-defined API calls complying with the policy specified for each node.

Architecting Trigger-Action Platforms for Security, Performance and Functionality

“…Our design choice of using a TEE enforces all three interpretations of isolation using hardware assistance and a small privileged security monitor. This is a stronger security property than current TAPs that rely on JavaScript language-based isolation that has a history of bugs [19] and only provides a weak version of the first two interpretations of isolation above.…”

“…The Keystone [48] framework considers three types of side channels: (i) Controlled channel (ii) Timing based and (iii) Cache based. Controlled channel var season = Meta.currentUserTime.month(); var sunrises: Array<number> = [9,8,7,7,6,5,5,6,7,8,8,9]; var sunsets: Array<number> = [15,16,17,19,20,21,21,20,19,18,16,15] To mitigate timing attacks against the cryptographic code inside an applet enclave, we enable timing resistance in WolfSSL during compilation. This only leaves timing attacks against applet code as a possibility.…”

“…All of this trust is unwarranted, and as we will show, unnecessary as well. TAPs are essentially cloud services, and thus, they are vulnerable to all security and privacy issues that plague cloud services [4], [6], [18], [19]. For example, an attacker could exploit a bug in the web stack to steal OAuth tokens and then use them to access sensitive data or an attacker could compromise parts of the cloud service to violate integrity of applet execution.…”

“…A growing line of work in TAP security is exploring alternative designs for trigger-action platforms with the goal of achieving approximations of this ideal world [19], [23], [28], [32]- [34], [38], [55]. These works explore different points in the design space and have various trade-offs among security, performance and functionality under a threat model that the TAP itself is untrusted.…”

Untitled

“…The TTN was connected to the cloud hosting by Digital Ocean as a storage resource and outsourced the data for integration via the MQTT broker. Node-RED was deployed in this study to wire together the measurement unit, Application Programming Interfaces (APIs), and diagnostic unit to create a smooth data flow in the editor dashboard (Ahmadpanah et al, 2021;Ferencz et al, 2020). Node-RED refers to a JavaScript-based tool built with the Node.js platform.…”