16 ms·

Malicious NPM package opens backdoors on programmers' computers

93 points by LinuxBender 6y ago

philplckthun 6y 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.
- LinuxBender 6y 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 6y 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.
    - LinuxBender 6y ago
      Very true and good point. What would be a good low friction way to solve that?
      - im3w1l 6y ago
        I believe Debian uses a web of trust and irl verifications to build that web. Hierarchical trust like the x509 certs we use for https, sounds like a more convenient alternative.
      - dr-detroit 6y ago
        Be able to read and comprehend your dependencies. Reduce dependencies. Eschew learning-frameworks like create-react-app for production projects.
        ethanwillis 6y ago
        I think this is an important skill that enough people don't cultivate nowadays. At some level there's always going to be some dependencies unless you literally bootstrap the universe from first principles. And people like to use that as a rationalization for why they shouldn't bother going a little bit lower level than they normally would. I recently put together my own personal blog after years of putting it off and letting domains go unused. I've thought about using Hugo, Jekyll, even Wordpress. But I just hated the thought of everything extra that comes with them. But I also didn't want to handwrite all of my HTML, manually move files around, etc. So instead I wrote my own thing in about 20 lines of bash. Super easy to comprehend and I can fit it to exactly what I'm doing. It feels nicer versus typical Node stuff I do where it feels like I'm stuffing clowns in a car.
      - lftl 6y ago
        A popularity score that combines age of the package, number of downloads, and the number of packages that depend on the package in question could give a quick metric for cases like this, helping people realize that this probably isn't the official Twilio package. All of that is roughly available on the npm website, but isn't really exposed in the CLI.
        ethanwillis 6y ago
        I read it in a different way, not to say your reading is invalid! My interpretation was that a malicious actor could be holding a compromised key.
      - gravitas 6y ago
        Distributions who have built GPG keychecks into the process use the keyparts distributed by themselves; meaning that on RHEL systems (and the clones - CentOS, OracleLinux, etc.) use the GPG keyparts delivered via the vendor "release" packages sitting in /etc/pki/rpm-gpg/, an Arch system uses "archlinux-keyring" which populates /use/share/pacman/keyrings/ and so forth. A 3rd party vendor source (think Nginx, Percona MySQL, Zabbix, etc.) who runs their own yum repo provides their own trusted GPG key and signs their packages with their key, so you install the "foobarvendor-release" package which contains their keys. System package installs then do a GPG check against those known good keyparts from trusted vendors which you've allowed and stop you when you have an unsigned package (being a bit light on detail here, each distribution handles it their own way). So the NPM (or Artifactory, etc.) ecosystem could invent an installable package of their GPG keys, and require all packages sourced from their server to be signed with this key -- this is how the EPEL 3rd party community repo works for example. These are all based on trusted humans having access to the signing keys and process, so there are layers of vetted/known folks required (not just anyone can walk into Mordor here). This does not work though for some Linux distributions such as Ubuntu due to their original design. Debian/Ubuntu systems for example are at somewhat of a disadvantage here; from the beginning the DEB system design has eschewed GPG signing individual packages and instead sign repositories (which tends to also get disable/ignored if even used), they're at least now recommending HTTPS around apt which is nice.
      - asimpletune 6y ago
        In just the most general sense, you do this by associating a public key with something else that is already presumed to be trusted, eg belonging to the alleged owner. For example, a DNS record belonging to twillio.com, saying their npm public key is “xyz”. Then, to the point others mentioned here, you include the logic to verify this in the package managers, ie compare the signed package with the trustee public key. Although the verification would also be something that could easily be done by a human as well. Your points of failure here are a) trusting the DNS system, which is acceptable for most use cases, and b) trusting the package manager, which is a similar situation to a above. There are a few types of dns records that are meant for this already, depending on the specific, but probably a txt record is fine and I think what most people do now, though I could be wrong about that.
- brundolf 6y 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.
Havoc 6y 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
- koratkar 6y ago
  The feeling of knowing that your computers and accounts are secure and that even if something bad happens you can easily just restart is great.
- fsflover 6y ago
  You may like Qubes OS, which relies on a bunch of virtual machines for security through isolation.
- TheDong 6y 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/ https://www.qubes-os.org/
  - Havoc 6y 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...
    - TheDong 6y ago
notpublic 6y 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-scripts-vulnerability https://blog.npmjs.org/post/141702881055/package-install-scr...
- msoad 6y 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 6y ago
  You can also just not use npm!
- mushufasa 6y 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 6y 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.
    - mushufasa 6y ago
      yes, and if i need the component then i have to run the scripts...
  - notpublic 6y 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 :)
parksy 6y 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.
- dkonofalski 6y 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 6y 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.
    - dkonofalski 6y ago
      What defines a "general computing platform"?
  - 6y ago
mike-cardwell 6y ago
Thank god for https://gitlab.com/mikecardwell/safernode https://gitlab.com/mikecardwell/safernode Full disclosure: I'm the author of said application.
nahuel0x 6y 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-py 6y 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 6y ago
  Isn't that what Deno solves in this specific area?
  - awinter-py 6y 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 https://github.com/denoland/deno/issues/171

