Traditionally, concerns over open-source code security have revolved around whether or not open-source code could contain vulnerabilities, backdoors, or hidden malicious code. In recent months, however, we have observed a growth in a particular trend: Open-source code is being subjected to modifications to its functionality to express political protest. These instances of so-called “protestware” occur in the form of code changes by certain open-source code maintainers or backers in what could only be surmised as politically motivated or protest-driven acts. While this activity is not new and has been seen in the past, the recent geopolitical situation has divided the open-source community: Some support the trend, while others prefer that the open-source ecosystem remain apolitical, as protestware could jeopardize the trustworthiness of open-source software as a whole.
This type of activity attracted significant attention after the maintainer of an important Node.js supply chain component, node-ipc, altered its code to have destructive behavior. This node-ipc incident happened in March and turned out to be far from being an isolated case. There have been other incidents in the open-source community tied to the ongoing conflicts in Ukraine, Israel, and Palestine, and other geopolitical issues. Users of open-source software therefore need to ensure that the whole supply chain of their open-source software stack is safe and has not been affected by code changes that are not related to the code components’ main functionality. In fact, this is a new concern that IT administrators have to worry about when securing their systems. Now, they also have to think about how politics might interfere with their digital supply chain.
In this blog post, we discuss several open-source code security incidents featuring code commits that introduced political messages, malicious code modifications, and destructive actions. We also provide an analysis of what these incidents could mean for the IT industry as a whole and for the open-source community in particular.
The most notable of the recent open-source code cases was the node-ipc incident. Node-ipc is a package that enables local and remote inter-process communication (IPC) in Node.js. It supports Linux, macOS, and Windows, and is a key component of node packet manager (npm), which is a default package manager for Node.js. Consequently, node-ipc is deployed and used in many servers around the world, even if the system administrators of these servers did not explicitly install it; the node-ipc package could have been installed as a dependency of other packages.
Between March 7 and 8, 2022, the code for node-ipc was modified to include destructive commands if the code detected itself to be running in certain geographical regions. Simply put, it would overwrite any file it could access with a heart emoji if it passed the geolocation check. Two specific versions, 10.1.1 and 10.1.2, included this code modification. These altered versions were online for about five hours, until they were replaced by version 10.1.3, a version without the destructive code.
Further, another modified version of node-ipc, version 11.0.0, was uploaded within another four hours. This added the use of the peacenotwar module, which dropped a text file on a user’s desktop. This functionality was declared in the new version’s README file, which, for obvious reasons, had not been done with the earlier versions. This version was used by more than 300 packages and was downloaded more than one million times during the first three weeks of March.
A GitHub user’s investigation of the node-ipc code showed that the malicious code added to the package would delete files based on a user’s IP address geolocation check via an online API.
This, in turn, was met with significant criticism in the open-source community, which led to the creation of at least one maintenance fork of node-ipc under a different maintainer.
The interdependence within and the security of the supply chain in open-source projects is indeed a growing problem. For example, in a separate, nonpolitical case, a security consultant named Lance R. Vick noticed that the foreach component of npm was controlled by a single maintainer, who had not been able to renew his personal email address domain. The consultant claimed that he was able to buy the domain and announced that he controlled the foreach package, although he said in later interviews that he did not actually log in to the account. This highlighted the lack of security around open-source code maintainer accounts, an issue that Vick had raised as early as 2020. In another case, which we discuss later in this article, a browser extension maintainer sold his project to a third party, which appeared to buy the project for a malicious purpose.
Medikoo attempted to explain his decision in a GitHub discussion thread, which received many negative comments from other developers.
The political message remains in the es5-ext package as of writing.
Event-source-polyfill, an npm library that implements the EventSource API for web browsers that do not support the API, also had a recent code commit in version 1.0.26 that featured a political message. In a GitHub discussion thread posted on March 18, a user opened an issue that discussed the undesired changes in the EventSource source code. Another user described the behavior of the affected version on the same thread. Like other politically motivated changes in the open-source projects discussed in this post, the package used time zone settings to decide whether to display the message or not. For matching time zones, the package would show an antiwar message in users’ browsers. The package would also try to redirect browsers to the petition website Change.org.
Attacks on software supply chains is indeed a growing problem. And the motivation behind such attacks is not always political: Code could be tampered with for pure financial gain, as in the case of The Great Suspender, an extension for Google Chrome.
Like many of the most popular browser extensions for Chrome, The Great Suspender was open-source. It was a lightweight app that helped free up system resources by automatically suspending or closing unused tabs in Chrome. This free app was installed more than two million times prior to its removal from the Chrome Web Store and automatic deactivation or disabling in users’ browsers.
In June 2020, the app’s original maintainer sold The Great Suspender source code to an unidentified party. The new maintainer published two versions: v7.1.8 and v7.1.9.
V7.1.8, which was published on the Chrome Web Store but not on GitHub, executed arbitrary code from a remote server. Based on a GitHub report, this new version appeared to be used for malware-like tracking and fraud actions, and was pushed to machines without notifying their users. It also did not automatically receive the malware-removing update. This meant that until Google disabled the app, this malicious version continued to run.
Meanwhile, v7.1.9 was created and published without the malicious code, but since it was handled by the malicious maintainer, compromised code could have been inserted into it at any time.
Regardless of how some developers might feel about political issues, the unfortunate reality is that expressing views on them via software, or “protestware” as it is now called, has unintended consequences. Organizations that use compromised open-source tools in their products could face significant reputational damage, especially if their products exhibit malicious behavior unbeknown to them. One example of software that used compromised open-source code happened to the Russian state-owned bank Sberbank, which warned its users not to update their software because of “increased cyberattacks.”
Broadly, malicious code commits in open-source code invite doubts about the reliability of open-source software. This might hinder or reverse the adoption of open-source software, as some organizations might feel the need to audit code because of these undesired events.
There is an effort to address software supply chain security issues with the introduction of the software bill of materials (SBOM). The SBOM is intended to unify the process of tracking security packages, software versions, and software patches that are used in software deployment. This bill will enable organizations’ security teams to swiftly respond to software supply chain breaches, evaluate the potential impact, and mitigate associated risks. Organizations can also use software composition analysis (SCA) tools to gain better visibility over open-source components. This is an area that Trend Micro researchers are currently looking into; we have talked about this topic as well.
Even when backed by good intentions, political code changes could bring unexpected consequences because they frequently rely on time zone checks or geolocation API queries to trigger politically motivated behavior. These checks and parameters are not always accurate and might bring about unanticipated effects if triggered incorrectly. Examples of incorrect triggering include time synchronization attacks, parameter tampering, time zone configuration errors, and inaccurate geolocation services.
Organizations can benefit from security solutions that provide visibility and monitoring of open-source application code. Trend Micro Cloud One – Open Source Security by Snyk automatically finds, prioritizes, and reports vulnerabilities and license risks in open-source dependencies used by an organization’s applications. As part of the Trend Micro Cloud One security platform, it connects with code repositories and CI/CD pipelines to scan projects, enabling security teams to gain relevant insights and improve risk management for organizations via increased visibility, tracking, and early awareness into open source issues.