Is https://www.virustotal.com good? I saw it referenced but never used
Yes.
There's signal if there's detections
There's signal if something is old and there's no detections
There's no signal if something is recent with no detections
Embedded Malware in Coa
31–40 of 86 posts
Re: Embedded Malware in Coa
#32How do you add a new version to npm? Was the devs account hacked or how does that work?
The most common ways these things seem to happen is either password reuse with no 2fa or that the npm token (in ~/.npmrc) was harvested by another compromised package/program. IIRC there were a few that were due to phishing too.
Almost certainly one of these. It's not a typosquatting attack, since it's an existing package. And it's not a repository compromise, since they had to create new versions instead of silently altering an existing version.
Re: Embedded Malware in Coa
#33As bad as this may sound, this is why a love Open Source, npm and the JavaScript ecosystem. It super easy to audit and check the code. What is missing is more automated and recurrent checks in all the packages and downstream dependencies.
This is a really odd comment. Npm, and the strange, insecure JavaScript packaging ecosystem is the reason this happened in the first place.
I don't see how this is an NPM issue at all. If the attacker made a Linux version and stuck it inside a Makefile, plenty of devs and build servers would end up executing the malicious code.
Re: Embedded Malware in Coa
#34Reminder that people should seriously consider disabling the install-scripts.
Personal system-wide config:
npm/yarn config set ignore-scripts true -g
ignore-scripts true
And yes yes, as people love to point out, this isn't exactly a bulletproof solution either. The attacker could just put the malicious code inside the package's code and wait for it to be actually executed. But again and again, they don't, they choose to use the package's install scripts as the place to do their dirty work.
So in practice this policy would've alrady protected you from who knows how many of these attacks, and my guess is that it'll continue to do so.
Re: Embedded Malware in Coa
#35What a worthless advisory, how about sharing who could possibly be affected at the very top, or at least anywhere? Going to the issue, it seems the `preinstall` field was changed to `start /B node compile.js & node compile.js",` which means this would only run on Windows machines, everyone else seems to be unaffected. Here is how you can find out if you have the affected package on your machine/instance: find ~/proje…
-name "*coa*" is a bit too eager. It will flag other packages too, like the fairly popular babel-plugin-nullish-coalescing
If you have an index for the locate command it's probably easier to do:
locate "/coa/package.json" | xargs -I {} jq .version {} 2>/dev/null
Re: Embedded Malware in Coa
#36As bad as this may sound, this is why a love Open Source, npm and the JavaScript ecosystem. It super easy to audit and check the code. What is missing is more automated and recurrent checks in all the packages and downstream dependencies.
This is a really odd comment. Npm, and the strange, insecure JavaScript packaging ecosystem is the reason this happened in the first place.
What makes npm more insecure than other packaging systems?
Re: Embedded Malware in Coa
#37As bad as this may sound, this is why a love Open Source, npm and the JavaScript ecosystem. It super easy to audit and check the code. What is missing is more automated and recurrent checks in all the packages and downstream dependencies.
I just can't agree with this. The problems npm has are not new, surprising ones. They are happily letting people upload malware. https://my.diffend.io/npm/coa/2.0.3/2.0.4/ In 2021, why on earth does such a change not trigger a review before release?
Trigger a review where and by who?
Re: Embedded Malware in Coa
#38It seems that all of these should be cryptographically signed by a developer's private key before publication and then verified by others before use. Is that not the case?
I agree that all software package repositories -- NPM, Rubygems, PyPI, Maven, NuGet, Crates, etc -- should have two minimum baseline security policies:
1. All accounts are MFA, no exceptions.
Only CI/CD usecases justify some laxity. Only push tokens should be non-MFA-able for CI/CD purposes, and they should only be usable for push. Tokens should only be obtainable with MFA.
Ideally these too would be part of a multi-step OAuth2 or OIDC refresh token to access token flow, so that any given access token is only used once and CI/CD jobs never get to see the refresh token.
And while we're on tokens: they should all expire, after a short period of time, without exception.
2. Signing packages is opt-out, not opt-in.
The two reasons package signing is relatively rare are that (1) in most ecosystems it is unwieldy, (2) not actually that effective at providing guarantees (self-signed certs are no better than a pinky promise).
But once these are solved, and I believe they can be, making signing opt-out means that we'd see signing rate percentages in the 90s, instead of languishing in single digits as they do today.
If you work on NPM and would like to swap notes, I would love to talk to you with my professional hat on -- email in profile.
Re: Embedded Malware in Coa
#39Why can’t there just be multiple curated repositories like how Linux distros do it?
Having NPM just be a free-for-all is a ticking time bomb. It is only a matter of time before an event like this results in something very serious.
Re: Embedded Malware in Coa
#40Earlier quoted context omitted.
This is a really odd comment. Npm, and the strange, insecure JavaScript packaging ecosystem is the reason this happened in the first place.
What makes npm more insecure than other packaging systems?
I would say that it's not that different from others I've seen, just more visible because of the size and activity of the repository.
One thing NPM does (and I believe Python too) is to allow install scripts -- this has been a reliable vector for attackers to steal credentials. Not every package repository system has that.