Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

301–310 of 796 posts

Re: NPM debug and chalk packages compromised

#301
post #43

Developer account got hijacked through phishing. @junon acknowledged this readily and is trying to get it sorted. Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight. So let me raise a different concern. This looks like an exploit for web browsers, where an average user (and most above average users) have no clue as to what's running unde…

> - How do the end user protect themselves at this point? Especially the average user?

- Install as little software as possible, use websites if possible.

- Keep important stuff (especially cryptocurrency) on a separate device.

- If you are working on a project that pulls 100s of dependencies from a package registry, put that project on a VM or container.

Re: NPM debug and chalk packages compromised

#302

Earlier quoted context omitted.

But then you depend on Microsoft for everything. I prefer python where it's battery Included but you depend on a foundation

Hasn't .net been open-source for like 10 years?

It is, but it's still firmly controlled by Microsoft, particularly when it comes to ecosystem evolution. Some people find that uncomfortable even if the source is open - legal right to fork is one thing, technical ability to do so and maintain said fork is another.

Re: NPM debug and chalk packages compromised

#303

NPM deserves some blame here, IMO. Countless third party intel feeds and security startups can apparently detect this malicious activity, yet NPM, the single source of truth for these packages, with access to literally every data event and security signal, can't seem to stop falling victim to this type of attack? It's practically willful ignorance at this point.

Identical, highly obfuscated (and thus suspicious looking) payload was inserted into 22+ packages from the same author (many dormant for a while) simultaneously and published.

What kind of crazy AI could possible have noticed that on the NPM side?

This is frustrating as someone that has built/published apps and extensions to other software providers for years and must wait days or weeks for a release to be approved while it's scanned and analyzed.

For all the security wares that MS and GitHub sell, NPM has seen practically no investment over the years (e.g. just go review the NPM security page... oh, wait, where?).

Re: NPM debug and chalk packages compromised

#304

Earlier quoted context omitted.

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,…

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.

Re: NPM debug and chalk packages compromised

#305
post #124
post #59

Earlier quoted context omitted.

how about: grep -r "_0x112fa8"

Irritatingly, this doesn't turn up anything, despite having a theoretically-compromised project as per the package-lock.json… At least on my end

If you had the dependency installed before this attack, then you would still be pinned to an old safe version.

Re: NPM debug and chalk packages compromised

#306

Earlier quoted context omitted.

I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years. Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and sc…

> The responses vary but often take the form of reused cliches of which some don't even directly apply. "It has been tested by a 1000 people before me" "What if there is an upstream optimisation?" "I'm just here to focus on Business Problems™" "It reduces cognitive load" --- Whilst I think you are exaggerating, I do recognise this phenomenon. For me, it was during the pandemic when I had to train / support a lot of b…

> They were anxious to perform in their new career and interpreted that as shipping tickets as fast as possible. [...].. they had like, no drive at all to engage with problems

To be honest, I think these programmers understood their jobs perfectly here. Their bosses view programmers as commodities, are not concerned with robustness, maintainability, or technical merit - they want a crank they can turn that spits out features.

Re: NPM debug and chalk packages compromised

#307
post #119

Earlier quoted context omitted.

Did they also phish the login password after clicking the link or did they already have it?

They phished username, password (unique to npm), and a TOTP code. They even gave me a new TOTP code to install (lol) and it worked. Showed up in authy fine. Whoever made this put a ton of effort into it.

[deleted]

Re: NPM debug and chalk packages compromised

#308
post #253
post #202

Earlier quoted context omitted.

I clicked the link like a genius :)

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?

[deleted]

Re: NPM debug and chalk packages compromised

#309
post #260
post #253

Earlier quoted context omitted.

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?

Re: NPM debug and chalk packages compromised

#310

Earlier quoted context omitted.

I'm a pretty big fan of BitWarden/VaultWarden myself... though relatively recently something changed on my Android phone in that the password fills aren't working from inside my browser, I have to copy/paste from the app, which is not only irritating but potentially less safe.

Consider adding the widget/action to your quick actions: then to don't need to copy paste at least

For those of us unfamiliar, can you describe the resulting UI pattern? Do you give focus to the password field and then tap a button at the top of the notification shade which automatically types (or gives a choice, if multiple are saved) whatever the password manager has for that site? I'm slightly surprised that something running in that context would know what site the browser has open.
Post reply on HN