The popular NPM package, node-ipc, is a nodejs module for local and remote inter-process communication which supports all forms of socket communication from low level unix and windows sockets.

With over 1 million weekly downloads, node-ipc has found itself in the middle of the Russia-Ukraine conflict. Malicious code, also known as protestware, within certain versions of the package was causing chaos among Russia and Belarus based developers—overwriting their entire file system with a heart emoji (❤️). These versions (10.1.0 and 10.1.2) are now tracked under CVE-2022-23812.

Brandon Nozaki Miller, aka RIAEvangelist, is the node-ipc creator and seems to have designed these two versions as a peaceful protest act, as they primarily put a “message of peace” (hence the heart emoji) to every Russia or Belarus based developer who installs them.

CVE-2022-23812 Details

Once the package is installed, the ‘ssl-geospec.js’ file, which is located in the ‘dao’ folder, appears to be in charge of the workflow. The code in the file uses a service called ipgeolocation to determine whether the host is in Russia or Belarus once it has been installed. As you can see from this code breakdown in the next few screenshots:

We can review the ssl-geospec.js file as shown below:

Next, the code checks whether the host is located in Russia or Belarus:

Next, an asynchronization function checks for the print working directory (pwd), parentDir, grandParentDir and root directory.

As of versions v11.0.0 and v9.2.2 a module called peacenotwar is being used. affected users who installed the package will get the ‘WITH-LOVE-FROM-AMERICA.txt’ file written in 5 different languages. This text file opens up on their host with “peace” messages, as shown below:

Node-ipc and Vue.js

‘node-ipc’ is also a dependency in the popular JavaScript front-end framework ‘Vue.js’. Prior to this occurrence, however, ‘Vue.js’ was set up to fetch the newest minor and patch versions of the ‘node-ipc’ dependency instead of pinning the versions to a safe version. As a result, some users were startled as Vue.js CLI users made an urgent request to the project’s maintainers to pin the ‘node-ipc’ requirement to a safe version.

Snyk researchers suspect that npm took down ‘node-ipc’ versions 10.1.1 and 10.1.2, which caused blatant system harm, within 24 hours after publication. Versions 11.0.0 and above of ‘node-ipc’ are still available on npm. These versions also include the peacenotwar module, which generates, as mentioned above, the ‘WITH-LOVE-FROM-AMERICA.txt’ files on the host.

As a result, if you’re using the ‘node-ipc’ library in your project, make sure you pin the dependency to a secure version like 9.2.1 (it turns out that 9.2.2 isn’t safe either).

Open Source Package Risks in Cloud Environments

Whether it’s NPM, Python PIP, or Ruby Gems, rogue open source packages can pose major problems for cloud providers’ engineers.

Consider the following situation: 

For its internal CI/CD process, Organization X uses a number of NPM packages, including some well-known NPM packages that are similar to the packages we saw earlier. In addition to those, there are two packages named production-x-company-internal1 and production-x-company-internal2, which, as their names suggest, are internal packages which might imply they are not registered in npm public registry.

A bad actor could use the rogue package to retrieve sensitive information related to the company’s cloud provider infrastructure by abusing a novel attack known as “Dependency Confusion”. You can read the fascinating medium blog by Alex Birsan here.

One main principle must exist in order to carry out this Supply Chain Attack, and it is entirely dependent on how Organization X handles its NPM CI/CD process. For example, whether it installs packages from the public registry or not.

  1. For the sake of example, we will assume the Organization calls the NPM external registry first as default, meaning that by executing the following command:
    NPM is configured to use the public NPM registry by default, hence when installing a package, NPM will try to find it in the public registry by retrieving data from the following endpoint –    https://registry.npmjs.com/production-x-company-internal1But since the package does not exist (yet) – it will get a 404.
  2. Next, I’ll register the package in NPM as a public package, by performing the following:
    As seen from the screenshot above, I’ve started the process of creating a package by running npm init and then populating the various fields of the package we want to “hijack” and set the version to     9.9.9 (a higher version will be prioritized over a lower version).
  3. Next, I’ll set up my payload within the index.js file. As previously stated, my primary goal is to retrieve sensitive data related to the cloud provider (in our case, AWS), which means looking for both config and credentials files, as well as IMDSv2 data for the instance installing the package.
    The two variables (awsconfig and awscreds) in the screenshot above will be filled with the base64 encoded content of the ~/.aws/config and ~/.aws/credentials files.
    The request shown above would be sent to the IMDS server to retrieve sensitive data in our case:    http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance/
    In addition to 3 main variables (awsconfig, awscreds and the IMDS data), and as we can see from the above screenshot, I would be also interested in retrieving various data such as     hostname, username, and the uid of the host.
  4. The final payload, as well as the four custom headers that will be sent to my Burp Collaborator, are shown in the screenshot above.
  5. As the next to last step, all I have left to do is to set the “preinstall” function in the package.json file. The “preinstall” function guarantees that the malicious index.js will be executed immediately:
    When it all said and done, we left with 3 main files:
  6. The final step is to publish the package so it will become public, and then wait for the victim to install our malicious package:

We can see that the package was published successfully, and is now available in the NPM registry.Assume Organization X is getting ready to update its current environment, which includes installing new versions of its current NPM packages, including our malicious package. Installing our package would yield the following:

We can see from the screenshot above that we were able to send the POST request back to our host, complete with the various custom headers that are now filled with the sensitive data we were able to extract.

Open Source Risks in the Cloud and CI/CD Pipeline

Open source packages, such as NPM, Python PIP, etc., can play a crucial role in cloud environments and CI/CD processes. Supply chain attacks, such as ‘Dependency Confusion,’ can cause serious damage to both non-cloud and cloud-based organizations, as we saw in the example above. Balancing the open source trade-offs for the benefits when there are vulnerabilities, like CVE-20220-23812, requires a cloud security risk management approach that helps you prioritize your top cloud security risks instantaneously.

The Orca Security Research Pod will continue to provide our audience with updates as future details emerge. If you’d like to get in contact about specific security questions or learn more about the Orca Security Platform please contact us.

To better understand the current risk posture of your cloud environments, sign up for a 30-day free risk assessment.