Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

291–300 of 796 posts

Re: NPM debug and chalk packages compromised

#291

Post by mrguyorama »

hunter2_ wrote: post #92
nodesocket wrote: post #79

Earlier quoted context omitted.

Yikes, looks legit. Curious what are the destination addresses? Would like to monitor them to see how much coin they are stealing.

In terms of presentation, yes. In terms of substance, short deadlines are often what separate phishing from legitimate requests.

There is NO reliable indicators, because every single one of these "Legit requests don't ..." recommendations has been done by a local bank trying to get their customers to do something.

My local credit union sent me a "please change your password" email from a completely unassociated email address with a link to the change password portal. I emailed them saying "Hey it looks like someone is phishing" and they said, "nope, we really, intentionally, did this"

Companies intentionally withhold warning emails as late as possible to cause more people to incur late fees. So everyone is used to "shit, gotta do this now or get screwed"

You can't hope to have good security when everyone's money is controlled by organizations that actively train people to have bad OPSEC or risk missing rent.

Re: NPM debug and chalk packages compromised

#292

Post by junon »

scratchyone wrote: post #252
junon wrote: post #119

Earlier quoted context omitted.

They phished username, password (unique to npm), and a TOTP code. They even gave me a new TOTP code to install (lol) and it worked. Showed up in authy fine. Whoever made this put a ton of effort into it.

Damn, that's an impressively well-done attack. Curious, do you use a password manager? If so, did it not autofilling feel like a red flag to you? I've always wondered if I ever get phished if I'll notice bc of that or if I'll just go "ugh 1password isn't working, guess i'll paste my password in manually" and end up pwned

I was on mobile, didn't use the autofiller. Also previous experience with the web extensions showed me that they were flakey at best anyway.

The `.help` should have been the biggest red flag, followed by the 48-hours request timeline. I wasn't thinking about things like I normally would this morning and just wanted to get things done today. Been a particularly stressful week, not that it's any excuse.

Re: NPM debug and chalk packages compromised

#293

Post by jamesnorden »

skydhash wrote: post #49
thewebguyd wrote: post #32

Earlier quoted context omitted.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

But why can’t we have a good library instead of those mini thingies?

The JS ecosystem values quantity over quality, for some bizarre reason.

Re: NPM debug and chalk packages compromised

#294

Post by int_19h »

tannhaeuser wrote: post #86
thewebguyd wrote: post #32

Earlier quoted context omitted.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

npmjs is the stdlib, or what emerged from it. It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative…

> JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations

It's not unique in this sense, yet others manage to provide a lot more in their stdlib.

It's not that you need a "big daddy". It's that the ecosystem needs a community that actually cares about shit like this vulnerability.

Re: NPM debug and chalk packages compromised

#295

Post by Mattwmaster58 »

josefbud wrote: post #263
DDerTyp wrote: post #52

One 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 upda…

As others have noted, npm install can/will change your lockfile as it installs, and one caveat for the clean-install command they provide is that it is SLOW, since it deletes the entire node_modules directory. Lots of people have complained but they have done nothing: https://github.com/npm/cli/issues/564

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.

Re: NPM debug and chalk packages compromised

#296

Post by dboon »

HexDecOctBin wrote: post #195
simpaticoder wrote: post #121

I'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…

As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal. Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.

Yeah lol I’m making a C package manager for exactly this. No transitive dependencies, no binaries served. Just pulling source code, building, and being smart about avoiding rebuilds.

Re: NPM debug and chalk packages compromised

#297

Post by mrguyorama »

cddotdotslash wrote: post #154

NPM deserves some blame here, IMO. Countless third party intel feeds and security startups can apparently detect this malicious activity, yet NPM, the single source of truth for these packages, with access to literally every data event and security signal, can't seem to stop falling victim to this type of attack? It's practically willful ignorance at this point.

Why would NPM do anything about it? NPM has been a great source of distributing malware for like a decade now, and none of you have stopped using it.

Why in the world would they NEED to stop? It apparently doesn't harm their "business"

Re: NPM debug and chalk packages compromised

#299

Post by 0cf8612b2e1e »

sigotirandolas wrote: post #276
josefbud wrote: post #263

Earlier quoted context omitted.

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 upda…

Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`. 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.

Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.

Re: NPM debug and chalk packages compromised

#300

Post by internetter »

winwang wrote: post #68
junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.

in general npm does a not-too-great job with these things
Post reply on HN