Malicious NPM package opens backdoors on programmers' computers

https://www.zdnet.com/article/malicious-npm-package-opens-backdoors-on-programmers-computers/

by LinuxBender • 6 years ago

93 42 6 years ago

Despite a short lifespan on the npm portal, the library was downloaded more than 370 times

It’s probably worth mentioning that this doesn’t sound like the back door was successful at all. Every package typically has around ~100-200 downloads immediately due to scanners and proxies.

This security response of under a day really sounds like a good improvement, although I still wish npm had some support for signatures so trusted packages can be trusted indefinitely.

LinuxBender2• 6 years ago

I would love to see these things GPG signed. This has been done with Linux packages for ages. This is a real problem at my workplace. We pull in python and ruby files, mirror them in artifactory and have no way to know for sure where they actually came from. We use tools to scan the files, but these tools are really just looking for known CVE's and not likely they would find subtle changes that dial home and execute code.

wolfgke• 6 years ago

GPG signature only ensures that the package was signed by the owner of the key. It does not by itself ensure that the owner of the key is who he claims to be.

brundolf• 6 years ago

so trusted packages can be trusted indefinitely

If you specify an exact package version, you can trust that to be immutable. NPM doesn't allow replacing of existing versions, only addition of new versions.

Havoc2• 6 years ago

One of the reasons I’m looking to virtualize my dev machine. Ability to tear it down and rebuild in <5 mins means stuff like this barely matters

fsflover• 6 years ago

You may like Qubes OS, which relies on a bunch of virtual machines for security through isolation.

TheDong2• 6 years ago

If your dev machine contains credentials, like private ssh keys, aws keys, npm auth tokens, github tokens, etc, the compromise still can do some damage.

One very real benefit that separation gives you is that if you consciously run your email and banking outside of the VM, you now have a VM barrier between those things, meaning the malware now can _only_ steal ssh keys and docker logins and such, not those and your email + banking account password.

But really, why stop at just one VM? Why not use Qubes [0] and put your email webbrowser in a different VM from your banking webbrowser, your nodejs development in a different vm from your ruby development?

[0] https://www.qubes-os.org/

Havoc2• 6 years ago

Interesting concept - didn't know local splitting like that existed.

Currently using an ansible/cloud-init approach to spin up VMs on a proxmox server and vscode ssh remote dev in, but I guess it's a case of many ways to skin a cat.

SSH keys...yeah was trying to implement a jump server with 2FA but didn't get anywhere with it. VS code ssh remote doesn't seem to like jump servers even without 2FA.

Early days though...

notpublic2• 6 years ago

One can protect from these kinds of vulnerabilities by setting ignore-scripts to true as default:

  npm config set ignore-scripts true

  yarn config set ignore-scripts true

https://blog.npmjs.org/post/141702881055/package-install-scr...

msoad• 6 years ago

Wish they could simply disable this behavior! Or at least sandbox those scripts like Deno so if post install needs network or disk access, user has to specify a flag when installing

kordlessagain• 6 years ago

You can also just not use npm!

mushufasa2• 6 years ago

I tried this but then basic, very popular packages would fail to install properly. I couldn't even run npm start for my projects -- it would fail silently. So I had to revert because I couldn't get any work done.

Was I just doing this wrong?

bryanrasmussen• 6 years ago

try npm install --ignore-scripts when first installing

if problem, evaluate if you need to install that component and if look at the script.

notpublic2• 6 years ago

There is no easy way to do it. Wish yarn/npm had an --allow-scripts flag.

Anyway, this is what you could do. Find out which packages require postinstall scripts and then run it manually:

  $ grep postinstall node_modules/**/package.json
  node_modules/node-sass/package.json:    "postinstall": "node scripts/build.js",
  $ cd node_modules/node-sass/
  $ yarn run postinstall

On the positive side, you get to know more about the dependency that you are trying to add :)

parksy3• 6 years ago

Beyond the usual DIY security practices when dealing with NPM I wonder if there's viability in a service offering access to pre-audited repos like NPM, basically just a curated proxy with a process around certifying the security of packages and updates into the repo, including code reviews, dependency checking and various tests performed by security engineers.

I feel that the benefits in outsourcing some of that risk management could be a service worth paying for, at least for commercial purposes. It might lag behind and given the number of NPM packages most likely wouldn't offer the full range of packages, but I could see it bringing peace of mind for like the 90% of use-cases.

At the moment it would appear every NPM user is responsible for their own security, and the barrier of entry to the NPM repository is low which is fine and in keeping with the general principles of open source and distributed development, but on the flipside wouldn't it be more efficient to centralise the security auditing and management effort somewhere?

I don't know, just thinking out loud, perhaps there's good reasons why this hasn't happened.

