Half of all JavaScript npm packages could have been hacked via weak credentials

https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/

by whitewalls • 9 years ago

128 37 9 years ago

bleepingcomputer.com

BenjaminCoe2• 9 years ago

worth mentioning, since this article npm has released two-factor authentication \o/

http://blog.npmjs.org/post/166039777883/protect-your-npm-acc...

make sure you turn it on.

micaksica• 9 years ago

I'm curious what the percentage of npm publishers that have this toggled on is, and I wish that was available data. First, in terms of all packages, and then of top 1000 packages. I'll wildly guess <0.5% of all packages, and <1% of top 1000. You don't get 2FA without the beta client right now anyway.

It's of no surprise to anyone that follows Node.js security at this stage that the third party dependency chain is really its biggest weak link. Jordan Wright did some good research a couple of months ago on Node dependency trees and malicious packages that's worth a read:

https://duo.com/blog/hunting-malicious-npm-packages

BenjaminCoe2• 9 years ago

I'm curious what the percentage of npm publishers that have this toggled on is, and I wish that was available data.

I know we're tracking this data and I bet a follow up post will be written at some point once some numbers are available. As you say, I expect 2fa will see wide adoption as soon as a stable version lands in the upstream Node.

paxy• 9 years ago

The problem with measures such as 2FA is that they are voluntarily implemented only by users who are most concerned about security, whereas users setting their password to "password" are on the opposite end of the spectrum.

What we really need is (1) 2FA and other enhanced security measures and (2) the ability to exclude all packages from a project, whether imported directly or indirectly, that do not abide with a minimum level of security.

cjcampbell• 9 years ago

I like the direction you’re heading with this, as it touches on supply-chain issues that have most folks just throwing their hands up. What would be most interesting is a standard framework for expressing a security policy combined with some hooks in the build tooling.

I also wonder whether it would be appropriate for the repositories themselves to hold maintainers to a minimum standard as well as their own claims. E.g., package maintainers must set a >12 character password and employ 2fa.

In reality, this isn’t just an NPM issue. I suspect that similar issues plague just about every package management framework, App Store, or CDN out there. Having a couple of standardized approaches would enable developers who care to automate checks and start to generate new incentives for the folks that are publishing their work to follow some basic standards.

infogulch• 9 years ago

This is exactly what is needed. Publish on each user's profile whether their account is secure, and provide an option in the client to disallow upgrading package versions owned by users that don't comply.

You could even try to crack the password of any user with enough (by some threshold) downloads using known leaked passwords as seeds, and mark them as insecure and reset their password if successful.

rtpg• 9 years ago

It seems like a no-brainer that any accounts on the main npm repos would _have_ to have 2FA enabled.

jessaustin• 9 years ago

You're talking about actions that security-minded parties could take already, if they cared to do so. Run your own registry, and audit everything that goes in, before it goes in. That would be a lot of work, but it would actually affect security to some degree. This idea that packages will be safe if only we inconvenience all package authors enough is just silly.

jlgaddis• 9 years ago

With a good password policy and mandatory 2FA and (GPG) signing, npm would actually be pretty damn trustworthy.

That's too much "friction", though, so I expect it to remain in this sorry state it has been in.

bsimpson• 9 years ago

I tried to use it over the weekend, but the CLI didn't recognize `npm profile`, even after I made sure I was on the latest version of npm.

peterwwillis2• 9 years ago

So, why is it they're not using certificates?

jclulow• 9 years ago

I can imagine this would lead to a rash of certificates committed to repositories on GitHub.

peterwwillis2• 9 years ago

My bad - I said certificates when I meant public key crypto. They would only check in a public key.

robocat• 9 years ago

The npm ecosystem is fundamentally insecure. Some highlights:

* I obtained accounts of 4 users from the top-20 list.

* One of those 4 users set their password back to the leaked one shortly after it was reset.

* 13 users [that I found the password for] had more than 50 million downloads/month.

