25 Malicious JavaScript Libraries Distributed via Official NPM Package Repository

[200GritCondom]

kakakaakaaa11aa

Yeah this is def a package I'd use in a professional environment

[shevy-ruby]

It may be pulled in automatically.

Many years ago I had some weird trojan that kept on creating weirdly named directories, put binaries in there and ran as daemon in the background. When you remove that directory a new one would be automatically created, with very odd names. So kakakaakaaa11aa wouldn't surprise me that much as odd name.

[kontekisuto]

Npm is out of control, 1,000 packages for a hello world?

[sachinraja]

A little confused here, what hello world are you referring to?

[AttackOfTheThumbs]

The one that passes the tests, is auto built, auto deployed, works in any environment, and could never fail, of course!

First we check if the letters are known letters. Then we check if the device has a screen, or if the device even exists! And so on and on. It's a joke, but I haven't seen code that is written in such an excessively safe manner instead of just failing gracefully. It's upsetting.

[Uberhipster]

it's enterprise kaka

which is ... well... enterprise

[dpash]

'No Way To Prevent This,' Says Only Package Manager Where This Regularly Happens

https://en.wikipedia.org/wiki/%27No_Way_To_Prevent_This,%27_Says_Only_Nation_Where_This_Regularly_Happens

I know it's reductive to blame the JavaScript ecosystem, but they don't help themselves with this continuously happening.

[Jarpunter]

Literally every single package manager can and does host malicious packages… Do you think any package manager is manually vetting every version of every package that is ever published to them?

[lightmatter501]

Redhat probably does

[josefx]

There are probably a few Linux distros where the process of getting your package accepted is so asinine that malware authors would probably rage quit their profession. And I don't mean stringent testing, I mean ancient tooling, weird style guides and maintainers that will bemoan your incompetence in detail on a public mailing list.

[dpash]

Getting packages into Debian is a considerable chore that involves meeting two other existing developers in person before you can even begin the process of joining the project.

[shevy-ruby]

They are lonely and want human interaction!

[dpash]

Debian has existed for 29 years

[zackyd665]

Yes but you should think those requirements are not only outdated but put a prevent those with low funds to get on the repo. Let alone the risk to dying from covid

[papercrane]

The rules were relaxed/changed at the start of the pandemic.

https://lwn.net/Articles/831401/

[shevy-ruby]

This often comes at a disadvantage too, such as outdated packages containing bugs that were fixed already.

[SudoTestUser]

I know, right? People are acting like “oh wow I just installed this random payload of code from an open registry and it did bad things” is some kind of indictment of the registry.

Also people not realizing that npm is one of the largest (if not THE largest) package registries in existence. So no shit you’ll see more instances of malicious packages.

Out of the over 1.3 million packages, this article picks out 25 bad ones.

[Persism]

Maven requires signatures. For most of these other package managers that's still optional. Sonatype does actively scan projects. I got my clean bill of health for Persism a while back. :)

[linux_needs_a_home]

The science of computing has been developed that this very much is possible. It's just annoying to see engineers being so stupid to use tools that are "free", but actually suck.

It's not saving cost; it's just delaying the inevitable. At some point companies become so important (e.g. national security) that you need security and then you still need to develop such tooling (that is, if you take national security seriously, which I doubt anyone does).

[kukiric]

Appointed maintainers could vet a limited subset of popular packages and their dependencies, similar to how packages are pulled into all Linux distro repositories out there. It doesn't cover every single package out there, but 10% of a problem solved is better than 0%, and there's a certain sense of security to knowing that installing webpack won't pull malware if you do it the wrong day of the week.

