Malicious Open Source: the cost of using someone else’s code. Hello everyone! This video was recorded for the VMconf 22 Vulnerability Management conference, vmconf.pw. I will be talking about malicious open source and the cost of using someone else’s code.

Alternative video link (for Russia): https://vk.com/video-149273431_456239086
Video in Russian from CISO Forum 2022: https://youtu.be/LPXg-MEamVA

To be honest, at the beginning of the year I did not plan to talk about these things. But life changes rapidly and unpredictably, so it becomes impossible not to talk about this.

My name is Alexander Leonov. I have been working in the field of Vulnerability Management since 2009, I have a blog about it. I invite you to subscribe.

The New Reality of Information Security (TNRoIS)

We must start with the fact that this year is fundamentally different. We now live in The New Reality of Information Security (TNRoIS).

Western commercial IT/InfoSec vendors have proven to be completely unreliable. If you use their products, be prepared that in one day you can see the degradation of the product’s functionality up to complete uselessness, blocked updates and user support. All this without any refund.

It has become quite clear that Open Source tools and code can harm your organization, because project maintainers can easily inject malicious features into their projects. Now they are actually doing it! Hypothetical threats have become quite real!

In this video, let’s focus on Open Source issues.

Open Source pros and cons

Of course, Open Source is a good thing. It benefits the developers. They can access code they couldn’t write themselves. They can learn from the best in the industry. And they can even raise their status and even earn money if their Open Source projects are widely used.

Open Source benefits companies that receive tested code and solutions for free, save time and money, and can bring their own products to market faster.

But at the same time, it makes organizations dependent on Open Source. Open Source has become an integral part of the infrastructure and software development process. You have most likely heard these best practices:

• Try not to write your own code, but use ready-made modules and libraries, because it is more efficient, faster and safer.
• Update these ready-made modules and libraries as soon as possible to prevent exploitation of vulnerabilities.
• Automatically rebuild and deploy projects by downloading dependencies from registries such as npm, PyPI, RubyGems, etc.

This leads to serious problems. One of the most interesting examples of this year is the malicious functionality in node-ipc.

Malicious node-ipc

Node.js (Node) is an open-source, cross-platform, back-end JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser. It allows the creation of Web servers and networking tools using JavaScript and a collection of “modules” that handle various core functionalities. Modules are provided for file system I/O, networking (DNS, HTTP, TCP, TLS/SSL, or UDP), binary data (buffers), cryptography functions, data streams, and other core functions. Modules can be installed with npm (Node Package Manager).

node-ipc is a nodejs module for local and remote Inter Process Communication with full support for Linux, Mac and Windows. node-ipc package has about a million downloads a week and is used as a dependency for 354 packages, including vue-cli.

On March 7, 2022, node-ipc maintainer Brandon Nozaki Miller (RIAEvangelist) embedded a package with malicious code into node-ipc. Malicious code has a 25% chance of replacing the contents of all files on systems (with write permissions) with the symbol “❤️”. It worked only on hosts with Russian and Belarusian IP addresses.

The code has been obfuscated. The parameters were stored in Base64. It’s not that hard to figure out manually what this code does, but it’s hard enough to detect such malicious functionality automatically.

Why did he do it? He explained this by some political position. But I don’t think it makes sense to talk about it. It can be political beliefs of any kind. Maybe there was a financial motivation. Maybe even he was intimidated by someone. It is important that a person had a certain power. People trusted him. And he took advantage of that trust to launch an attack.

File deletion was in versions 10.1.1, 10.1.2 (March 7). From March 8 to March 15, RIAEvangelist released versions 10.1.3, 11, 9.2.2 without file deletion, it just created a political proclamation file.

The last relatively safe version of node-ipc was 9.2.1. It hardly makes sense to continue to use RIAEvangelist’s releases of node-ipc, it is better to use the new fork.

It is not clear what to do with other projects where RIAEvangelist was a maintainer. He maintained 41 packages, some (js-queue, easy-stack, js-message, event-pubsub) have about a million downloads per week. It would be right to stop using them.

Other cases

It wouldn’t be so serious if it was a problem with one specific developer. However, unfortunately it is widespread. Some other cases:

▪ Encryptor in AWS Terraform modules (supported by the community). The malware was added by maintainer. Terraform is an open-source infrastructure as code software tool created by HashiCorp.
▪ Malicious functionality in the Tasmota firmware for ESP8266 and ESP32 microcontrollers that can block the devices.
▪ Destructive changes to the NPM packages colors and faker (used in 20 thousand projects), purposefully leading to failures at the build and execution stage.
▪ Political proclamations in es5-ext, rete, PHP composer, PHPUnit, Redis Desktop Manager, Awesome Prometheus Alerts, verdaccio, filestash. Of course political proclamations are not so dangerous. On the other hand, it shows who exactly controls the project. These maintainers can do something far more critical if they want to.

Registries

In response to such malicious activity in Open Source projects, enthusiasts began to make registries that document all this. I will mention three of them.

• ctorecords
• toxic-repos.ru
• GreatBookOfGrudges

What should we do?

To paraphrase the old meme that there are no clouds, there are someone else’s computers, there is no Open Source, there is someone else’s code. And those who control the code may have their own agenda.

But what about organizations using Open Source? What should they do?

The most obvious option and the least realistic: write code yourself, minimize dependencies, fork projects and maintain them yourself.

If we can’t just stop using someone else’s code, we’ll have to implement controls for Open Source:

• Maintain Software bill of materials (SBOM) for products
• Pay special attention to community projects. Large organizations tend to care more about their reputation and are less likely to engage in sabotage.
• Check dependencies for functionality (Quality Assurance), vulnerabilities (Dynamic and Static Application Security Testing) and related incidents (Vulnerability Intelligence)

I also wanted to mention the good articles on the Snyk blog. Preventing malicious packages and supply chain attacks, 10 npm Security Best Practices. This company discovered and investigated the node-ipc case.

It also looks right to pay attention to specialized solutions against Supply Chain attacks, for example by Checkmarx. Slogan “Don’t take code from strangers​”. I’m not sure that it makes sense to purchase this particular solution, but it’s right to study its capabilities.

Well, I would like to finish with two ideas. First, that the current situation reminds me of the state of security in aviation. Those requirements for the screening of passengers that now exist are the result of real attacks, which unfortunately ended in disasters. So the introduction of controls for Open Source is also a painful process, but a necessary one.

As another metaphor, I would like to recall the poison detectors from Frank Herbert’s Dune universe.

«The classic central chandelier remained unlighted, and its chain twisted upward into shadows where the mechanism of the poison-snooper had been concealed. Pausing in the doorway to inspect the arrangements, the Duke thought about the poison-snooper and what it signified in his society.

All of a pattern, he thought. You can plumb us by our language – the precise and delicate delineations for ways to administer treacherous death. Will someone try chaumurky tonight – poison in the drink? Or will it be chaumas – poison in the food?»

Indeed, the cases that we are seeing this year are some kind of poisoning attempts. We can discuss that this behavior is disgusting, that this is the behavior of cowards. But this will not stop such attacks. Protection from them becomes an urgent need. Those who do not do this are showing carelessness. So let’s set up our “poison-snoopers” and hope that this will save us from the most critical problems.