Hacker News Reader

Comment by junon | Hacker News Reader

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

View on HN

@everyone in the industry, everywhere:

Urgency is poison.

Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on your users. Make one month's advance notice the golden standard.

I see this pattern in scam mail (including physical) all the time: stamp an unreasonably short notice and expect the mark to panic. This scam works - and this is why legit companies that try this "in good faith" should be shamed for doing it.

Actual alerts: just notify. Take immediate, preventive, but non-destructive action, and help the user figure out how to right it - on their own terms.

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

The email says accounts will start locking Sept 10th and it was sent Sept 8th - so a 48 hour urgency window or an account would be locked is urgency IMO

Fair enough, was just thinking about many low effort scams that have “EMERGENCY!!! ACT NOW!!!” in red boldface. This, by being slightly? less aggressive is actually less likely to trip my “this is phishing” detector. Obviously ymmv.

> The solution is to not use email.

and use what? instant message? few things lack legitimacy more than an instant message asking you to do something.

Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive.

the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. You depend on them. You ARE reviewing them, right? Fewer things to depend on is better than more, and NPM is very much an ecosystem where one is encouraged to depend on others as much as possible.

> the actual solution is to avoid dependencies whenever possible, so that you can review them when they change.

If you're publishing your software: you can't "not" depend on some essential service like source hosting or library index.

> You ARE reviewing them, right?

Werkzeug is 20kloc and is considered "bare bones" of Python's server-side HTTP. If you're going to write a complex Python web app using raw WSGI, you're just going to repeat their every mistake.

While at it: review Python itself, GCC, glibc, maybe Linux, your CPU? Society depends on trust.

Depends what you use it for. I don’t think email is a single thing in that regard. For example I’ve used it as a backup method for important files and also as 2 factor. Those are wholly different things that warrant different solutions. The majority of email volume is not person to person communication but part of some corporation/spammers/scammers business model who at best, like my bank, is using it to shift liability away from themselves onto consumers and at worst is attempting to defraud me of all I own. It’s still useful in business, maybe, but pretty sure teams/slack/… will win eventually.

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

And one pwned domain later, we are back in square one.

> And one pwned domain later, we are back in square one.

1. It's an extra step: before you pwn the package, you need to pwn a domain.

2. When a domain is pwned, the packages it signs can be revoked with a single command.

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.

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.

On the other hand, they did the actual work when nobody else did. It's so easy to take potshots, when you've never done anything consequential enough for the results to matter as much as they do for npm.

> X509 certificate

It should be a PGP or SSH key, absolutely not an X509 certificate (unless you allow self signed).

Personal identity keys should be fully autonomous and not contingent on the formal recognition of any external authority.

> The solution is to tie a package to an identity using a certificate.

Identity on the Internet is a lie. Nobody knows you're a dog.

The solution is to make security easy and accessible, so that the user can't be confused into doing the insecure thing.

> Identity on the Internet is a lie.

What do you think HTTPS is?

Transport Layer Security, and has nothing to do with Identity. Take for example the perfectly valid certificate that was issued for npmjs[.]help which unquestionably does not belong to Microsoft/GitHub. Hell, even the certificate for npmjs.com is 'O=Google Trust Services' which doesn't sound like any of the business entities one would expect to own that cert

"Whoever was on the cacert list that ships with your browser" has signed "I claim to be Acme Widgets Inc. and I own microsoft.com".

As long as you're OK with self signed certificates or PGP keys, I'd be on board with this.

I really, really dislike the idea of using TLS certificates as we know them for this purpose, because the certificate authority system is too centralized, hierarchical, and bureaucratic, tightly coupled to the DNS.

That system is great for the centralized, hierarchical, bureaucratic enterprises who designed it in the 90s, but would be a pain in the ass for a solo developer, especially with the upcoming change to 45 day lifetimes.

> As long as you're OK with self signed certificates or PGP keys, I'd be on board with this.

I am with PGP but more wary of self-signed certs, though even self-signed certs allow mass revocation of packages when an author's cert is compromised.

Can you post full message headers somewhere? It'd be interesting which MTA was involved in delivery from the sender's side.

Yep - https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee...

let's see the header of interest:

     Received: from npmjs.help by smtp.mailtrap.live

what about it?

How did simply opening this email in something like Gmail or a desktop client result in it being able to compromise NPM packages under your control?

I'm just curious - and as a word of warning to others so we can learn. I may be missing some details, I've read most of the comments on the page.

I clicked the link like a genius :)

