'One In Two New Npm Packages Is SEO Spam Right Now' (sandworm.dev) 37
Gabi Dobocan, writing at auditing firm Sandworm: More than half of all new packages that are currently (29 Mar 2023) being submitted to npm are SEO spam. That is - empty packages, with just a single README file that contains links to various malicious websites. Out of the ~320k new npm packages or versions that Sandworm has scanned over the past week, at least ~185k were labeled as SEO spam. Just in the last hour as of writing this article, 1583 new e-book spam packages have been published. All the identified spam packages are currently live on npmjs.com.
How does one distinguish (Score:4, Funny)
Re:How does one distinguish (Score:5, Funny)
Spam from JavaScript? Joking not joking.
Well if its node.js one can just assume its pure goodness for your server. ;-)
Re: (Score:1)
Mr. Abbott is a crook and a pathological liar.
Re: (Score:2)
Spam uses English words, mostly. JavaScript uses variables and various kinds of brackets and punctuation.
I have to say it (Score:3)
But this is why we can't have nice things.
Re:I have to say it (Score:5, Insightful)
npm was never nice things.
Just need a ruthless bastard to reject things ... (Score:5, Insightful)
Re:Just need a ruthless bastard to reject things . (Score:4, Interesting)
Think the Debian apt repo maintainer group would be a better example....
Re: (Score:1)
Re:Just need a ruthless bastard to reject things . (Score:4, Insightful)
No it wouldn't. They let Lennart Pottering submit stuff.
Re: (Score:2)
No it wouldn't. They let Lennart Pottering submit stuff.
Of course they did. He made stuff they like and made their job easier. You seem to think that Debian exists for the users. It doesn't It exists the way the *maintainers* want it to exist.
You dear user are free to accept it, or go fork yourself (Yeah I feel clever for having come up with that. :-) )
Re: (Score:2)
Think the Debian apt repo maintainer group would be a better example....
People who don't like Systemd would disagree with you.
Re: (Score:3)
Or alternately create both a tool to process submitted projects for their code, and a style-guide and associated processing tool for the README with very rigid rules governing the type and layout of content, that requires something like 95% of the document to be an actual description and instruction set, with only 5% allowed to be links.
For the latter, set it up in tandem with a web page fillable form. Give package maintaners the option to either 1) submit their README through the fillable form not dissimi
Re: (Score:1)
Re: (Score:1)
There's nothing nice about NPM. The whole reason this is happening is because it is, and always was, fucking awful.
why not automatically removed? (Score:4, Interesting)
You're right. (Score:2)
This doesn't really sound like that much of a problem. 2FA, account validation & bot-check for publishing to npm actual, some graylisting/blacklisting of hosts, perhaps some firewall service to flag suspicious activity and some plausibility checks for newly published packages.
This should be public archive maintenance and protection 101, no? Nothing a good team of maintainers couldn't solve in a few sessions. That's my impression anyway.
Re: You're right. (Score:2)
Re: (Score:3)
Why not automatically removed? Seems pretty simple to classify these.
If npm creates a simple automatic classifier, you can be sure that within a day the bad actors will come up with new submissions that thwart the classifier. It'll be a never-ending whack-a-mole that npm are doomed to lose, because economic incentives are against them -- they don't gain much additional revenue to offset the cost of the full time employees they need to beat the bad actors, while the bad actors have an easier job and directly make money.
Re: (Score:3)
If npm creates a simple automatic classifier, you can be sure that within a day the bad actors will come up with new submissions that thwart the classifier. It'll be a never-ending whack-a-mole that npm are doomed to lose, because economic incentives are against them -- they don't gain much additional revenue to offset the cost of the full time employees they need to beat the bad actors, while the bad actors have an easier job and directly make money.
You don't have to make it hard enough that the bad actors can't abuse it profitably -- you just have to make it hard enough that it's easier for the bad actors to just go somewhere else. Sort of like "I don't have to outrun the bear -- I just have to outrun you."
You know what solves this? (Score:3)
A workflow.
New accounts w/ new submissions - must get reviewed and approval before being added.
Existing accounts w/ good standing - auto-approval.
Re:You know what solves this? (Score:5, Insightful)
The real question is why you need to pull in so many third party libraries. How on earth was software ever written in the decades before this nonsense?
Re: (Score:2)
Before this nonsense, developers copied and pasted snippets of code. These snippets had security vulnerabilities when exposed to untrusted input, and there was no central way to update all uses of a particular snippet.
Re: (Score:2)
Now, we introduce security vulnerabilities with ruthless efficiency!
Seriously. Security is a reason to avoid importing a ton of third-party code.
there was no central way to update all uses of a particular snippet
Most sensible organizations maintained their own library of "snippets" as it gave them a competitive advantage. The really smart ones still do.
Re: (Score:2)
In those days it took longer and cost more to write software. The primary appeal of using all these third party libraries is: many features quickly and cheaply.
Sure, there may be a price to pay in the long run. A maintenance cost. But that's ok because we got our product out the door before the competition, locked up some clients in long-term contracts, and as such we will have the money to pay that maintenance cost when the time comes.
And by the time this mess snowballs into an enormous, impenetrable bl
Re: (Score:3)
Between the enormous maintenance costs, and the necessarily shorter lifetime of the product, I have to wonder if there would ultimately be any savings at all.
Even in the short-term, I can't imagine there being much of anything saved during development. There's a story I like to tell about how making and testing a thing took less time than was spend trying and failing to find a suitable thing from a third-party. Finding, learning, and adapting a third-party thingamabob that doesn't quite do what you want i
Re: (Score:2)
A workflow.
New accounts w/ new submissions - must get reviewed and approval before being added.
Existing accounts w/ good standing - auto-approval.
Existing accounts w/ good standing - auto-approval with random reviews to ensure compliance.
FTFY
Crap community, crap experience (Score:5, Interesting)
They need community moderation. For any Linux distro, you need to go through a series of steps before you can have a package accepted or modify a package.
1. Do not allow packages to return in search results by default.
2. For any brand new package, require an existing community member with approved packages review the package before it can be accepted.
3. If a package is flagged as malware, pull it from search results and suspend the author's ability to publish anything, pending a review by moderators.
4. If multiple packages are flagged, ban the user for a month.
5. If any package is confirmed to be malware, ban the user for life. An appeals process allows requesting the ban be overturned if they can prove they didn't mean to push malware.
This could be further enhanced by various means (captchas, confirming user identity via SMS, etc). But the point is to have humans in the loop, not allow just anyone to publish anything, and have a way to quickly identify and pause anything that seems like malware.
Re: (Score:2)
For any Linux distro, you need to go through a series of steps before you can have a package accepted or modify a package.
For example, in the case of Debian, getting a package in seems to require a key signing [debian.org], which involves traveling hundreds or kilometres or hundreds of miles to meet an experienced developer in person. Economic, geopolitical, or disability barriers may make this impractical. (I admit I may have misunderstood what I read on Debian's website about the relationship between a contributor and a sponsor.)
2. For any brand new package, require an existing community member with approved packages review the package before it can be accepted.
When a developer uploads a package, and the package gets no attention at all from other members, what recourse
Re: (Score:2)
If a developer somehow can't afford a $5 flip phone and $5/mo service, they can use a free online SMS number.
Re: Crap community, crap experience (Score:2)
None of those are necessary. Having any human at all in the loop excludes 100.00% of spammers. It's far too costly to meet someone personally for every bit of spam you want to post.
Re: (Score:2)
Makes me think of the sci-fi story site that had to stop accepting submissions because of chat-gpt spam.
"2. For any brand new package, require an existing community member with approved packages review the package before it can be accepted."
Can we dump so much spam on it that 'human community members' can't possibly keep up?
Why, yes. yes we can. Barely an inconvenience.
"An appeals process allows requesting the ban be overturned if they can prove they didn't mean to push malware."
The poor innocent victims, w
LOLWUT? (Score:1)
"a single README file that contains links to various malicious websites."
Pretty sure that is not the definition of "SEO SPAM"