Earlier quoted context omitted.
Yep - https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee...
let's see the header of interest: Received: from npmjs.help by smtp.mailtrap.live
what about it?
NPM debug and chalk packages compromised
261–270 of 796 posts
Re: NPM debug and chalk packages compromised
#262Earlier quoted context omitted.
I agree, and this is arguably the best reason to use a password manager (with the next being lack of reuse which automatically occurs if you use generated passwords, and then the next being strength if you use generated passwords). I generally recommend Google's to any Android users, since it suggests your saved password not only based on domain in Chrome browser, but also based on registered appID for native apps, t…
I'm a pretty big fan of BitWarden/VaultWarden myself... though relatively recently something changed on my Android phone in that the password fills aren't working from inside my browser, I have to copy/paste from the app, which is not only irritating but potentially less safe.
Consider adding the widget/action to your quick actions: then to don't need to copy paste at least
Re: NPM debug and chalk packages compromised
#263One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one. This is a brilliant…
I'm a little confused on one of the excerpts from your article.
> Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3
As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it updates to a new patch version it's updating the lockfile with it. The npm docs suggest this is the case as well: https://arc.net/l/quote/cdigautx
And with that, packages usually shouldn't be getting updated in your CI pipeline.
Am I mistaken on how npm(/yarn/pnpm) lockfiles work?
Re: NPM debug and chalk packages compromised
#264From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-32668...
If it produces no output, does that mean that there's no code that could act in the future? I first acted out of nerves and deleted the whole node-modules and package.lock in a couple of freshly opened Astro projects, curious if I should considered my web surfing to still be potentially malicious
The malware introduced here is a crypto address swapper. It's possible that even after deleting node_modules that some malicious code could persist in a browser cache.
If you have crypto wallets on the potentially compromised machine, or intend to transfer crypto via some web client, proceed with caution.
Re: NPM debug and chalk packages compromised
#265I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a ma…
> The alternative is to import packages directly from the (git) repository.
That sounds great in theory. In practice, NPM is very, very buggy, and some of those bugs impact pulling deps from git repos. See my issue here: https://github.com/npm/cli/issues/8440
Here's the history behind that:
Projects with build steps were silently broken as late as 2020: https://github.com/npm/cli/issues/1865
Somehow no one thought to test this until 2020, and the entire NPM user base either didn't use the feature, or couldn't be arsed to raise the issue until 2020.
The problem gets kinda sorta fixed in late 2020: https://github.com/npm/pacote/issues/53
I say kinda sorta fixed, because somehow they only fixed (part of) the problem when installing package from git non-globally -- `npm install -g whatever` is still completely broken. Again, somehow no one thought to test this, I guess. The issue I opened, which I mentioned at the very beginning of this comment, addresses this bug.
Now, I say "part of of the problem" was fixed because the npm docs blatantly lie to you about how prepack scripts work, which requires a workaround (which, again, only helps when not installing globally -- that's still completely broken); from https://docs.npmjs.com/cli/v8/using-npm/scripts:
prepack
- Runs BEFORE a tarball is packed (on "npm pack", "npm publish", and when installing a git dependencies).
Speaking of TypeScript, the TypeScript compiler developers ran into this very problem, and have adopted this workaround, which is to invoke a script from the npm prepare script, which in turn does some janky checks to guess if the execution is occuring from a source tree fetched from git, and if so, then it explicitly invokes the prepack script, which then kicks off compiler and such. This is the workaround they use today:
https://github.com/cspotcode/workaround-broken-npm-prepack-b...
... and while I'm mentioning bugs, even that has a nasty bug: https://github.com/cspotcode/workaround-broken-npm-prepack-b...
Yes, if the workaround calls `npm run prepack` and the prepack script fails for some reason (e.g. a compiler error), the exit code is not propagated, so `npm install` will silently install the respective git dependency in a broken state.
How no one looks at this and comes to the conclusion that NPM is in need of better stewardship, or ought to be entirely supplanted by a competing package manager, I dunno.
Re: NPM debug and chalk packages compromised
#266Earlier quoted context omitted.
Sorry to be dumb, but can you expand a bit on "2FA reset email..." so the rest of us know what not to do?
> so the rest of us know what not to do? Can't really tell you what not to do, but if you're not already using a password manager so you can easily avoid phishing scams, I really recommend you to look into starting doing so. In the case of this attack, if you had a password manager and ended up on a domain that looks like the real one, but isn't, you'd notice something is amiss when your password manager cannot find…
After nearly being phished once (only having a confirmation email save me) I've taken to being extra vigilant if I don't get a password entry suggestion from my password manager. It means I need to be extremely damn sure I'm on a domain that is controlled by the same entity my account is with. So far I haven't had another incident like that and I hope to keep it that way.
Re: NPM debug and chalk packages compromised
#267Earlier quoted context omitted.
Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts. [1] https://www.debian.org/doc/manuals/securing-debian-manual/de...
In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense. So if we're discussin…
The NPM team has repeatedly commented that it's "too hard", effectively, and would discourage new developers from publishing packages. See:
https://github.com/npm/npm/pull/4016#issuecomment-76316744
https://news.ycombinator.com/item?id=38645969
https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...
Re: NPM debug and chalk packages compromised
#268Earlier quoted context omitted.
Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package. A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but s…
Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.
This is because you cannot easily remove problematic stuff from the browser. It's actively being used by someone, so the vendors keep it, so it continues to be used. The process takes decades, literally.
On the server side, of course, you can do whatever you like, see Node / Deno / Bun. But the code bundle size plays a minor role there.
Re: NPM debug and chalk packages compromised
#269From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-32668...
convenience script that checks through package.json dependency tree + a couple malicious binary patterns:
https://gist.github.com/edgarpavlovsky/695b896445c19b6f66f14...
Re: NPM debug and chalk packages compromised
#270Earlier quoted context omitted.
I clicked the link like a genius :)
I don't understand. The link could've come from anywhere (for example from a HN comment). How does just clicking on it give your package credentials to someone else? Is NPM also at fault here? I'd naively think that this shouldn't be possible. For example, GitHub asks for 2FA when I change certain repo settings (or when deleting a repo etc.) even when I'm logged in. Maybe NPM needs to do the same?
OP entered their credentials and TOTP code, which the attacker proxied to the real npmjs.com
FWIW npmjs does support FIDO2 including hard tokens like Yubikey.
They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages. iirc GitHub does force re-auth when you request an access token.