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

681–690 of 796 posts

Re: NPM debug and chalk packages compromised

#681

Post by acdha »

typpilol wrote: post #631
acdha wrote: post #544

Earlier quoted context omitted.

I also use WebAuthn where possible but wouldn’t be so cocky. The most likely reason why we haven’t been phished because we haven’t been targeted by a sophisticated attacker. One side note: most systems make it hard to completely rely on WebAuthn. As long as other options are available, you are likely vulnerable to an attack. It’s often easier than it should be to get a vendor to reset MFA, even for security companies…

But this wasn't even really a spear fishing attack. It was a generic Phish email you were in every single Corp 101 security course

The attacker did have a great domain name choice, didn’t overuse it to the point where it got on spam block lists, and got them at a moment of distraction, so it worked. It’s really easy to look at something in a training exercise and say “who’d fall for that” without thinking about what happens when you’re not at your best in a calm, focused state.

My main point was simply that the better response isn’t to mock them but to build systems which can’t fail this badly. WebAuthn is great, but you have to go all in if you want to prevent phishing. NPM would also benefit immensely from putting speed bumps and things like code signing requirements in place, but that’s a big usability hit if it’s not carefully implemented.

Re: NPM debug and chalk packages compromised

#682

Post by hvb2 »

b112 wrote: post #641
SchemaLoad wrote: post #568

Earlier quoted context omitted.

2FA is a huge benefit over plain passwords. But it wasn't enough here. The package dev had 2FA and it did not help since they got tricked in to logging in to a phishing page which proxied the 2FA code to the real login page.

Yet the parent said for each upload prior to publish. This attack would have 100% been thwarted, when a load of emails appeared saying "publish package you just uploaded?". (if you read the dev's account of this, you'll see this would have worked)

Assuming you've compromised said developers account, wouldn't you be able to click that publish button too?

Re: NPM debug and chalk packages compromised

#683

Post by acdha »

sneak wrote: post #645
acdha wrote: post #544

Earlier quoted context omitted.

I also use WebAuthn where possible but wouldn’t be so cocky. The most likely reason why we haven’t been phished because we haven’t been targeted by a sophisticated attacker. One side note: most systems make it hard to completely rely on WebAuthn. As long as other options are available, you are likely vulnerable to an attack. It’s often easier than it should be to get a vendor to reset MFA, even for security companies…

The failure here was that his password manager was not configured and he manually copied and pasted the credentials into the wrong webpage . A password manager can’t manage passwords if you don’t configure it and use it.

Yes, and we know that’s a thing which people are trained to do by all of the sites which are sloppy about their login forms or host names so we should assume that attackers can trick people into doing it, even many people who think they are too smart for it. Hubris is quite a boon for attackers.

Re: NPM debug and chalk packages compromised

#684

Post by idiotsecant »

lelanthran wrote: post #648
dabockster wrote: post #515

Earlier quoted context omitted.

That wouldn't work against a really sophisticated attacker. Especially for something that's clearly being maintained for free by one overworked person in their spare time (yet again). You'd need some kind of offline verification method as well for these widely used infrastructure libraries.

> That wouldn't work against a really sophisticated attacker. Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply. > You'd need some kind of offline verification method as well for these widely used infrastructure libraries. I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be…

If only they would have had the benefit of you being around to do all that work with your glorious hindsight.

Re: NPM debug and chalk packages compromised

#685

Post by jmull »

junon wrote: post #398
jmull wrote: post #358

Earlier quoted context omitted.

Yeah, I get that learning the codes is a little annoying, but not actually harder than finding, incorporating, and learning one of the APIs here. Also one is standard while the other is not. Seems a bit nuts to use a package for this.

Hi, missing a lot of history here. When Chalk was written, colors in the terminal wasn't a flashy thing people tried to do very often, at least not in the JS world. Coming from browsers and wanting to make CLI apps using the flashy new Node.js 0.10/0.12 at the time saw a lot of designers and other aesthetically-oriented folks with it. Chalk filled a hole for people to do that without needing to understand how TTYs wo…

I doubt we'll ever see eye-to-eye on this. Some people try to think about how to write less code, and some people try to think about how to write more code.

Re: NPM debug and chalk packages compromised

#686

Post by lelanthran »

idiotsecant wrote: post #684
lelanthran wrote: post #648