dkonofalski3• 6 years ago

This is exactly the dichotomy that people find with the App Store model that Apple runs. You minimize the ability for malicious actors to open backdoors and run bad scripts but you also minimize the variety of ways that people can solve problems. Neither is outright bad but there's a trade-off and a lot of people don't see the benefits to this type of product/service until it affects them personally.

SahAssar• 6 years ago

I think a lot of the criticism against the App Store is because there is no alternative. I don't object to Apple having a store that they curate as they like, I object to them not allowing anything else on what has become a general computing platform.

parksy3• 6 years ago

Good point, however unlike Apple's model, if a hypothetical certified NPM repository was set up, there is still the open public repository. The freeform and experimental problem solving still occurs there. Developers could even benefit by being able to add the certified stamp to their public repositories if they so wished.

From the user's POV, opting to use the certified package repo would be a conscious decision and the trade-offs vs benefits should be well advertised. The service could also offer a "self certified" package facility to users if they understand the risks.

Now that I think about the potential downsides, would developers eschew dependencies to reduce the risk of losing a coveted "certified" badge, thereby undermining one of the more useful aspects of nodejs? Would developers get upset their code is included in a paid service and demand takedown or a revenue share? Fast forward a bunch of years, does this certification service become a looming spectre hovering over the node ecosystem and end up hurting what it was supposed to protect? Is the risk of a zero-day making it into the "official" repository too big for a startup to handle? Is it too much to ask users to simply "trust the process"? Would it just be too annoying for in-house developers to constantly have to battle missing and outdated dependencies as the certification team struggles to keep up with the constant stream of updates and new packages?

It would definitely require a lot of resources to set up and maintain, not to mention financial and legal finesse.

Maybe this is why I haven't come across such a service yet, maybe it's just in the too-hard basket or something. Interesting to think about though.

Gibbon1• 6 years ago

Random thought. OS vendors provide curated and maintain libraries. In native languages you also have curated libraries. Problem is everyone wants to replace native languages and OS's with webshit running in a browser using freeware libraries.

karlding• 6 years ago

There are projects like crev [0] which attempt to get around this by using a web of trust to audit dependencies. Rust has cargo-crev [1] as an implementation.

Here's the previous HN discussion [2].

[0] https://github.com/crev-dev/crev/

[1] https://github.com/crev-dev/cargo-crev

[2] https://news.ycombinator.com/item?id=18824923

parksy3• 6 years ago

Thanks, I hadn't come across crev. I have always worried that open review systems could create a false sense of security, if enough bad-faith actors poison the well.

But it looks like crev deals with this by allowing users to choose their circle of trust, which is an interesting concept, definitely following this project and will take a deeper dive into it. Cheers :)

emerongi• 6 years ago

I actually started building this exact product earlier this year. Then I realized I won't have the funds to hire people to actually do these audits. So I stopped.

Maybe this could be a community effort.

based2• 6 years ago

VMware/pivotal has a curated Open Source Application Catalog product: https://tanzu.vmware.com/application-catalog

  https://tac.bitnami.com/

Hallucinaut• 6 years ago

Do you have any idea on cost for this? It's somewhat ironic that you need to pay not for the software but to be protected from the free software these days...

weinzierl• 6 years ago

[..] there's viability in a service offering access to pre-audited repos like NPM, basically just a curated proxy with a process around certifying the security of packages and updates into the repo, [..]

This exists and is not uncommon in the enterprise world. sonatype is an example I have worked with in my Java days and I think they over npm too nowadays. It's just expensive and therefore not ubiquitous.

mike-cardwell• 6 years ago

Thank god for https://gitlab.com/mikecardwell/safernode

Full disclosure: I'm the author of said application.

nahuel0x• 6 years ago

You download code to run on your computer. You can't audit all of it. So, there is only two non-exclusive options:

A- Trust the source or an auditing third party (source signatures, apt, App Store, etc)

B- Run it on a sandbox, optionally extended with capabilities explicitly allowed by the user (browser, android, docker, wasm, snap, etc)

It seems there is no other way. This also shows how the classic unix permission model is obsolete. I think Wasm has a big role to play here.

awinter-py2• 6 years ago

libraries need a permission model like mobile apps

things like disk + network aren't necessary for a lot of libs

you should need to declare a manifest thing to access the platform APIs for those resources

oh_boy• 6 years ago

Isn't that what Deno solves in this specific area?

awinter-py2• 6 years ago

I think deno pkg.json permissions are process-level not library-level

I'm concluding that only by this very old thread; I'm not up-to-date with deno + could be wrong

https://github.com/denoland/deno/issues/171

Malicious NPM package opens backdoors on programmers' computers

Related Stories