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

151–160 of 796 posts

Re: NPM debug and chalk packages compromised

#151

Post by tadamcz »

junon wrote: post #26
dboreham wrote: post #12

Earlier 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?

Ignore anything coming from npm you didn't expect. Don't click links, go to the website directly and address it there. That's what I should have done, and didn't because I was in a rush. Don't do security things when you're not fully awake, too. Lesson learned. The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things co…

Using a security key as 2FA instead of TOTP would have prevented this attack, right?

If you maintain popular open source packages for the love of God get yourself a couple of security keys.

Re: NPM debug and chalk packages compromised

#152

Post by suzzer99 »

bflesch wrote: post #114
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…

Can you attribute this technique to a specific group?

A few years ago, I remember reading about some NFT contract attack that did something similar. So I'm sure it's out there now.

Re: NPM debug and chalk packages compromised

#153

Post by anonymars »

twoodfin wrote: post #91
junon wrote: post #45

Earlier quoted context omitted.

That it had been more than 12 months since last updating them. Npm has done outreach before about doing security changes/enhancements in the past so this didn't really catch me. Screenshot here: https://imgur.com/a/q8s235k

Perfect example of why habituating users to renewing credentials (typically password expiration) is a terrible practice.

Frustrating that you're being downvoted

https://pages.nist.gov/800-63-FAQ/#q-b05

Re: NPM debug and chalk packages compromised

#154

Post by cddotdotslash »

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.

Re: NPM debug and chalk packages compromised

#155

Post by dsff3f3f3f »

skydhash wrote: post #72
dsff3f3f3f wrote: post #54

Earlier quoted context omitted.

I wouldn't use debug or ansi-styles. They're not even remotely close to being worth adding a dependency. Obviously none of them are trustworthy now though.

I wouldn’t even use chalk. Altering terminal output is easy. But it should be used sparingly.

You're right. I only looked at the source for debug and ansi-styles. After looking at chalk it's insanity to add that as a dependency as well.

Re: NPM debug and chalk packages compromised

#158

Post by homebrewer »

paulddraper wrote: post #29
stathibus wrote: post #18

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

Which of these would you prefer to reimplement? Debug, chalk, ansi-styles? --- You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years.

It's telling that we keep remembering xz to this day, while npm has these incidents on what feels like every single week.

Re: NPM debug and chalk packages compromised

#159

Post by komali2 »

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…

Do you do this in your CI as well? E.g. if you have a server somewhere that most would run `npm install` on builds, you just `git clone` into your node_modules or what?

Re: NPM debug and chalk packages compromised

#160

Post by zero_shift »

rglover wrote: post #63
grishka wrote: post #40

Earlier quoted context omitted.

Then the question becomes, why do developers of larger libraries import someone else's module for every little trivial thing?

Because they don't have the slightest clue what they're doing.

It's not that either.

There are a handful of important packages that are controlled by people who have consulting / commercial interests in OSS activity. These people have an incentive to inflate download numbers.

There could be a collective push to move off these deps, but it takes effort and nobody has a strong incentive to be the first

Post reply on HN