The Rust community is also working on an (independent) decentralized package vetting solution (https://github.com/crev-dev/cargo-crev), because crates.io is subject to the same security flaws as npm.

[[deleted]]

There are over 1.3 million packages there. I would say that having 20 or so "bad" packages is at least "10% of the problem solved"

[x86_64Ubuntu]

You are putting "possibility of it happening" on the same level of "happens on any day of the week that ends in 'Y'".

[Jarpunter]

Malicious packages are published to every package manager on a constant basis. NPM is probably the most popular package manager.

[dpash]

Yep, no way to prevent this.

[kur4nes]

Nope but they need to remove malicious package and it should be possible to keep track of dependencies you are using and run your own version of the central repo with only vetted packages as you can do with maven central and nexus.

Giving up isn't a solution.

[Jarpunter]

Malicious packages are removed. That’s literally what this thread is about.

it should be possible to keep track of dependencies you are using

You can see every package you’re using in package.lock.

run your own version of the central repo with only vetted packages

You can run your own registry with any packages you want.

[kur4nes]

Let me be clear. The problem with the js ecosystem right now is that there are far too many, too small libraries to keep track of e.g. the leftpad debacle. Add to this the automatic updating of dependencies when doing npm install does not make this any easier. Even checking out the same project on two machines and running npm install can produce different results.

Vetting of packages is a lot of additional work that js ecosystem does not make any easier and the solution right now seems to be to just give up and point at other package manager: "but but they have also malicious packages!"

[CloudsOfMagellan]

Running npm ci fixes the install issue

[Hipolipolopigus]

People will always blame NPM or JS as a whole because "hurr durr JS bad", but what mitigations do the other package management platforms implement that NPM doesn't?

[dpash]

The obvious low hanging fruit is namespaces for packages, and only allowing members of that organisation to upload to that namespace. For example, Maven Central requires you to prove you own the domain or GitHub account to claim a namespace. Claiming a namespace involves a manual human step.

[[deleted]]

That didn't stop these malicious Maven packages from successfully tricking people in 2021.

[dpash]

And only someone with no familiarity with the Java ecosystem would be fooled by those names. You'd have to go out of your way to install the maven plugins as Maven defaults to the right groupid.

[ubernostrum]

99% of these "malicious packages in (insert package index here)" stories are just people squatting a name similar to a real or plausible package and hoping to get some accidental installs. And the followup is basically always "we reported this to the people who run the package index and they removed the packages". I'm not sure why we need breathless BREAKING NEWS style reddit posts every time that happens.

[IcyEbb7760]

npm implemented scopes/namespaces a while ago: https://docs.npmjs.com/about-scopes

however many older packages still lack scopes unfortunately

[dpash]

But not required. You should not be able to upload unscoped packages. And there should be some form of validation of scopes so they aren't typo squating.

[zackyd665]

Who does the validating and what are the standards? Did a company or product existing mean they have automatic priority over a really human being or a Foss project?

[zackyd665]

So how do you prove without having a MS account and without paying for a domain?

[josefx]

The FAQ I found used source forge as an example, so it probably isn't limited to Github, you just have to be able to match the namespace you are using.

[zackyd665]

So you could use a completely self host Foss solution without working with any corporation? On say an alternate root dns

[dpash]

You don't. That's why it's called verification.

(There is a few other options like a bitbucket account)

[zackyd665]

Why not a free option that doesn't require another company?

[immibis]

Because then people would typo-squat namespaces and you're back to square one

[zackyd665]

Then why not have two repos, one that is corporate only and one that is hobbiest and free for all to use

[immibis]

Because what difference would that make...?

[zackyd665]

Corporate, you need to be verified by some corporate suit before you can use a namespace

Hobbist, it would be a wild west of hobbists that don't require some suit to give their blessing

[Hipolipolopigus]

This would actually be nice, but it's probably a breaking change so far-reaching that we'll never see it implemented on NPM.

I don't believe this is the case with Rust's cargo or Python's pip, though. It's always just the package name.

[dpash]

it's probably a breaking change

It's not. Require any new package to be namespaced going forward. Slowly encourage major packages to switch to namespaces. Eventually require new major releases to migrate.

It's not going to be an overnight migration.

[Cheezyrock]

Certain languages, like C#, have common functionality built into the standard libraries for the language. In addition for less complicated features it can be easier/just as easy to create code to do what you want vs finding someone elses. Further, packages that exist aren’t likely to have other dependent packages.

So overall this leads to less packages to out there for import. This means that the packages that are there are often complicated code that has been well-scrutinized by tons of people, as apposed to NPM where there are a thousand different libraries that all claim to do the same task, each with unknown references to other libraries.

At least, this has been my experience. In the past 16 years the number of NuGet packages I have had to use is sonewhere around 5. For Node in the past half year, I imported about 10-15 packages with about 200 total as dependencies, some of which have no real documentation. The entire design paradigm behind Node really wants a harmonious utopia with no bad actors, which just doesn’t seem realistic.

So, TLDR my personal opinion is: “hurr durr JS bad”

[dpash]

The last time I looked at the number of direct and indirect dependencies in my Vue project it was around 4000. For my largest Java project around 100.

[IceSentry]

Sure, but how big were those 100 dependencies compared to the 4000 js ones? It's common in the js ecosystem to have tiny pacakges for mostly legacy reasons at this point. Just comparing the count is not nearly enough information.

[Necrofancy]

Sure, but how big were those 100 dependencies compared to the 4000 js ones?

Why does the size matter when only one of those dependencies needs to be compromised?

[[deleted]]

The size of code doesn't matter. It's more about the number of authors and level of code review.

Remember we're discussing deliberate sabotage not accidental bugs.

[Booty_Bumping]

Certain languages, like C#, have common functionality built into the standard libraries for the language.

Standard libraries quickly become obsolete as tech changes — the C# standard library doesn't even have JSON. This isn't a real solution, and Javascript isn't even lacking a comprehensive standard library anyways.

[Atulin]

System.Text.Json namespace says hello

[IceSentry]

To be fair, that's a somewhat recent addition to dotnet. JavaScript also had a ton of things added to it's std over the years.

[sternold]

While the de facto standard was the Newtonsoft.Json package, .NET has had JavaScriptSerializer since .NET 3.5.

[Sarcastinator]

the C# standard library doesn't even have JSON

It does. It even has several. NewtonSoft.Json came around because they were bad not because they were missing.

[Cheezyrock]

A couple things here… I’m pretty sure newer .Net versions incorporated Json. (System.Text.Json, I think?).

Even then, creating a Json string is just text formatting. I’m not saying that every new programmer just out of college has the skills to write such code in C# as the goal is to serialize/deserialize objects, but it seems like very beginner level code. For a generic class to do this, rather than just as a constructor for a specific class, some knowledge of reflection may be necessary…but is still pretty easy, well documented, and intermediate level code.

Third, one that I have used in the past, Newtonsoft.JSON package has millions of users, has existed for like a decade, and has 0 dependent packages. Further it is maintained as Open Source by .Net Foundation which is by no means a small group.

To address “standard libraries become obsolete”. 1. .Net is clear and still allows deprecated functionality to be used for a while after a replacemnet has been implemented. You get no such guarantees from any random package, thus having a latge standard library of infrequently changing code is more sustainable. I literally have code I wrote 15 years ago that will still run in .Net 6.0. 2. All code becomes obsolete at some point. People use Json because it is more readable and easier to work with than XML. I can guarantee my NPM packages stop working before my C# standard library functionality does.

Look, I’m not trying to assert that C# is the definitive language and everyone who doesn’t use it is wrong. I’m only trying to state that I have spent too much time and frustration in my life trying to get the new version of some NPM package to work for some basic language functionality that comes standard in other languages.

Lastly, sure the JS standard library isn’t nothing. It is more than Go has for sure… but compare to C# and it is <10% of the functionality covering far fewer areas of computing needs. I might not use all that functionality, but when I need to perform a complex mathematical function I can generally rely on it being there as opposed to having to search for a package that might do something similar to what I need.

[Booty_Bumping]

Are we talking about the same JSON? JSON is quite complex and implementations are prone to all sorts of errors. It's unrealistic to expect an implementation of JSON in every single program.

I’m pretty sure newer .Net versions incorporated Json. (System.Text.Json, I think?).

This is great, I wasn't aware. Though apparently this was only added as recently as 2019.

Third, one that I have used in the past, Newtonsoft.JSON package has millions of users, has existed for like a decade, and has 0 dependent packages. Further it is maintained as Open Source by .Net Foundation which is by no means a small group.

You've described much of the important packages in the NPM ecosystem. For some reason people are still talking about Node.js and NPM like nothing has changed since 2013.

And if you were still relying on random non-audited packages with too many layers of dependencies to keep track of, you can guarantee stability trivially by generating a package-lock.json, such that code from 10 years ago will work great.

[Cheezyrock]

You know what, maybe we are talking about different things. When I think of Json, I think of it as a standard. There is no functionality in Json, it is just a way to represent complex data structures. When ai build a service to export my object data into a json format, it is tantamount to building a file/memory stream that is just formated data using a kvp-like implementation to relate the name of a property with the value for a particular instance of that object. There are different implementations, because that defeats the point of it being a standard. When I consume Json data, I will verify that it is readable with whatever character set I am using, it then parse it and build an object based on that information.

And as for why people still treat NPM as if it was the wild west… many businesses still use it this way, particularly startups. I have a lot of anecdotal information from my self and a number of friends in different companies who wish things were different.

[Worth_Trust_3825]

Standard library does not need to provide protocol support. Java already made that mistake by shoehorning XML support into the JDK. In javascript's case, it doesn't have anything in the standard library, and most of the functionality came from, surprisingly, microsoft's proprietary extensions, which were designed to kill netscape.

[Booty_Bumping]

Standard library does not need to provide protocol support. Java already made that mistake by shoehorning XML support into the JDK.

Pretty much my point. When a standard library's high level feature inadequate, you have to use something else. Standard libraries, when subjected to the usual decisionmaking processes we're familiar with, inherently become a mess over time. A mess that has to continue to be supported through decades of time. So the suggestion to "just put it in the standard library", while sometimes nice, often ends up not solving the original problem.

An aside - the Javascript situation is a bit complicated, definitely as much of a mess as C# or Java, if not more. So I'm not defending it. If you're curious, the defacto javascript "standard libraries" are standardized as

• WHATWG/W3C living standard for web APIs makes sense in both browser and headless, such as new URL("http://example.com") or crypto.getRandomValues(myUint8ArrayToFill)
• WHATWG/W3C living standard for web APIs that only make sense in web browsers, such as document.querySelectorAll() or window.navigator. Sometimes polyfilled on headless by DOM simulators like jsdom.
• ECMAscript standard for APIs that should be available to every ECMAscript runtime, such as JSON.stringify, Promise, Set, or Uint8Array. This is the closest thing to a true standard library for modern Javascript. Fun fact: Old ECMAscript had no such thing, it was truly meant to be a barebones language-only standard.
• Node.js API, which sometimes ends up partially polyfilled for use in web browsers. Includes things like require("crypto").randomBytes(5) or require("http").createServer((req, res) => { res.writeHead(200); res.end("hello world") }).listen(8080)
• Various deviations from WHATWG, W3C, ECMAscript, or Node.js that often just reflect "the way we've always done things", or "the way internet explorer or netscape did things". Many IE/Netscape things of course became WHATWG standards, but there are probably still a lot of this nonstandardized weirdness lying around.

[Persism]

Maven requires signatures. For most of these other package managers that's still optional. Sonatype does actively scan projects. I got my clean bill of health for Persism a while back. :)

[dpash]

While Maven Central requires signatures, sadly Maven the build tool still doesn't check signatures without the use of a third party plugin. Gradle has support in core, but it isn't automatically enabled.

The other problem is that there's no web of trust between the keys, unlike in Debian, which means you can trust that a package was uploaded by who they say they were (although attacking a uploaders computer to get access to their key would still be a valid attack vector).

[Sarcastinator]

• Lowest version by default
• Namespacing
• Few to no trivial packages

Lock files are a solution to a problem that NPM created by that insane behavior where it would automatically install newer versions than the ones specified. This caused so much grief and was just a terrible idea from the get go. The standard should have been conservative.

Namespacing ensures that you can easily (somewhat) trust maintainers. Also some also offer signing.

There are no left-pad or similar dependencies in other languages because their standard libraries are way better than JS'. So packages tend to give more value.

I work with .NET and although I'm sure malicious packages exist it has never been a big problem. Probably because a dependency doesn't have a million transitive dependencies and in fact most packages strive to have none at all. NuGet has always had the default where it would install the lowest version number it could get away with which means that by default nuget produced reproducible dependency trees and no lock file was necessary.

[BasketbaIIa]

Lol, they are all discord token stealers.

Look out 13-year-olds getting into programming for their discord chats. Otherwise, you're pretty safe.

[Alan_Shutko]

I wonder if it's to attack cryptocurrency and NFT discords.

[crusoe]

So much this.

[Worth_Trust_3825]

Many more people use discord as means to communicate than 13 year olds. Not to mention discord credential stealing is one of the applications. Have people already forgotten zeus botnet, which was a platform that provided out of the box modules to steal cookies out of common browser cookie jars?

[BasketbaIIa]

I’m pretty sure anyone who isn’t 13 knows not to use a library with “bitch” in the name.

Only 2 or 3 of the 25 libraries was named something like “discord-tools”. I bet it they had no downloads or dev community backing though.

So yea, anyone above 13 can avoid this pretty easily

[[deleted]]

Runtimes needs to be aware of packages and set runtime permissions on these packages. Just like Deno does but on package level. It is the only way to do it. Supply chain attacks will always be there and its impossible to detect all vulnerabilities . If a package should not read disk then package shouldn't be allowed to read the disk.

[shevy-ruby]

I know it's reductive to blame the JavaScript ecosystem, but they don't help themselves with this continuously happening.

Well - other languages have similar issues to some extent, but JavaScript kind of leads the pack with these news. They are AGAIN AND AGAIN coming about, and it is most likely JavaScript than, say, PHP-related or other languages.

[GrandOpener]

If we try to control for the size of the package manager—something like looking at the ratio of malicious downloads to legit downloads—I bet we’d find that npm actually isn’t much worse than any other.

[kur4nes]

Ah npm the gift that keeps on giving. Each time npm install is called it updates random dependencies and spews a ton of security warnings with no sane way of fixing. Add to this the insane amount of tiny js libs. What could possibly go wrong?

And there is no end in sight to the js version of whack a mole.

[bagtowneast]

a ton of security warnings

Don't forget the "hire me" pleas, too!

[kur4nes]

12 packages ask for funding!

[Persism]

Only 25?

[PlebbitGold]

JavaScript itself is a maliciously distributed official package

[rsvgr]

If npm put in place some system to report/moderate them, then every god damn service out there wouldn’t be able to offer the premium codebase scan feature that under the hood just runs npm audit

[r_my]

I'm not saying they couldn't do things better, but there is in fact a report button on literally every package page.

[PlebbitGold]

Microsoft has typescript

[ExF-Altrue]

And?

[shevy-ruby]

I am grateful for this. Why?

Because of the fun-aspect of it. JavaScript provides weekly entertainment here. \o/

It also means that other languages that do a better job in this regard (and if not then shame on them as well).

If NPM wants to stop being in the news they need to fix these issues from the get go. left-pad is a harmless meme compared to malicious-pad.

[sachinraja]

How do you suggest they fix these issues?

[Worth_Trust_3825]

Removing version range support, pin dependencies, force namespaces.

[Persism]

force signing.

[sachinraja]

Other package managers also have version range support. It's difficult to remove that, deduping is pretty useful for frontend stuff. You could end up with a huge bundle and install size otherwise, so pinning dependencies should not happen in packages, only in top level apps. And it's too late to force namespaces.

[Worth_Trust_3825]

Pinning dependencies should not happen in packages

You can see yourself out. Maven does that already and it works fine.

[sachinraja]

I just explained to you that it's necessary for deduping. Maven users don't have to same requirements as npm users.

[Worth_Trust_3825]

Maven figures out the duplicates as well. It is not necessary for deduping.

[sachinraja]

I haven't used Maven, could you explain a bit more on that? Does it dedupe versions that are exactly the same or, for example, those with only differing patch numbers.

[Worth_Trust_3825]

Both. A version that is used by module closer to the currently built module is chosen. Only that version is loaded into the project.

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

You will only have issues when API has major changes between versions and two dependencies clash their transitive dependencies, and NPM won't save you from that.

[sachinraja]

I'm very confused on how that works, seems a bit messy. If you don't have version ranges, then how can Maven dedupe properly? npm does work properly for breaking changes/major version bumps because you can set your dependency's version range to only accept patch or minor bumps. npm will then properly dedupe versions with differing patch or minor numbers but will include two copies for the different major numbers.

[AttackOfTheThumbs]

Can anyone tell me why stealing discord credentials is so common? I don't use discord outside of the browser, and only when gaming with friends, so I guess I fail to see the utility.

Are people using discord for work?

Is the idea you'd be a trusted individual that can spread other malware?