Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

631–640 of 796 posts

Re: NPM debug and chalk packages compromised

#631
post #544
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…

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

Re: NPM debug and chalk packages compromised

#632
post #485

Earlier quoted context omitted.

Or you know, get a password manager like the rest of us. If your password manager doesn't show the usual autofill, since the domain is different than it should, take a step back and validate everything before moving on. Have the TOTP in the same/another password manager (after considering the tradeoffs) and that can also not be entered unless the domain is right :)

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.

This is how Troy Hunt got phished. He was already very tired after a long flight, but his internal alarm bells didn't ring loud enough, when the password manager didn't fill in the credentials. He was already used to autofill not always working.

Re: NPM debug and chalk packages compromised

#634
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…

Happens to the best of people. Appreciate you’re fast and open response.

Re: NPM debug and chalk packages compromised

#636

Earlier quoted context omitted.

And it's not like it would hurt the developers to be conscious of their choices.

There's actually nothing the developers can do about this particular issue other than to display all colors and allow colorblind people to see the colors that they can see.

For the newly made up feature, which doesn't exist yet, but already has an issue?

Simple. Instead of forcing colour, one could retain a no colour option maybe?

Done. Solved.

Everything should have this option. I personally have no colour vision issues, other than I find colour annoying in any output. There's a lot who prefer this too.

Re: NPM debug and chalk packages compromised

#637

Earlier quoted context omitted.

> This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit ... I don't agree that the exuberance over the brilliance of this attack is warranted if you give this a moment's thought. The web has been fighting lookalike attacks for decades. This is just a more dynamic version of the same. To be honest, this whole post has the ring of AI wr…

> To be honest, this whole post has the ring of AI writing, not careful analysis. It has been what, hours? since the discovery? Are you expecting them to spend time analysing it instead of announcing it? Also, nearly everyone has AI editing content these days. It doesn’t mean it wasn’t written by a human.

Just for a counter, "nearly everyone" seems wildly ambitious.

I want no part of AI in any form of my communication, and I know many which espouse the same.

I will certainly agree on "many", but not "nearly everyone".

Re: NPM debug and chalk packages compromised

#638

Earlier quoted context omitted.

For a package with thousands of downloads a week, does the publishing pace need to be so fast? New version could be uploaded to NPM, then perhaps a notification email to the maintainer saying it will go live on XX date and click here to cancel?

A standard release process for Linux distro packages is 1) submitting a new revision, 2) having it approved by a repository maintainer, 3) it cooks a while in unstable, 4) then in testing, and finally 5) is released as stable. So there's an approval process, a testing phase, and finally a release. And since it's impossible for people to upload a brand new package into a package repository without this process, typosq…

It's a problem solved decades ago, as you say. Devs, not caring about security or trust, just found it inconvenient.

This will probably be reigned in soon. Many companies I know are backing away from npm/node, and even composer. It's just too risky an ecosystem.

Re: NPM debug and chalk packages compromised

#639
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.

How does someone intelligent with 2FA get pwned? Serious question.

Thinking you're above getting pwned is often step one :)

It's not easy to be 100% vigilant 100% of the time against attacks deliberatly crafted to fall for them. All it takes is a single well crafted attack that strikes when you're tired and you're done.

Re: NPM debug and chalk packages compromised

#640
One reason why i run everything on my development machine in a docker container, you can't trust any package.

I use bun, but similar could be done with npm

Add to .bashrc:

  alias bun='docker run --rm -it -u $(id -u):$(id -g) -p 8080:8080 -v "$PWD":/app -w /app my-bun bun "$@"'
then you can use `bun` command as usual.

Dockerfile:

  FROM oven/bun:1 AS base
  VOLUME [ "/app" ]
  EXPOSE 8080/tcp
  WORKDIR /app
  # Add your custom libs
  # RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get -y install \
  #  ... \

Create once the container:

  $ docker build -t "my-bun" -f "Dockerfile" .
Post reply on HN