[HN Gopher] The De-obfuscated Protestware code from node-ipc tha...
___________________________________________________________________
The De-obfuscated Protestware code from node-ipc that wiped Russian
computers
Author : freeqaz
Score : 12 points
Date : 2022-03-22 21:32 UTC (1 hours ago)
(HTM) web link (www.lunasec.io)
(TXT) w3m dump (www.lunasec.io)
| freeqaz wrote:
| Direct link to Code:
|
| https://www.lunasec.io/docs/blog/node-ipc-protestware#a-look...
|
| Edit: I tried to link directly there but it didn't work. The
| "hash fragment" in my submitted URL doesn't actually make it's
| way through the Hacker News link filter. My apologies to
| everybody for having to scroll to the bottom to actually get to
| the "real code"! Here is the link to use instead up above. (The
| rest is my OG comment)
|
| ------
|
| 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/
| Already__Taken wrote:
| years? we've done it already. run everything in containers. Am
| I missing something painfully obvious?
| freeqaz wrote:
| Containers can help to prevent some attack scenarios, ie by
| making it easier to "re-deploy" a container that has had all
| of it's files deleted, but they don't "sandbox" code very
| effectively against a sophisticated attack.
|
| For example: If you install a package that generates a random
| UUID, and that package has malware added to it silently, that
| package can do _anything_ that your backend code can do.
|
| Would you expect your random UUID library to make a network
| call out to a server and then open up a Bash shell to let
| somebody execute arbitrary commands?
|
| Containers don't help prevent that scenario. The only way to
| "fix" that is to _limit_ the default permissions of a library
| to be something _sane_.
|
| Maybe this UUID library is allowed to have filesystem access
| to read `/dev/urandom` but not to read `~/.ssh/id_rsa`.
|
| The default Node runtime does not provide any mechanism to
| whitelist or filter what privileges a module requires. Adding
| that capability would require major changes to the entire
| ecosystem (like every package adding a "permissions" manifest
| file).
| dane-pgp wrote:
| > Deno adds permissions per dependency
|
| Another project heading in that direction is also an anagram of
| Node:
|
| "The foundation of Endo is SES, a tamper-proof JavaScript
| environment that allows safe execution of arbitrary programs in
| Compartments. ... Endo uses LavaMoat to automatically generate
| reviewable policies that determine what capabilities will be
| distributed to third party dependencies.
|
| https://github.com/endojs/endo
| freeqaz wrote:
| Edit: Lol, I was looking at my previous submissions to HN and
| I noticed that I'd submitted[3] LavaMoat just a few weeks
| ago! Maybe with this recent Protestware stuff going on, that
| project can get a few more contributors wanting to help out.
|
| ------
|
| 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 attached
| similarly to how TypeScript types are "retroactively" added
| for existing vanilla JS 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
|
| 3: https://news.ycombinator.com/item?id=30280642
___________________________________________________________________
(page generated 2022-03-22 23:02 UTC)