Earlier quoted context omitted.

> That wouldn't work against a really sophisticated attacker. Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply. > You'd need some kind of offline verification method as well for these widely used infrastructure libraries. I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be…

If only they would have had the benefit of you being around to do all that work with your glorious hindsight.

> If only they would have had the benefit of you being around to do all that work with your glorious hindsight.

They didn't need me; plenty of repositories doing signed packages existed well before npm was created.

Which is why I likened them to a bunch of kids - they didn't look around at how the existing repos were designed, they just did the first thing that popped into their head.

Re: NPM debug and chalk packages compromised

#687

Post by goodpoint »

jonquest wrote: post #476
justusthane wrote: post #463

Earlier quoted context omitted.

No, they are extremely well vetted. Have you ever heard of a supply chain attack involving Red Hat, Debian or Ubuntu repos?

Yes, the XZ attack affected Fedora nightly and Debian testing and unstable. Yes, it got caught before it made it into a stable distribution (this time). https://www.redhat.com/en/blog/understanding-red-hats-respon... https://lists.debian.org/debian-security-announce/2024/msg00...

So the attack was successfully stopped and you complain about it?

Re: NPM debug and chalk packages compromised

#688

Post by grumple »

sneak wrote: post #472
winwang wrote: post #68

Earlier quoted context omitted.

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.

Can happen to anyone… who doesn’t use password manager autofill and unphishable 2FA like passkeys. Most people who get phished aren’t using password managers, or they would notice that the autofill doesn’t work because the domain is wrong. Additionally, TOTP 2FA (numeric codes) are phishable; stop using them when U2F/WebAuthn/passkeys are available. I have never been phished because I follow best practices. Most peop…

You can use password manager autofill and hardware 2fa and still get phished. All it takes is you rushing, not paying attention, clicking on a link, and logging in (been caught by my own security team doing this). Yes, in an ideal world you're going to be 100% perfect. The world is not ideal, unfortunately. I don't have a solution, but demanding humans behave perfectly in order to remain secure is not a reasonable ask.

Re: NPM debug and chalk packages compromised

#689

Post by acdha »

sunaookami wrote: post #578
acdha wrote: post #540

Earlier quoted context omitted.

> So pick one that does? That's like its top 2 feature Still doesn’t work 100% of the time, because half of the companies on earth demote their developer time to breaking 1995-level forms. That’s why every popular password manager has a way to fill passwords for other domains, why people learn to use that feature, and why phishers have learned to convince people to use that feature. WebAuthn prevents phishing. Passwo…

Then good password managers will still show you only the logins for that domain. If the login is on another domain then you would have saved it anyways when first logging in/registering and if the site moved then you can get suspicious and check carefully first.

All password managers allow copy-paste (which is what happened here) and the popular ones all offer you the ability to search and fill passwords from other domains. It's important to understand why they do, because it's also why these attacks continue to work: the user _thinks_ they are working around some kind of IT screwup, and 9 times out of 10 (probably closer to 99 out of 100) that's correct. Every marketing-driven hostname migration, every SSO failure, every front-end developer who breaks autofill, every “security expert” who was an accountant last year saying password managers are a vulnerability helps train users to think that it's not suspicious when you have to search for a different variation of the hostname or copy-paste a password.

That's why WebAuthn doesn't allow that as a core protocol feature, preventing both this attack and shifting the cost of unnecessary origin changes back to the company hosting the site. Attacking this guy for making a mistake in a moment of distraction is like prosecuting a soldier who was looking the other way when someone snuck past: wise leaders know that human error happens and structure the system to be robust against a single mistake.

Re: NPM debug and chalk packages compromised

#690

Post by chuckadams »

goku12 wrote: post #613
chuckadams wrote: post #327

Earlier quoted context omitted.

At least on a Mac, you can just double-click a cert file, it'll prompt to install in Keychain, and anything using macOS's TLS implementation will see it.

And what about the browser? How does it know which client cert (I assume the key is also there) to use for a site? Does it prompt you before proceeding with authentication?

The domains the cert gets presented to is also configured in Keychain, and Safari uses it. Looks like Firefox has its own thing, buried several layers deep in settings. No idea about chrome. It's definitely a process you'd want to script in an installer, nothing you'd want to subject the end user to. So yeah, still pretty crap UX overall.
Post reply on HN