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

641–650 of 796 posts

Re: NPM debug and chalk packages compromised

#641

Post by b112 »

SchemaLoad wrote: post #568
rtpg wrote: post #504

Earlier quoted context omitted.

I have a hard time arguing that 2FA isn't a massive win in almost every circumstance. Having a "confirm that you have uploaded a new package" thing as the default seems good! Someone like npm mandating that a human being presses a button with a recaptcha for any package downloaded by more than X times per week just feels almost mandatory at this point. The attacks are still possible, but they're not going to be nearl…

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)

Re: NPM debug and chalk packages compromised

#642

Post by darkamaul »

paxys wrote: post #422

Yeah I know "everyone can be pwned" etc. but at this point if you are not using a password manager and still entering passwords on random websites whose domains don't match the official one then you have no business doing anything of value on the internet.

I get the sentiment behind 'just use a password manager', but I don’t think victim-blaming should be the first reflex. Anyone can be targeted, and anyone can fail, even people who do 'everything right'.

Password managers themselves have had vulnerabilities, browser autofill can fail, and phishing can bypass even well-trained users if the attack is convincing enough.

Good hygiene (password managers, MFA, domain awareness) certainly reduces risk, but it doesn’t eliminate it. Framing security only as a matter of 'individual responsibility' ignores that attackers adapt, and that humans are not perfect computers. A healthier approach would be: encourage best practices, but also design systems that are resilient when users inevitably make mistakes.

Re: NPM debug and chalk packages compromised

#643

Post by discomrobertul8 »

junon wrote: post #471
nromiun wrote: post #61

I have nothing to do with this but still I am getting second hand embarrassment. Here is an example, is-arrayish package, 73.8 MILLION downloads per week. The code? 3 lines to check if an object can be used like an array. I am sorry, but this is not due to not having a good standard library, this is just bad programming. Just pure laziness. At this point just blacklist every package starting with is-.

I wrote it 10 years ago, I think before Node was v1, and forgot about it for a long time. This was back before we had spreads, classes, typescript, and had to use DOM arrays and other weird structures, and where `arguments` wasn't an array but an object. > (function() { return Array.isArray(arguments); })() false

Do you think it might be time to deprecate and then retire this package, given that the ecosystem has evolved? Sure, it'll mean downstream packages will need to update their reliance on `is-arrayish` and use some other means suited to their task, but perhaps that's positive design pressure?

Re: NPM debug and chalk packages compromised

#644

Post by sneak »

hdjrudni wrote: post #626
yawaramin wrote: post #598

Earlier quoted context omitted.

I'm angry about this. Large megacorps with the budget of medium-sized countries allocate the minimum amount of budget to maintain their auth systems and still allow the use of phishable auth methods. If npm disabled passwords and forced people to use passkeys, this huge problem just disappears tomorrow. But instead, we're left with this mess where ordinary developers are forced to deal with the consequences of gettin…

Passkeys can be a pain in the ass too. Evidentially I set up my Yubikey with Github as some point, which is fine if I'm at my desktop where my key is plugged in, but if I want to sign in on mobile.... now what? I just couldn't log in on mobile for months until I realized I think there's a button on there somewhere that's like "use different 2fa" but then what was even the point of having a key registered if it can be…

You can use software u2f (iCloud supports this), you don’t need Yubikeys.

Also, Yubikeys work on phones just fine, via both NFC and USB.

Re: NPM debug and chalk packages compromised

#645

Post by sneak »

acdha wrote: post #544
sneak wrote: post #472

Earlier quoted context omitted.

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…

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.

Re: NPM debug and chalk packages compromised

#646

Post by sneak »

junon wrote: post #473
sneak wrote: post #472

Earlier quoted context omitted.

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…

I use a password manager. I was mobile, the autofill stuff isn't installed as I don't use it often on my phone. In 15 years of maintaining OSS, I've never been pwned, phished, or anything of the sort. Thank you for your input :)

I never copy and paste passwords. Any time you find yourself wanting to do that, alarm bells should be ringing.

Password managers can’t help you if you don’t use them properly.

Spotify steals (and presumably uploads) your clipboard, as well as other apps. Autofill is your primary defense against phishing, as you (and hopefully some others) learned this week.

Re: NPM debug and chalk packages compromised

#647

Post by Tarq0n »

paxys wrote: post #422

Yeah I know "everyone can be pwned" etc. but at this point if you are not using a password manager and still entering passwords on random websites whose domains don't match the official one then you have no business doing anything of value on the internet.

Have you used a Microsoft product lately? So many bigco's publishing their org chart as login domains.

Re: NPM debug and chalk packages compromised

#648

Post by lelanthran »

dabockster wrote: post #515
lelanthran wrote: post #376

Earlier quoted context omitted.

> The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.

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 online anyway. The new/updated/replacement package will have to be signed. The signature must be verified by the upload script/handler. The verification can be done using the X509 certificate issued for the domain of the contributor.

1. If the contributor cannot afford the few dollars a year for a domain, they are extremely vulnerable to the supply chain attack anyway (by selling the maintenance of the package to a bad actor), and you shouldn't trust them anyway.

2. If the contributor's domain gets compromised you only have to revoke that specific certificate, and all packages signed with that certificate, in the past or in the future, would not be installable.

As I have repeatedly said in the past, NPM (and the JS tools development community in general) had no adults in the room during the design phase. Everything about JS stacks feels like it was designed by children who had never programmed in anything else before.

It's a total clown show.

Re: NPM debug and chalk packages compromised

#650

Post by dns_snek »

bix6 wrote: post #21
andrewmcwatters wrote: post #15

@junon, if it makes you feel any better, I once had a Chinese hacking group target my router and hijack my DNS configuration specifically to make "amazon.com" point to 1:1 replica of the site just to steal my Amazon credentials. There was no way to quickly visualize that the site was fake, because it was in fact, "actually" amazon.com. Phishing sucks. Sorry to read about this. Edit: To other readers, yes, the exploit…

Any write up? I would like to learn more to avoid.

The exact attack they described is less of an issue these days due to HSTS and preloading, but:

- make sure you're connected to the expected official domain (though many companies are desensitizing us to this threat by using distinct domains instead of subdomains for official business)

- make sure you're connected over HTTPS (this was most likely their issue)

- use a password manager which remembers official domains for you and won't offer to auto-fill on phishing sites

- use a 2FA method that's immune to phishing, like passkeys or security keys (if you do this, you get a lot of leniency to mistakes everywhere else)

Post reply on HN