I don't agree that the exuberance over the brilliance of this attack is warranted if you give this a moment's thought. The web has been fighting lookalike attacks for decades. This is just a more dynamic version of the same.
To be honest, this whole post has the ring of AI writing, not careful analysis.
No it doesn't?
It has been what, hours? since the discovery? Are you expecting them to spend time analysing it instead of announcing it?
Also, nearly everyone has AI editing content these days. It doesn’t mean it wasn’t written by a human.
I want no part of AI in any form of my communication, and I know many which espouse the same.
I will certainly agree on "many", but not "nearly everyone".
"we kindly ask that you complete this update your earliest convenience".
The email was included here: https://cdn.prod.website-files.com/642adcaf364024654c71df23/...
From this article: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
Such a Two Factor Authentication update request would have needed a blog post first, to announce such a fishy request.
This is smart, but not really unusual.
> 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?
In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.
That's because they are being "replaced", in a sense!
When an industry doubles every 5 years like web dev was for a long time, that by the mathematical definition means that the average developer has 5 years or less experience. Sure, the old guard eventually get to 10 or 15 years of experience, but they're simply outnumbered by an exponentially growing influx of total neophytes.
Hence the childish attitude and behaviour with everything to do with JavaScript.
And so, it seems, is everything else. Perhaps, this commentary adds no value — just old man yells at cloud stuff.
Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?
The lockfile includes a hash of the tarball, doesn't it?
Thank you!
The npm team eventually seemed to settle on requiring someone to bring an RFC for this improvment, and the RFC someone did create I think has sat neglected in a corner ever since.
The package.json locked the file to ^1.3.2. If a newer version exists online that still satisfies the range in package.json (like 1.3.3 for ^1.3.2), npm install will often fetch that newer version and update your package-lock.json file automatically.
That’s how I understand it / that’s my current knowledge. Maybe there is someone here who can confirm/deny that. That would be great!
That way it's much harder to make one hash look like another.
Simple. Instead of forcing colour, one could retain a no colour option maybe?
Done. Solved.
Everything should have this option. I personally have no colour vision issues, other than I find colour annoying in any output. There's a lot who prefer this too.
If you're the sort of person who would think about adjusting it to suit your sensitivity to this kind of attack, you're likely not the sort of person that the feature is trying to protect anyhow.
One will not be surprised to see that Chalk chooses its own path via the stunningly opaque FORCE_COLOR=0 and is all :fu: to people who suggest otherwise <https://github.com/chalk/chalk/issues/547#issuecomment-11268...> One will especially enjoy the "get bent" response because I discovered that one issue by, you know, searching the issues <https://github.com/chalk/chalk/issues?q=is%3Aissue%20NO_COLO...>
That's a lot of flexibility within which to do clever color math which accounts for the types of colorblindness according to their prevalence.
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 piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit of only checking the first and last few characters of an address before confirming a transaction.
We did a full deobfuscation of the payload and analyzed this specific function. Wrote up the details here for anyone interested: https://jdstaerk.substack.com/p/we-just-found-malicious-code...
Stay safe!