93 points by LinuxBender 6y 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.

LinuxBender 6y 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 6y 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.
  - LinuxBender 6y ago
    Very true and good point. What would be a good low friction way to solve that?
    - im3w1l 6y ago
      I believe Debian uses a web of trust and irl verifications to build that web. Hierarchical trust like the x509 certs we use for https, sounds like a more convenient alternative.
    - dr-detroit 6y ago
      Be able to read and comprehend your dependencies. Reduce dependencies. Eschew learning-frameworks like create-react-app for production projects.
      - ethanwillis 6y ago
        I think this is an important skill that enough people don't cultivate nowadays. At some level there's always going to be some dependencies unless you literally bootstrap the universe from first principles. And people like to use that as a rationalization for why they shouldn't bother going a little bit lower level than they normally would. I recently put together my own personal blog after years of putting it off and letting domains go unused. I've thought about using Hugo, Jekyll, even Wordpress. But I just hated the thought of everything extra that comes with them. But I also didn't want to handwrite all of my HTML, manually move files around, etc. So instead I wrote my own thing in about 20 lines of bash. Super easy to comprehend and I can fit it to exactly what I'm doing. It feels nicer versus typical Node stuff I do where it feels like I'm stuffing clowns in a car.
    - lftl 6y ago
      A popularity score that combines age of the package, number of downloads, and the number of packages that depend on the package in question could give a quick metric for cases like this, helping people realize that this probably isn't the official Twilio package. All of that is roughly available on the npm website, but isn't really exposed in the CLI.
      - ethanwillis 6y ago
        I read it in a different way, not to say your reading is invalid! My interpretation was that a malicious actor could be holding a compromised key.
    - gravitas 6y ago
      Distributions who have built GPG keychecks into the process use the keyparts distributed by themselves; meaning that on RHEL systems (and the clones - CentOS, OracleLinux, etc.) use the GPG keyparts delivered via the vendor "release" packages sitting in /etc/pki/rpm-gpg/, an Arch system uses "archlinux-keyring" which populates /use/share/pacman/keyrings/ and so forth. A 3rd party vendor source (think Nginx, Percona MySQL, Zabbix, etc.) who runs their own yum repo provides their own trusted GPG key and signs their packages with their key, so you install the "foobarvendor-release" package which contains their keys. System package installs then do a GPG check against those known good keyparts from trusted vendors which you've allowed and stop you when you have an unsigned package (being a bit light on detail here, each distribution handles it their own way). So the NPM (or Artifactory, etc.) ecosystem could invent an installable package of their GPG keys, and require all packages sourced from their server to be signed with this key -- this is how the EPEL 3rd party community repo works for example. These are all based on trusted humans having access to the signing keys and process, so there are layers of vetted/known folks required (not just anyone can walk into Mordor here). This does not work though for some Linux distributions such as Ubuntu due to their original design. Debian/Ubuntu systems for example are at somewhat of a disadvantage here; from the beginning the DEB system design has eschewed GPG signing individual packages and instead sign repositories (which tends to also get disable/ignored if even used), they're at least now recommending HTTPS around apt which is nice.
    - asimpletune 6y ago
      In just the most general sense, you do this by associating a public key with something else that is already presumed to be trusted, eg belonging to the alleged owner. For example, a DNS record belonging to twillio.com, saying their npm public key is “xyz”. Then, to the point others mentioned here, you include the logic to verify this in the package managers, ie compare the signed package with the trustee public key. Although the verification would also be something that could easily be done by a human as well. Your points of failure here are a) trusting the DNS system, which is acceptable for most use cases, and b) trusting the package manager, which is a similar situation to a above. There are a few types of dns records that are meant for this already, depending on the specific, but probably a txt record is fine and I think what most people do now, though I could be wrong about that.
brundolf 6y 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.

Havoc 6y 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

koratkar 6y ago
The feeling of knowing that your computers and accounts are secure and that even if something bad happens you can easily just restart is great.
fsflover 6y ago
You may like Qubes OS, which relies on a bunch of virtual machines for security through isolation.
TheDong 6y 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/ https://www.qubes-os.org/
- Havoc 6y 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...
  - TheDong 6y ago

notpublic 6y 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-scripts-vulnerability https://blog.npmjs.org/post/141702881055/package-install-scr...

msoad 6y 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 6y ago
You can also just not use npm!
mushufasa 6y 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 6y 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.
  - mushufasa 6y ago
    yes, and if i need the component then i have to run the scripts...
- notpublic 6y 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 :)

parksy 6y 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.

dkonofalski 6y 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 6y 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.
  - dkonofalski 6y ago
    What defines a "general computing platform"?
- 6y ago

mike-cardwell 6y ago

Thank god for https://gitlab.com/mikecardwell/safernode https://gitlab.com/mikecardwell/safernode Full disclosure: I'm the author of said application.

nahuel0x 6y 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-py 6y 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 6y ago
Isn't that what Deno solves in this specific area?
- awinter-py 6y 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 https://github.com/denoland/deno/issues/171