:-( How did the link hijack your password/2fa? Or did you also enter some stuff on the form?

I don't understand. The link could've come from anywhere (for example from a HN comment). How does just clicking on it give your package credentials to someone else? Is NPM also at fault here? I'd naively think that this shouldn't be possible.

For example, GitHub asks for 2FA when I change certain repo settings (or when deleting a repo etc.) even when I'm logged in. Maybe NPM needs to do the same?

As OC mentioned elsewhere, it was a targeted TOTP proxy attack.

So, he clicked the link and then entered his correct TOTP? how would manually typing the url instead of clicking the link have mitigated this?

They wouldn't have manually typed the exact URL from the email, they would have just typed in npmjs.com which would ensure they ended up on the real NPM site. Or even if they did type out the exact URL from the email, it would have made them much more likely to notice that it was not the real NPM URL.

OP entered their credentials and TOTP code, which the attacker proxied to the real npmjs.com

FWIW npmjs does support FIDO2 including hard tokens like Yubikey.

They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages. iirc GitHub does force re-auth when you request an access token.

> They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages

I'm surprised by this. Yeah, GitHub definitely forces you to re-auth when accessing certain settings.

https://mailtrap.io/contact-details/

Thanks for sharing, I've created an OTX entry for this: https://otx.alienvault.com/pulse/68bf031ee0452072533deee6

Just looking for "const _0x112" as an IOC seems a bit false positive prone: https://github.com/search?q=%2Fconst+_0x112%2F+lang%3Ajs&typ... (most of that code is pretty dodgy obviously, but it's not unique enough to identify this).

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

is there an actual habituation?

that message feels like it could work as a first-time as well

We should be immediately suspicious when we get any solicitation to "renew" something "expired" in a security domain. Swapping un-compromised secrets is essentially always more risky than leaving them be.

Regardless of whether the real NPM had done this in the past, decades of dumb password expiration policies have trained us that requests like this are to be expected rather than suspected.

If legitimate companies didn't do this, then the email would be suspicious.

Yikes, looks legit. Curious what are the destination addresses? Would like to monitor them to see how much coin they are stealing.

In terms of presentation, yes. In terms of substance, short deadlines are often what separate phishing from legitimate requests.

There is NO reliable indicators, because every single one of these "Legit requests don't ..." recommendations has been done by a local bank trying to get their customers to do something.

My local credit union sent me a "please change your password" email from a completely unassociated email address with a link to the change password portal. I emailed them saying "Hey it looks like someone is phishing" and they said, "nope, we really, intentionally, did this"

Companies intentionally withhold warning emails as late as possible to cause more people to incur late fees. So everyone is used to "shit, gotta do this now or get screwed"

You can't hope to have good security when everyone's money is controlled by organizations that actively train people to have bad OPSEC or risk missing rent.

I agree: any of the potential indicators of phishing (whether it's poor presentation, incorrect grammar, tight deadlines, unusual "from" addresses, unusual domains in links, etc.) can easily have false positives which unfortunately dull people's senses. That doesn't mean they can't continue to be promulgated as indicators of possible (not definite) phishing, though.

I used the word "often" rather than "always" for this reason.

> There is NO reliable indicators

Completely agree. The only reliable way is to never use an email/SMS link to login, ever.

Or go ahead and use them, but abort if your password manager doesn't auto fill. Such abort scenarios include not only a password field without auto fill, but also a total lack of password field (e.g., sites that offer OTP-only authentication), since either way you don't have your password manager vetting the domain.

0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af

0x10ed43c718714eb63d5aa57b78b54704e256024e

0x13f4ea83d0bd40e75c8222255bc855a974568dd4

0x1111111254eeb25477b68fb85ed929f73a960582

0xd9e1ce17f2641f24ae83637ab66a2cca9c378b9f

Source: https://github.com/chalk/chalk/issues/656#issuecomment-32670...

Next comment:

> Those are swap contract addresses, not attacker addresses. E.g. 0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af the Uniswap v4 universal router addr.

> Every indication so far is that the attacker stole $0 from all of this. Which is a best-case outcome.

Oh, that makes much more sense - thanks!

There's a lot, looks like they start at line 103 in the gist here: https://gist.github.com/sindresorhus/2b7466b1ec36376b8742dc7...

And then what happens when you click the link? Wouldn't your password manager fail to auto fill your details?

This was mobile, I don't use browser extensions for the password manager there.

That green checkmark ... what application is this?

Migadu. The tooltip hovering over it shows:

    dkim=pass header.d=smtp.mailtrap.live header.s=rwmt1 header.b=Wrv0sR0r

check marks in email clients usually mean DKIM / other domain verification passed. The attack author truly owns npmjs.help, so a checkmark is appropriate.

Reply on news.ycombinator.com