Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
Security / Software Development

Is npm a Hotbed of Malware?

WhiteSource, a leading open source security provider, says npm, one of the most widely used JavaScript package managers, is a playground for malicious actors.
Feb 3rd, 2022 7:00am by
Featued image for: Is npm a Hotbed of Malware?
Featured image via Pixabay.

According to WhiteSource, a leading open source security provider, npm, one of the most widely used JavaScript package managers, is a playground for malicious actors. Is it really that bad?

First, JavaScript is wildly popular. Love it or hate it, Javascript by Stack Overflow’s count remains today’s most commonly used programming language. With more than 16 million developers worldwide relying on its speed, strong documentation, and interoperability with other programming languages that won’t be changing soon.

But its popularity is a mixed blessing. Hackers are increasingly targeting JavaScript’s open source package managers and package registries. The most widely used of which is npm, with more than 1.8 million active packages.

Malware Detection

Using WhiteSource Diffend, the company’s flagship automated malware detection platform. The company claims it found more than 1,300 malicious npm packages in 2021 in npm. That’s bad, but 1,300 out of 1.8-million is only 0.007222%. If you were to just randomly grab JavaScript packages for your program, odds are you’ll be safe.

According to the report, WhiteSource tracked an average of 32 thousand new npm packages published every month during 2021. Even out of that yearly total of 384 thousand packages, your chance of grabbing the wrong code only goes up to 0.00338%.

Of course, no one programs it that way. But this does underline that you need to look very carefully at any npm code before pulling it into your project. For example, you’ll want to avoid new code or code that others have avoided.

Different Attacks

On the other hand, do you want to take even a minute chance when the kind of attacks hiding in npm included:

  • Software supply chain attacks: Used to steal data, corrupt targeted systems, and gain access throughout networks via lateral movement.
  • Cryptojacking: Enables a threat actor to take control of a victim’s compute resources to mine cryptocurrency.
  • Data stealing: Using keyloggers, screen scrapers, spyware, adware, bots, and more, attackers steal private and/or proprietary data from victims.
  • Security research: Attackers create packages that falsely claim to be designed for security research but actually contain malicious code.

I don’t think you do.

True, most npm malware is just there to check out your site. But who wants a reconnaissance program cruising through your systems? I sure don’t!

In addition, by npm’s official count, an astronomical 20 billion package versions are downloaded every week. Clearly, few people are doing their due diligence when it comes to using npm packages.

By its very nature, npm is difficult to police. Npm enables you to use external libraries and supports dependency management. Combined this makes it all too easy to call third-party libraries and dependencies for your project. In addition, while in theory npm packages include everything needed for their functionality all too often, many packages download additional resources upon installation. Sure, you checked the specific program for security problems but what about all its dependencies and its downloads?

Can you say “dependency hell?” I can.

Secure the Software Supply Chain

Npm is a sterling example of why we need software supply chain security. And we need it now.

So it’s no surprise that “with more than 18,000 npm package versions published in 2021, there’s no question that npm is a valuable tool for developers,” explained Rami Sass, WhiteSource’s co-founder and CEO. But, “Unfortunately, that popularity is being used by threat actors to spread malware and launch attacks that harm businesses and individuals.”

For example, let’s say you downloaded what you thought was the well-regarded npm packages style-resources-loader and sass-loader. But, unlucky you, instead, you download the two brandjacking packages faking them. Besides having names that looked right at a casual glance they also included their good source code. But, hiding away in there was an obfuscated JavaScript file and a pair of binary files hidden as JavaScript components that were up to no good.

Specifically, one of the fake JavaScript files was part of the Cobalt Strike, an adversary simulation framework. The final goal? To put your machine to work mining Monero cryptocurrency. That’s no one’s idea of a good time.

Diffend Yourself

So, what can you do? Well, of course, WhiteSource would like you to download and eventually buy Diffend. Their tool checks to make sure you’re only using verified package sources and that you avoid most npm security traps. Using Diffend is actually a good idea.

In addition, WhiteSource has numerous other suggestions on how to defend yourself against common npm security holes. These include:

  • Watch out for typosquatting and its friends. For example,  sspec -> rspec; atlas-client -> atlas_client; damerau-levenstein -> damerau-levenshtein; or ruby-bitcoin -> bitcoin-ruby
  • Never blindly assume ownership in any registry.
  • Migrate from packages that are abandoned or take them over.
  • Do not use packages that are fairly new (e.g. days old).
  • Report unexpected behaviors and inconsistencies to package owners.
  • Never install packages without running an assessment.
  • Don’t install upgraded libraries without carefully reviewing the code.
  • Make sure that dependency update tools that pull request (PR) updates have enough delay to time to verify packages updates.
  • Do not use the same environment variable (ENV) for running specs, building containers, pushing things, etc.

Finally, always remember that the most damage to date from npm has not come from conventional malware at all. Instead, it’s come from developers screwing around with their npm libraries, Examples include the recent “colors.js” and “faker.js” mess and 2016’s infamous, “left-pad npm” episode.

In short, while I can’t call npm a “playground for malicious actors,” I can call it ripe for malware and unable to defend itself well from its inherent security problems. If you use npm, and I know many of you do, you must take steps to protect yourself.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.