Hacking 20 High-Profile Dev Accounts Could Compromise Half of the NPM Ecosystem (zdnet.com) 17
The npm ecosystem of JavaScript libraries is more interwoven than most developers think, and the entire thing is a gigantic house of cards, being one bad hack away from compromising hundreds of thousands of projects, according to a recent academic study. From a report: The research, carried out by the Department of Computer Science from the Technical University of Darmstadt, in Germany, analyzed the dependency graph of the entire npm ecosystem. Researchers downloaded metadata for all the npm packages published until April 2018 and created a giant graph that included 676,539 nodes and 4,543,473 edges (lines connecting the nodes). In addition, academics also analyzed different versions of the same packages, looking at historical versions (5,386,239 versions for the 676,539 packages), but also at the package maintainers (199,327 npm accounts), and known security flaws impacting the packages (609 public reports). [...]
Their goal was to get an idea of how hacking one or more npm maintainer accounts, or how vulnerabilities in one or more packages, reverberated across the npm ecosystem; along with the critical mass needed to cause security incidents inside tens of thousands of npm projects at a time. [...] But while some npm packages load code from too many packages and from too many developers, there is another dangerous trend forming on the npm package repository -- namely the consolidation of popular npm packages under a few maintainer accounts. "391 highly influential maintainers affect more than 10,000 packages, making them prime targets for attacks," the research team said. "If an attacker manages to compromise the account of any of the 391 most influential maintainers, the community will experience a serious security incident."
Their goal was to get an idea of how hacking one or more npm maintainer accounts, or how vulnerabilities in one or more packages, reverberated across the npm ecosystem; along with the critical mass needed to cause security incidents inside tens of thousands of npm projects at a time. [...] But while some npm packages load code from too many packages and from too many developers, there is another dangerous trend forming on the npm package repository -- namely the consolidation of popular npm packages under a few maintainer accounts. "391 highly influential maintainers affect more than 10,000 packages, making them prime targets for attacks," the research team said. "If an attacker manages to compromise the account of any of the 391 most influential maintainers, the community will experience a serious security incident."
391 seems to be a little too high (Score:2)
Re: (Score:3, Funny)
Of course, this is all only relevant to the hypothetical scenario where the NPM ecosystem wasn't already entirely compromised by node.js coders.
Oh great (Score:3)
"Researchers downloaded metadata for all the npm packages published until April 2018 and created a giant graph that included 676,539 nodes and 4,543,473 edges (lines connecting the nodes). "
Great, now the bad guys know just where to concentrate their efforts.
Re: (Score:2)
Are you suggesting that this is out of the usual line of work for intelligence agencies? ;)
Re: (Score:2)
Are you suggesting that this is out of the usual line of work for intelligence agencies? ;)
Nope, just observing that there are lots of scumbags out there who will work hard to weaponize this data.
Re: (Score:1)
Re: (Score:2)
Re:Oh great (Score:4, Interesting)
It's the same logic as security researchers investigating flaws in software or even hardware, like RowHammer. "Oh great, now the bad guys have a new tool!"
But public acknowledgment of a potential vulnerability is the first step in securing it. Zero-days are a thing, you know. Bad guys sometimes discover these weaknesses first. Every vulnerability a white hat researcher finds and publishes is one less potential zero-day exploit.
Yes, it increases vulnerability for a short window, but we're more resistant to / aware of that particular threat afterwards, so long as effort is put into mitigation. Not a perfect solution, but it's not a perfect world.
Re: (Score:2)
Yes, it increases vulnerability for a short window, but we're more resistant to / aware of that particular threat afterwards, so long as effort is put into mitigation. Not a perfect solution, but it's not a perfect world.
No, I totally understand. As I said, I was just observing that there are lots of scumbags out there who will work hard to weaponize this data.
Re: (Score:3)
Didn't mean to preach to the choir, as I read your comment in a different way. But you're right, of course. It's really a shame that, for every piece of cool new technology, we not only have all the technical problems to solve, but we have to ask ourselves "How could this be abused or turned into a weapon?"
I always envision being able to go back to whoever was coming up with these "great" new ideas, such as embedding a scripting language in documents. Or allowing someone to attach an executable file as a
I'm fine with this (Score:5, Insightful)
Every now and then I try to get the Node Religion and install a few projects in a VM. The first time I run npm and watch it download The Entire Internet + Kitchen Sink, my bowels unleash and I go back to being a pagan again.
I give npm credit for making a framework that works so well at maintaining dependencies that the toilet clogger mass of files it handles doesn't fall over every other week. But otherwise it just gives me The Fear.
Re: (Score:3)
> The first time I run npm and watch it download The Entire Internet + Kitchen Sink,
Not just npm. Replace npm with gradle or brew or pip and we start to see the same crap as well.
At least brew seems to be much more sensible.
Re: (Score:2)
Or apt, or whatever RedHat uses this week or....
Most programmers have been so steeped in "don't reinvent the wheel" that they'll include a gig of dependencies to add two numbers together.
That's not the fault of the package manager.
node.js is one hell of a security issue (Score:4, Interesting)
Remember why it was created. Basically, the market was full of web developers who could do javascript but nothing else, and suddenly there was no longer a need for frontend developers. But there was a severe shortage of backend people. Conclusion? node.js.
What you get out of this is self-trained "I can has webpage!" scripters that live by the creed "it displays what it should at least most of the time, good enough for production" not only on the frontend but also on the backend.
You know what the average webpage code looks like? Do an audit of your favorite "edgy" webpage code. What you'll find is quite a bit of javascript libraries held together by haphazard code that somehow strings them together. Which is basically more or less secure mostly because the libraries get so many eyeballs that at least the glaring security holes are eventually caught and the code that strings them together usually doesn't have enough functionality to fuck it up too badly. But don't worry, wherever possible it probably is.
Now imagine the exact same code, written by the exact same people, being run on servers where the potential damage is considerably higher with the amount of eyeballing done considerably lower because no sane person with at least some security background touches javascript unless he gets paid good money for it. I think the legal term for it is "solatium".
And you think that the companies that hire ex-webdevs as backend developers because they're cheaper "waste" money on a security audit?
fine (Score:1)