8 ms·

Building a backdoor with Node.js

103 points by lirantal 7y ago

w-ll 7y ago
Why Node? Why make a backdoor with a 90MB payload? Sorry guys, I should have fully read the article.
- matharmin 7y ago
  The article is about injecting a backdoor in a Node server using a malicious NPM package.
- bryanrasmussen 7y ago
  either because they think they have a bigger potential audience if Node is used, or because Node is what they know best.
  - giancarlostoro 7y ago
    I mean given how prevalent Node is for frontend theres a high possibility you could compromise a big enterprise companies proprietary code.
  - jetti 7y ago
    It is also a rather easy attack vector. Publish an npm package with this code and when people pull it into their project they will have opened up a backdoor.
  - ufmace 7y ago
    I think you can make a case that Node/NPM is more vulnerable to this than usual due to the huge number of packages pulled in by even simple applications. Can anybody really audit what 10k different packages are doing, and if any of them has had malicious code snuck in at some point?
    - eeZah7Ux 7y ago
      It's not just more vulnerable, it's incredibly so.
      - wesleytodd 7y ago
        Which platform do you use which does not rely on large amounts of open source libraries?
        okareaman 7y ago
        Powershell has a security model. Also, Ryan Dahl (creator of node.js) is working on Deno as a replacement because he thinks he made a mistake with node. 10 Things I Regret About Node.js - Ryan Dahl https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
        wesleytodd 7y ago
        Ryan is one person and not involved with node anymore. Deno also has many mistakes IMO, so fine to agree to disagree on this one.
        okareaman 7y ago
        Interesting. You think he is making mistakes again? He complains about "second system syndrome." I've been using Deno for hobby projects and find a lot to like about it.
        mikewhy 7y ago
        There's a bit more to it than that. The article touches on the fact that whats on npm doesn't have to match with what's on github (which is true for any package system that isn't 100% backed by source control).
      - benologist 7y ago
        It's not more vulnerable, it's as-vulnerable as any other package manager where anyone may upload code without sufficient review for people to blindly install and run. We have already seen this abused in browser extensions being repurposed to inject advertising, in node and ruby modules being converted to malware, cryptocurrency miners being added to games on Steam etc. There was even a Nintendo Switch game that bundled a Ruby IDE, I believe iOS has had apps surreptitiously bundling other software too.
- jetti 7y ago
  Not sure if you read the article or not but the author shows that this could be an npm package that, if included in a project, would open up a backdoor. The payload isn't large at all and the code base itself is small.
- fuj 7y ago
  If instead of trying to be snarky you would read the article you would understand why node is being used
LockAndLol 7y ago
Bud, screen-space is scarce. Why does that header permanently take up a third of vertical space?
- tmpz22 7y ago
  Because the goal of the page is to get your email sign up not to display text.
- ravenstine 7y ago
  What if you're halfway down the page but you want to click to another page on the site? How else are you to do that unless the nav menu is on the screen all the time??? Sticky headers are stupid and annoying. Easily the worst UX pattern in the last decade. I bet no one has even tested to see whether they even increase "engagement".
  - dylan604 7y ago
    how about something less sinister like not designed for mobile first, and it looks just fine on a desktop with plenty of pixels to be used? like everything else in the world, a decent idea implemented badly makes the idea look bad. also, opinions are like noses. everyone has one and they all smell.
