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

751–760 of 796 posts

Re: NPM debug and chalk packages compromised

#751

Post by graemep »

hirako2000 wrote: post #743
graemep wrote: post #741

Earlier quoted context omitted.

> NEVER EVER login from an email link. EVER Login using one off email links (instead of username + password) is increasingly common which means its the only option.

At least you've requested that email, to be able to login. The timing chance for a phishing mail to come here and there is insignificant. OP is referring to communications that are one way street, the (pseudo) organisation to you.

Its a lot lower risk, its still not great IMO. Email is really not designed for it, and it trains people to use links to login.

Re: NPM debug and chalk packages compromised

#752

Post by typpilol »

acdha wrote: post #681
typpilol wrote: post #631

Earlier quoted context omitted.

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…

I wouldn't consider a .help domain to be a great choice.

Ive literally never for a support email or any email from a .help domain.

I'm not mocking them, just trying to understand how so many red flags slipped past.

Domain name No auto-fill Unannounced MFA resets Etc...

My point is that nothing could have saved this person except extreme security measures. There's literally no conclusion here besides:

1. Lock everything down so extremely that it's extremely inconvenient to prevent mistakes 99% of people don't make. (How many npm packages vs the total have been hijacked, less than 1%)

2. This person was always going to be a victim eventually... And that's a hard pill to swallow. For me and the maintainer. Being in network security it's my actual nightmare scenario.

The only lesson to be learned is you need extreme security measures for even the most experienced of internet users. This wasn't your grandma clicking a link, it's a guy who's been around for decades in the online / coding world.

It also makes me suspicious but that's a road I'd rather keep myself

Re: NPM debug and chalk packages compromised

#753

Post by const_cast »

mnahkies wrote: post #670
b112 wrote: post #641

Earlier quoted context omitted.

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)

Another advantage of this would be for CI/CD - MFA can be a pain for this. If I could have a publish token / oidc Auth in CI that required an additional manual approve in the web UI before it was actually published I could imagine this working well. It would help reduce risk from CI system breaches as well. There are already "package published" notification emails, it's just at that point it's too late.

Yes, exactly. A lot of these 2FA schemes or attestation schemes break automation, which is really undesirable in this particular scenario. Its tricky.

Re: NPM debug and chalk packages compromised

#754

Post by kngspook »

graemep wrote: post #751
hirako2000 wrote: post #743

Earlier quoted context omitted.

At least you've requested that email, to be able to login. The timing chance for a phishing mail to come here and there is insignificant. OP is referring to communications that are one way street, the (pseudo) organisation to you.

Its a lot lower risk, its still not great IMO. Email is really not designed for it, and it trains people to use links to login.

Yeah, I hate these. It's also a very not-ergonomic was to sign in. I wish those companies would redirect those efforts to passkeys.

Re: NPM debug and chalk packages compromised

#755

Post by kngspook »

diggan wrote: post #671
SchemaLoad wrote: post #556

Earlier quoted context omitted.

I feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished. I have to manually select the site to fill fairly often, especially inside apps where the password manager doesn't seem to match the app to the website password. Passkeys seem like the best solution here where you physically can not fall for a phishing attack.

> I feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished I dunno, it mostly seems to not work when companies change their field names/IDs, or just 3rd party authentication, then you need to manually add domains. Otherwise my password manager (1Password) works everywhere where I have an account, except my previous bank which was stuck in the 90s and disall…

My understand is the people behind passkeys are working on an import/export solution. Who knows when it'll happen though.

For now, when companies let me have multiple passkeys, that's sufficient for me. I put one on my Apple Keychain and one in 1Password.

Re: NPM debug and chalk packages compromised

#757

Post by cataflam »

graemep wrote: post #741
cataflam wrote: post #475

Earlier quoted context omitted.

Hey, you're doing an exemplary response, transparent and fast, in what must be a very stressful situation! I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA: TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough. I don't understand how mos…

> NEVER EVER login from an email link. EVER Login using one off email links (instead of username + password) is increasingly common which means its the only option.

In that case

1. You just requested it, I'm not saying to never click link on transactional emails you requested. You still need to click on those verify email links

2. It replaces entering your password, so you're not entering your password on a link from an email, which is the very wrong thing.

Re: NPM debug and chalk packages compromised

#758

Post by zestyping »

0xbadcafebee wrote: post #278

Here we are again. 12 days ago ( https://news.ycombinator.com/item?id=45039764 ) I commented how a similar compromise of Nx was totally preventable. Again, this is not the failure of a single person. This is a failure of the software industry . Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. W…

Interesting. According to https://www.wiz.io/blog/s1ngularity-supply-chain-attack the initial entry point was a "flawed GitHub Actions workflow that allowed code injection through unsanitized pull request titles" — which was detected and mitigated on August 29.

That was more than ten days ago, and yet major packages were compromised yesterday. How?

Re: NPM debug and chalk packages compromised

#759

Post by NamlchakKhandro »

aerodynamic_ wrote: post #269
joaomoreno wrote: post #129

From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-32668...

convenience script that checks through package.json dependency tree + a couple malicious binary patterns: https://gist.github.com/edgarpavlovsky/695b896445c19b6f66f14...

doesn't work for monorepos
Post reply on HN