Apr 27, 2022
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.
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:
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).
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.
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 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.