peter_d_sherman 7y ago
Excerpts: "So the only requirement for the victim is to install the library browser-redirect and add it to Express app, like a regular middleware:" [...] "I [Article Author] just published the malicious package to npm using npm install browser-redirect@1.0.2. However, in Github you can’t see the malicious code — see Master Branch and release 1.0.2. The reason for this is because npm does not check against Github or any other source control repository." Security Perspective Takeaways: 1) Downloading and building source code, where authentication is performed between the downloaded source and the exact GitHub branch (rather than downloading a pre-built package or even source code where this branch authentication is not performed) would at least guarantee that the source code could be matched to the source on github, and could be subsequently audited... 2) The broader class of this attack (which includes such things as Windows Update, software auto-updaters, installers and package managers - both Windows and Linux) is basically: download malicious code - inside of a (user) believed non-malicious binary or library... 3) There are some very strong arguments here towards: a) Always use open source for whatever you can; b) Always download and compile the source for whatever you can; c) Always audit source that you've downloaded... I know; easier said than done...
- danShumway 7y ago
  I really don't want to get into an argument about this again, but I would add to this list -- if you're already being responsible about your NodeJS dependencies and paying attention to their source, consider going a step farther and vendoring them as well. If you're building a library that you want to put on NPM, obviously don't vendor those dependencies. But if you're building a website, or a game, or an electron app, there are a lot of scenarios where without too much work you can make sure that all of your dependencies are pure-JS, and then you can just commit them to your Git repo. You get a lot of benefits out of that, but specifically for security you get to know that when you download a repository you're not getting any unvetted code in your dependencies. For a non-trivial portion of time, vendoring dependencies was just advised as good behavior by the NPM maintainers. And at some point the advice flipped and now everyone in the JS ecosystem hates the idea, and for the life of me I can't figure out why -- as far as I know, languages like Go and Rust still have good support for this, so it's not like it's a fringe practice. ---- "But won't that spike the size of my Git repo?" Usually no, not unless your dependencies contain large binaries or you have a massive repo. Most of the projects from most of the people reading this don't fall into that category. "But can't I just set up a private NPM mirror?" Sure, but you probably won't. And if you do, you'll probably set it up to do something like auto-pull new versions from NPM which defeats the security gains. "But don't lockfiles solve this problem?" Virtually none of the engineers at your company care about lock file security. If they get a warning that a hash mismatches, they'll just delete the lockfile and reinstall. Never mind the fact that lockfiles are tied to semantic versioning and allow bug-fix changes unless you run `npm ci` instead of `npm install`. Your engineers are probably not running `npm ci`, and malware can be snuck into bug-fixes. "But won't this break platform-specific code?" Yes, but many projects don't need platform specific code. And to be blunt, if your dependencies are pulling in `node-gyp`, you're probably going to end up with an install error some day on an unfamiliar environment that makes you hate yourself anyway. So only use platform-specific code if you really have to. For example, pure-JS implementations of SASS are fast enough that for most projects you do not need the C-compiled version.
cryptica 7y ago
The problem with Snyk and other automated vulnerability detection tools is the rate of false positives. For my open source library, the false positive rate so far (over many years) has been 100%. Not one of the many reports pointed to a single exploitable vulnerability in my library. The reason is that a lot of vulnerabilities are context-specific. For example, a common one in JavaScript is Object prototype pollution; this is not an issue at all if the affected function is only used with trusted input. Just because a function is vulnerable under a certain specific condition, it doesn't mean that it's generally vulnerable. That's like saying that chainsaws have a critical security vulnerability on the basis that if you put your foot in front of it, you will be badly harmed... and then you use this as justification to warn millions of tree removal experts (and their customers too) all around the world that their businesses are critically vulnerable and fundamentally unsound because they happen to use chainsaws. The other common problem is when it flags a vulnerability with a specific function within a library, but that function is not actually used by the project. It's not fair to label all downstream projects as vulnerable on the mostly false assumption that the project actually uses the vulnerable part of the code. I think Snyk does this because it gets them attention and that's how they turn a profit, but they have to get wiser because this strategy is compromising the quality of their service.
akoumjian 7y ago
Really astounding to see them publish this article today. I have a CVE that's about to go live regarding auditing tools like this one. I contacted Snyk a week ago to point out that their audit tool (just like npm audit, and others) cannot fundamentally protect you from attacks like this when installed to the same environment as a malicious package. Almost feels like they are trying to get ahead of it. I was withholding the CVE while other tools are wrapping up their mitigation strategy. NPMJS and Snyk folks basically shrugged their shoulders. This is kind of forcing my hand to publish now. Well, here is the blog post explaining: https://mulch.dev/blog/CVE-2020-5252-python-safety-vuln/ https://mulch.dev/blog/CVE-2020-5252-python-safety-vuln/ And here is the snyk proof of concept: https://github.com/akoumjian/npm-audit-vuln https://github.com/akoumjian/npm-audit-vuln TLDR; Don't ever use the `npm install` version of Snyk. Use the binaries or the dockerized version.
- akoumjian 7y ago
  Here is PyUp (safety) response: https://pyup.io/posts/patched-vulnerability/ https://pyup.io/posts/patched-vulnerability/
