Building a backdoor with Node.js
snyk.io
snyk.io
"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...
Such useless advice. Your day ends auditing the tool you're going to use to do something else. Security should be done as a collective effort than individually.
Nice suggestion. How do you propose this to be done?
Perhaps if you can easily flag a package as vulnerable from npm command would make people get alerted quickly?
npm audit flag [package name]
And just show how many percent of the downloaded people have flagged it when you try to install it.
You can easily see if it's a false positive by checking GitHub issues by seeing if people are talking about any vulnerabilities.
- Get rid of custom NPM install scripts for dependencies, force modules that rely on native code to bundle WASM or be set up by the user themselves. This closes off a lot of attack vectors. JS dependencies should not be able to execute custom code when they're installed.
- Make NPM treat minor semantic version changes as breaking changes by default. Currently, `npm install` ignores lockfiles for packages with bugfixes.
- In fact, if you want to be a little crazy consider getting rid of versions entirely and using package hashes instead. This has some tradeoffs, but might have some benefits as well.
- Vendor dependencies so you don't need to worry about them changing at the source. Apparently Yarn 2 is planning to do this by default, which is encouraging.
- On a community level, consider making it easier to put user-defined filters on top of NPM that define "safe" versions of specific packages. In Arch we have a distinction between vetted packages and AUR packages. That's not a perfect system either, but it's better than NPM which doesn't really have a ton of obvious indicators whether anyone else has vetted a specific version of a package. Note I'm not saying, "have somebody moderate every single package on NPM". I'm saying, "make little whitelists of safe packages that everyone uses, and let people easily subscribe to those whitelists."
Somebody somewhere has to do the security audit in order for us to have security. The collective part is about, "how do we make sure that the dependency isn't changing behind our back? How do we figure out who has and hasn't done the audit?" The reason why security in the Node ecosystem is so individualistic is because there are so many ways to circumvent collective security audits, and so few ways for users to aggregate those audits and coordinate them.
---
Also, I'll take any opportunity to advocate that we could also solve a lot of these security problems by having a proper permissions system for Node dependencies. This makes it easier to be responsible about what dependencies need what capabilities without necessarily needing to audit every line of code.
//No capabilities, leftPad and its dependencies cannot
//access the filesystem/network/etc...
var leftPad = require('leftPad', {});
//fs-extra can access the filesystem under this location,
//but not other capabilities like network/child-processes/etc...
var fs = require('fs-extra', {
filesystem: './assets'
});
Deno (Node's 'replacement') is a step in the right direction, but unfortunately only has permissions for the top-level binary. It's not trying to extend that system to dependencies, which I feel like is a kind of big mistake.
But ideally, yes, we would head at least a little bit in that direction. SELinux has bad UX, but some of these hard UX problems are solveable with enough effort.
It only has around 10 direct dependencies, but if I look in the node_modules folder...760 distinct modules required in the dependency graph.
Should I be doing security audits on every single one of the 760 modules?
- First, if you're treating Gatsby as a generalized site builder, this is an audit you only need to do once for all of your projects. It's not, "I need to audit 760 modules to build a simple webpage", it's "I need to audit my site builder once before I adopt it for all of my projects".
Of course, NPM makes it harder to treat Gatsby that way, because NPM makes it harder to freeze the entire package and guarantee you're using the same code everywhere. This is honestly true of a lot of package managers, there is a lot of room for future ecosystems to do package management better to help mitigate some of this personal responsibility.
Just as an example, I didn't need to personally do a security audit of every one of Krita's dependencies when I installed it in Arch. I downloaded a version that someone else had vetted. NPM just makes this hard to do.
- Second, the simple webpage part here is a little misleading. Gastby.js isn't simple, it's doing a ton of stuff. So it's not like building a simple webpage requires 760 modules, it's that you're using a site builder that comes with its own web Express web server, that does code transpilation with Babel and Webpack, that includes a code linter.
Here's the list of dependencies for Gatsby.js: https://www.npmjs.com/package/gatsby?activeTab=dependencies. Understanding that this isn't "a very simple webpage" puts that number into perspective and starts to make that security audit look at least a little bit more reasonable.
The Node ecosystem doesn't require 760 modules to build a webpage. It requires 760 modules to build a development environment, and then it bundles that development environment as a dependency. That's a very different situation to be in.
Yes, ideally.
I know this isn't practical. The fact that you have so many dependencies and any one of them could do something bad should be a sign that something is deeply wrong in the ecosystem.
I suspect it’s related to the ease of use to add new libraries/modules.
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.
I however no longer put node_modules in version control because NPM likes to shuffle around the files in node_modules every time you run a npm command. I instead fork each dependency and link directly to the tarball in the package.json.
But then there are dependencies of dependencies... The only solution is probably to allow users to sign packages and updates. And then you can pick a chain of trust so that if you trust the signatures of a few people they in turn trust the signatures of more people and you probably will end up with popular modules being vetted/signed by many people and thus considered safe.
The two things I'll say:
- First, it is very possible to use React without all of those dependencies, although it does mean skipping `create-react-app`. That could be a longer conversation in and of itself and going that direction comes with its own set of benefits and tradeoffs.
- Second, 307MB for a node_modules folder isn't actually so big that Git can't handle it. People get very frightened about this, but Git's performance on text files is pretty good. Obviously 307MB isn't ideal, but I strongly suspect in most cases you could commit those files in a single `initial commit` at the start of your project, and it would be fine -- you would not notice a major performance difference from Git.
The bigger concern is whether there are dependencies in creat-react-app that require node-gyp. Last time I checked, it wasn't bundling `node-sass` by default, but maybe that's changed. So there's a little bit of digging into your dependencies that you need to worry about to figure out what's going on.
I'm not going to say that `create-react-app` shouldn't be used. But I don't think `create-react-app` absolves you from needing to look at your dependencies and understand them. If you're in a position where you feel like you can't do that, then Git's performance probably shouldn't be your first concern.
https://next.yarnpkg.com/features/zero-installs
Give above I would still not recommend with current tooling to checking-in node_modules folder.
Current SASS implementation is made in Dart. https://sass-lang.com/dart-sass
Nice! I didn't know that, but I'm heavily in favor of that move. Yarn's handling of lockfiles even in version 1 is kind of just in general better than NPM's.
I agree with pretty much all of the recommendations they're giving at that link, particularly around avoiding install scripts.
> Current SASS implementation is made in Dart.
Unfortunately, the majority of Node projects still default to `node-sass` instead of `sass`. But you're correct, the `sass` package is what I recommend people use in most cases.
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.
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/
And here is the snyk proof of concept:
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.
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.
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.
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".
Sorry guys, I should have fully read the article.
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.
10 Things I Regret About Node.js - Ryan Dahl https://www.youtube.com/watch?v=M3BM9TB-8yA