* One of the users directly controlling more than 20 million downloads/month chose to improve their previously revoked leaked password by adding a ! to it at the end.

* While Skovoroda discovered credentials that granted him direct publish access to only 13% of npm packages, through dependencies, an attacker would have been able to spread his malicious code to about 52% of the entire npm ecosystem.

There is no bandaid to fix this structural issue.

epicide• 9 years ago

I don't see how any of these reasons are why npm is "fundamentally insecure" any more than any other system involving humans.

hayksaakian• 9 years ago

maybe there should be some type of 2 factor authorization to make sure you can't get in by guessing someone's insecure password, or grabbing it from a leak (due to password reuse).

stickfigure• 9 years ago

The npm community has a longstanding habit of depending on dynamic version numbers, eg "^1.2.3". Until the recent advent of package-lock.json, normal builds would pull in "whatever was latest"; any compromised upstream dependency would automatically propagate downstream as fast as their CI systems run. Also, builds are pretty much irreproducible.

The maven world, by contrast, is habituated to fixed version numbers for dependencies. A fake release might affect folks downstream that explicitly choose the upgrade, but it won't be automatic.

package-lock.json helps solve the technical problem, but the JS community still has a cultural problem because JS packages are typically fine-grained, released frequently, and upgraded without much thought.

always_good2• 9 years ago

What makes this a problem is that the NPM ecosystem has so many transitive dependencies. Which is why a left-pad fiasco can even happen in the first place.

vacri• 9 years ago

Perhaps look at an OS packaging system. Debian has a particularly robust one, and it simply couldn't be brute-forced like this (as it's key-based).

Even just simply forcing 2FA would be a significant improvement.

tristor• 9 years ago

That seems less of an indictment of npm and more an indictment of JS developers not caring about or understanding basic information security principles.

gsich• 9 years ago

What do you expect? The userbase requires stuff like isinteger and left-pad as packages, I don't think they are capable of understanding basic security concepts. On another note, NPM is rooting for companies instead of users as has been observed by the leftpad debacle.

megaman22• 9 years ago

We're building everything on quicksand. I'm constantly amazed anything ever works.

tomelders• 9 years ago

Heheh, welcome to JavaScript kid! Hold on tight!

goatlover• 9 years ago

Just wait till everything runs in a web browser. But by then you'll be able to convert your Rust program to web assembly to draw UIs on the canvas for VR apps.

inopinatus• 9 years ago

For those of us building anything that processes information with any level of sensitivity, it's not so funny. It's almost impossible to verify the integrity of JS dependencies.

I've had to adopt a policy of ignoring anything but the most carefully curated and dependency-minimised JS packages, and to avoid the language in general except when it can't be generally circumvented (i.e. in the browser).

msoad• 9 years ago

It's amazing that Node.js comes with a package manager that is not fully open source and is entirely controlled by a private corporation

NPM has some serious issues and unlike node itself we can't fix them because we don't have access to all of the source code.

Npm decided to auto close most of issues raised by its users in Github without addressing them. Many of those bugs still exist, even in the latest version.

It's a shame that the community of all those awesome package maintainers is being monetized by a corporation that is mostly dysfunctional and incompetent.

z3t42• 9 years ago

I think key based authorization should work great in NPM. Why are they not using keys ? Passwords should only be used to unlock keys.

k__• 9 years ago

Is this even a problem with a lockfile?

I mean even if an account is high jacked the packages must conform to a hash.

flavio812• 9 years ago

Obligatory HN reminder that the NPM system is crap and you shouldn't be using it.

dang• 9 years ago

Please don't post like this; it breaks the site guidelines and discredits both your point and you.

https://news.ycombinator.com/newsguidelines.html

This applies regardless of whether your underlying view is correct.

flavio812• 9 years ago

I'm sorry.

I should have said that NPM is fundamentally and essentially flawed, and that HN readers should not use it, favoring alternatives like Yarn instead.

Half of all JavaScript npm packages could have been hacked via weak credentials

Related Stories