philplckthun 7y ago
One can hope that with GitHub supporting signed commits and signed tags that now that they’ve acquired npm there’ll be a way to match up a signed release with an npm release. Signed releases on npm in general would be a start as then we could at least increase the reliability of security vulnerability notifications. That being said, as pointed out in another comment, the amount of false positives for instance for regex vulnerabilities in libraries that are only used in the devDependencies of a repository are too high.
cj 7y ago
Slightly off topic (but considering this is promo article from Snyk): What is the value of Snyk now that Github and NPM have built-in dependency security audits? I was a customer of Snyk before auditing was built in to NPM / Github (and before Snyk's price shot up to $750/mo for private repos). Was always confused how they justified that price point now that their main value prop is built in to npm for free.

103 points by lirantal 7y ago

w-ll 7y ago

Why Node? Why make a backdoor with a 90MB payload? Sorry guys, I should have fully read the article.

matharmin 7y ago
The article is about injecting a backdoor in a Node server using a malicious NPM package.
bryanrasmussen 7y ago
either because they think they have a bigger potential audience if Node is used, or because Node is what they know best.
- giancarlostoro 7y ago
  I mean given how prevalent Node is for frontend theres a high possibility you could compromise a big enterprise companies proprietary code.
- jetti 7y ago
  It is also a rather easy attack vector. Publish an npm package with this code and when people pull it into their project they will have opened up a backdoor.
- ufmace 7y ago
  I think you can make a case that Node/NPM is more vulnerable to this than usual due to the huge number of packages pulled in by even simple applications. Can anybody really audit what 10k different packages are doing, and if any of them has had malicious code snuck in at some point?
  - eeZah7Ux 7y ago
    It's not just more vulnerable, it's incredibly so.
    - wesleytodd 7y ago
      Which platform do you use which does not rely on large amounts of open source libraries?
      - okareaman 7y ago
        Powershell has a security model. Also, Ryan Dahl (creator of node.js) is working on Deno as a replacement because he thinks he made a mistake with node. 10 Things I Regret About Node.js - Ryan Dahl https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
        wesleytodd 7y ago
        Ryan is one person and not involved with node anymore. Deno also has many mistakes IMO, so fine to agree to disagree on this one.
        okareaman 7y ago
        Interesting. You think he is making mistakes again? He complains about "second system syndrome." I've been using Deno for hobby projects and find a lot to like about it.
      - mikewhy 7y ago
        There's a bit more to it than that. The article touches on the fact that whats on npm doesn't have to match with what's on github (which is true for any package system that isn't 100% backed by source control).
    - benologist 7y ago
      It's not more vulnerable, it's as-vulnerable as any other package manager where anyone may upload code without sufficient review for people to blindly install and run. We have already seen this abused in browser extensions being repurposed to inject advertising, in node and ruby modules being converted to malware, cryptocurrency miners being added to games on Steam etc. There was even a Nintendo Switch game that bundled a Ruby IDE, I believe iOS has had apps surreptitiously bundling other software too.
jetti 7y ago
Not sure if you read the article or not but the author shows that this could be an npm package that, if included in a project, would open up a backdoor. The payload isn't large at all and the code base itself is small.
fuj 7y ago
If instead of trying to be snarky you would read the article you would understand why node is being used

LockAndLol 7y ago

Bud, screen-space is scarce. Why does that header permanently take up a third of vertical space?

tmpz22 7y ago
Because the goal of the page is to get your email sign up not to display text.
ravenstine 7y ago
What if you're halfway down the page but you want to click to another page on the site? How else are you to do that unless the nav menu is on the screen all the time??? Sticky headers are stupid and annoying. Easily the worst UX pattern in the last decade. I bet no one has even tested to see whether they even increase "engagement".
- dylan604 7y ago
  how about something less sinister like not designed for mobile first, and it looks just fine on a desktop with plenty of pixels to be used? like everything else in the world, a decent idea implemented badly makes the idea look bad. also, opinions are like noses. everyone has one and they all smell.

peter_d_sherman 7y ago

Excerpts: "So the only requirement for the victim is to install the library browser-redirect and add it to Express app, like a regular middleware:" [...] "I [Article Author] just published the malicious package to npm using npm install browser-redirect@1.0.2. However, in Github you can’t see the malicious code — see Master Branch and release 1.0.2. The reason for this is because npm does not check against Github or any other source control repository." Security Perspective Takeaways: 1) Downloading and building source code, where authentication is performed between the downloaded source and the exact GitHub branch (rather than downloading a pre-built package or even source code where this branch authentication is not performed) would at least guarantee that the source code could be matched to the source on github, and could be subsequently audited... 2) The broader class of this attack (which includes such things as Windows Update, software auto-updaters, installers and package managers - both Windows and Linux) is basically: download malicious code - inside of a (user) believed non-malicious binary or library... 3) There are some very strong arguments here towards: a) Always use open source for whatever you can; b) Always download and compile the source for whatever you can; c) Always audit source that you've downloaded... I know; easier said than done...

