De-obfuscated Protestware code in node-ipc that wipes Russian computers

• deno

  448 92,907 9.9 Rust

  A modern runtime for JavaScript and TypeScript.

  

My colleague and I wanted to understand how this malware/Protestware worked, so we took the time to manually de-obfuscate the code that was bundled with the recent "node-ipc" NPM package to find out.

It's pretty simple and makes it clear that this wasn't very "advanced" malware. It was very much an emotionally motivated Open Source dev wanting to use their "power" to protest the war. The impact of a more sophisticated attack is... something I think about a lot about how to fix.

That's why this is another good reminder to keep thinking about how we can actually "fix" these types of supply-chain attacks. Here is a list of malware in a spreadsheet[0] from other authors that also have protestware bundled. (It's in Russian but the Google Translate browser extension worked for me.)

I wrote a blurb at the bottom of this blog post when we published it talking about mitigating "bad" NPM packages, and I need to update it to add a bit about projects like Deno[1] that are attempting to solve this by "forking" the Node ecosystem.

Deno adds permissions per dependency (like a browser extension or phone app) and sandboxes all untrusted code by default. It's going to take us many years before we're at the point where a project like that is "production ready" but it's something that I'd encourage you to check out!

0: https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPt...

1: https://deno.land/

• DefinitelyTyped

  158 47,143 10.0 TypeScript

  The repository for high quality TypeScript type definitions.

  

Nice! Thanks for sharing that link. I've done a bit of digging into that project before and it's definitely a very promising idea.

It has a lot of the same pitfalls as Dyno, imo, in that it would require somebody to define a "security policy" for every module to whitelist permissions.

But, it's also something that could maybe be attacked in a similar way to how TypeScript types were "retroactively" added for existing NPM packages. Ie, packages that have never added their own type declarations (like `express`) can have their types added to DefinitelyTyped[0] and published as a separate NPM package (`@types/express`).

It works fairly well and something like `@endo-policies/express` wouldn't be crazy to add in later. Obviously it's going to be super painful, but fixing tech debt is always going to hurt.

vm2[1] is another Node project with some semi-similar goals that's worth mentioning. It's not designed to be "applied" in the same way as Endo, but it does give you a way to "sandbox" dependencies.

As a security person, I am weary to trust something like vm2 because it is much harder to "get right" than a "sandboxed-by-default" approach like Endo or Dyno. Look at this[2] CVE on vm2 from a few months ago for some evidence about _why_ this approach isn't ideal.

I'm optimistic for the future but we still have a long way to go before we get to it!

0: https://github.com/DefinitelyTyped/DefinitelyTyped

1: https://www.npmjs.com/package/vm2

2: https://github.com/advisories/GHSA-6pw2-5hjv-9pf7

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• GHSA-6pw2-5hjv-9pf7

  1 - -

Nice! Thanks for sharing that link. I've done a bit of digging into that project before and it's definitely a very promising idea.

It has a lot of the same pitfalls as Dyno, imo, in that it would require somebody to define a "security policy" for every module to whitelist permissions.

But, it's also something that could maybe be attacked in a similar way to how TypeScript types were "retroactively" added for existing NPM packages. Ie, packages that have never added their own type declarations (like `express`) can have their types added to DefinitelyTyped[0] and published as a separate NPM package (`@types/express`).

It works fairly well and something like `@endo-policies/express` wouldn't be crazy to add in later. Obviously it's going to be super painful, but fixing tech debt is always going to hurt.

vm2[1] is another Node project with some semi-similar goals that's worth mentioning. It's not designed to be "applied" in the same way as Endo, but it does give you a way to "sandbox" dependencies.

As a security person, I am weary to trust something like vm2 because it is much harder to "get right" than a "sandboxed-by-default" approach like Endo or Dyno. Look at this[2] CVE on vm2 from a few months ago for some evidence about _why_ this approach isn't ideal.

I'm optimistic for the future but we still have a long way to go before we get to it!

0: https://github.com/DefinitelyTyped/DefinitelyTyped

1: https://www.npmjs.com/package/vm2

2: https://github.com/advisories/GHSA-6pw2-5hjv-9pf7

Suggest a related project