Earlier quoted context omitted.
You rely on LLMs riddled with hallucinations for malware detection?
> We use a mix of static analysis and AI. Flagged packages are escalated to a human review team. “Chat, I have reading comprehension problems. How do I fix it?”
NPM debug and chalk packages compromised
781–790 of 796 posts
Re: NPM debug and chalk packages compromised
#782Earlier quoted context omitted.
Then good password managers will still show you only the logins for that domain. If the login is on another domain then you would have saved it anyways when first logging in/registering and if the site moved then you can get suspicious and check carefully first.
What are good password managers for chrome and Firefox on Android?
Re: NPM debug and chalk packages compromised
#783Earlier quoted context omitted.
As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal. Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.
This isn't part of the current discussion, but what is the appeal of single-header libraries? Most times they actually are a normal .c/.h combo, but the implementation was moved to the "header" file and is simply only exposed by defining some macro. When it is actually a like a single file, that can be included multiple times, there is still code in it, so it is only a header file in name. What is the big deal in act…
And generally it's one less file to look at, more easy to copy-paste into your project (and as a very minor security benefit you'll potentially look at arbitrary subsets of the contents every time you do a go-to-definition or use the header as docs (thus having chances to notice oddities) instead of just looking at a header).
Re: NPM debug and chalk packages compromised
#784Earlier quoted context omitted.
FWIW, is-arrayish is primarily an internal dependency. The author (Qix) depends on it for the packages that actually get used, liked color and error-ex. But it's all one author.
It might be an internal dependency for this author, but package.json is only for direct dependencies, right? github shows is-arrayish is a direct dependency of thousands of repos: https://github.com/search?q=%22is-arrayish%22+path%253Apacka...
Vast majority are nothing. No stars, no downloads.
(IDK why. What I do know is that if you crack open the node_modules for any real project, is-arrayish will be there only because of one of the Qix packages.)
[1] https://www.npmjs.com/package/is-arrayish?activeTab=dependen...
Re: NPM debug and chalk packages compromised
#785Earlier quoted context omitted.
Username/password typically has the same issue via reset password links.
I agree. However you use them less often, so its far harder for someone to time it right. If you use username instead of email address attackers have to guess that too. One quite serious problem I see quite often is using email plus password for login, and notifying on failed login that the email is not in the system, letting attackers validate which emails are logins.
And this is exactly the kind of phishing attack that is most effective, as this particular incident shows. So I'd say it's actually a worse phishing vector than magic links.
Re: NPM debug and chalk packages compromised
#786Earlier quoted context omitted.
I see (I think): they tricked you into entering a TOTP code into their site, which they then proxied to the real names, thereby authenticating as your account. Is that correct?
It only proves that TOTP is useless against phishing.
The extension from https://authenticator.cc, with smart domain match enabled, would have caught this by showing all other TOTP codes besides the one intended by NPM.
On a Mac, Keychain would also have caught this by not autofilling: https://support.apple.com/en-ph/guide/passwords/mchl873a6e72...
Re: NPM debug and chalk packages compromised
#787Earlier quoted context omitted.
Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.
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…
Re: NPM debug and chalk packages compromised
#788Earlier quoted context omitted.
Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.
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…
You forgot to mention that you are both highly skilled and practiced at phishing yourself... don't you think that helps too?
Re: NPM debug and chalk packages compromised
#789Earlier quoted context omitted.
So how do you detect these attacks?
We use a mix of static analysis and AI. Flagged packages are escalated to a human review team. If we catch a malicious package, we notify our users, block installation and report them to the upstream package registries. Suspected malicious packages that have not yet been reviewed by a human are blocked for our users, but we don't try to get them removed until after they have been triaged by a human. In this incident,…
Re: NPM debug and chalk packages compromised
#790Earlier quoted context omitted.
>What about packages that are not "flagged"? You can't catch everything with normal static analysis either. LLM just produces some additional signal in this case, false negatives can be tolerated.
static analysis DOES NOT hallucinate.
when static analysis does it, it's called a "misclassification"