danShumway 7y ago
I really don't want to get into an argument about this again, but I would add to this list -- if you're already being responsible about your NodeJS dependencies and paying attention to their source, consider going a step farther and vendoring them as well. If you're building a library that you want to put on NPM, obviously don't vendor those dependencies. But if you're building a website, or a game, or an electron app, there are a lot of scenarios where without too much work you can make sure that all of your dependencies are pure-JS, and then you can just commit them to your Git repo. You get a lot of benefits out of that, but specifically for security you get to know that when you download a repository you're not getting any unvetted code in your dependencies. For a non-trivial portion of time, vendoring dependencies was just advised as good behavior by the NPM maintainers. And at some point the advice flipped and now everyone in the JS ecosystem hates the idea, and for the life of me I can't figure out why -- as far as I know, languages like Go and Rust still have good support for this, so it's not like it's a fringe practice. ---- "But won't that spike the size of my Git repo?" Usually no, not unless your dependencies contain large binaries or you have a massive repo. Most of the projects from most of the people reading this don't fall into that category. "But can't I just set up a private NPM mirror?" Sure, but you probably won't. And if you do, you'll probably set it up to do something like auto-pull new versions from NPM which defeats the security gains. "But don't lockfiles solve this problem?" Virtually none of the engineers at your company care about lock file security. If they get a warning that a hash mismatches, they'll just delete the lockfile and reinstall. Never mind the fact that lockfiles are tied to semantic versioning and allow bug-fix changes unless you run `npm ci` instead of `npm install`. Your engineers are probably not running `npm ci`, and malware can be snuck into bug-fixes. "But won't this break platform-specific code?" Yes, but many projects don't need platform specific code. And to be blunt, if your dependencies are pulling in `node-gyp`, you're probably going to end up with an install error some day on an unfamiliar environment that makes you hate yourself anyway. So only use platform-specific code if you really have to. For example, pure-JS implementations of SASS are fast enough that for most projects you do not need the C-compiled version.

cryptica 7y ago

The problem with Snyk and other automated vulnerability detection tools is the rate of false positives. For my open source library, the false positive rate so far (over many years) has been 100%. Not one of the many reports pointed to a single exploitable vulnerability in my library. The reason is that a lot of vulnerabilities are context-specific. For example, a common one in JavaScript is Object prototype pollution; this is not an issue at all if the affected function is only used with trusted input. Just because a function is vulnerable under a certain specific condition, it doesn't mean that it's generally vulnerable. That's like saying that chainsaws have a critical security vulnerability on the basis that if you put your foot in front of it, you will be badly harmed... and then you use this as justification to warn millions of tree removal experts (and their customers too) all around the world that their businesses are critically vulnerable and fundamentally unsound because they happen to use chainsaws. The other common problem is when it flags a vulnerability with a specific function within a library, but that function is not actually used by the project. It's not fair to label all downstream projects as vulnerable on the mostly false assumption that the project actually uses the vulnerable part of the code. I think Snyk does this because it gets them attention and that's how they turn a profit, but they have to get wiser because this strategy is compromising the quality of their service.

akoumjian 7y ago

Really astounding to see them publish this article today. I have a CVE that's about to go live regarding auditing tools like this one. I contacted Snyk a week ago to point out that their audit tool (just like npm audit, and others) cannot fundamentally protect you from attacks like this when installed to the same environment as a malicious package. Almost feels like they are trying to get ahead of it. I was withholding the CVE while other tools are wrapping up their mitigation strategy. NPMJS and Snyk folks basically shrugged their shoulders. This is kind of forcing my hand to publish now. Well, here is the blog post explaining: https://mulch.dev/blog/CVE-2020-5252-python-safety-vuln/ https://mulch.dev/blog/CVE-2020-5252-python-safety-vuln/ And here is the snyk proof of concept: https://github.com/akoumjian/npm-audit-vuln https://github.com/akoumjian/npm-audit-vuln TLDR; Don't ever use the `npm install` version of Snyk. Use the binaries or the dockerized version.

akoumjian 7y ago
Here is PyUp (safety) response: https://pyup.io/posts/patched-vulnerability/ https://pyup.io/posts/patched-vulnerability/

philplckthun 7y ago

One can hope that with GitHub supporting signed commits and signed tags that now that they’ve acquired npm there’ll be a way to match up a signed release with an npm release. Signed releases on npm in general would be a start as then we could at least increase the reliability of security vulnerability notifications. That being said, as pointed out in another comment, the amount of false positives for instance for regex vulnerabilities in libraries that are only used in the devDependencies of a repository are too high.

cj 7y ago

Slightly off topic (but considering this is promo article from Snyk): What is the value of Snyk now that Github and NPM have built-in dependency security audits? I was a customer of Snyk before auditing was built in to NPM / Github (and before Snyk's price shot up to $750/mo for private repos). Was always confused how they justified that price point now that their main value prop is built in to npm for free.