Beware of fake npm packages

Hey there, fellow security enthusiasts and developers!

Today, I want to shed some light on an important topic that affects our beloved npm ecosystem — typosquatting in npm packages. But before we dive into the details, let’s take a quick moment to understand what npm packages are and why they hold such significance in our development workflows.

For those of you who might be new to the term, npm (Node Package Manager) is the go-to package manager for JavaScript projects. It allows us to easily incorporate existing code and libraries into our applications, saving us precious time and effort. npm hosts a vast repository of open-source packages that we can freely use to enhance the functionality of our projects.

Now, let’s talk about typosquatting. Imagine this scenario: you’re diligently typing away, installing packages for your project, when suddenly you mistype the package name. It happens to the best of us, right? Well, here’s where the problem arises. Malicious actors take advantage of these innocent typos by creating fraudulent packages with similar names, hoping to deceive unsuspecting developers like us. This practice, known as typosquatting, involves registering package names that closely resemble popular and frequently mistyped ones.

Source: https://thehackernews.com/2022/02/25-malicious-javascript-libraries.html

Their goal? To trick developers into unintentionally installing these malicious impostor packages, potentially compromising the security and integrity of our projects.

In this blog post, we’ll explore the implications of typosquatting in the npm ecosystem, the risks it poses to our projects, and most importantly, strategies we can employ to protect ourselves and our code from falling victim to these sneaky tactics.

So, buckle up and get ready to learn how to navigate the false waters of typosquatting in npm packages. Let’s ensure our development environments remain secure, and our projects stay safe from these crafty adversaries.

Proof:

Around 7 months ago, I created and released an npm package that bears a resemblance to an existing package, making sure to project it as a fake package (I didn’t include a README.md file for this particular package). Typically, when attackers attempt to mimic an npm package, they employ a simple tactic of altering a few characters in the package name, while replicating the entire README file. Additionally, they cleverly redirect to a GitHub repository that mirrors the legitimate package’s project. Well, cloning a repository is a matter of < 30 seconds.

Snapshot of the npm package that I published

It has been quite surprising for me to witness the actual download of this package among users. When a package is well-maintained and presents itself convincingly with genuine links and details, it becomes remarkably easy to entice thousands of developers within a span of just a few months. There are several such real cases where malicious packages are published in the npm registry and people have fallen into the trap.

Give a read to this cross-env story as well :)

(Please note that I have taken down this package 😅)

Now, having added these packages to the benign projects, how can this exploit the corresponding applications?

1. Malware Injection: Malicious actors can publish typosquatting packages that contain malware or malicious code, and may cause unauthorized access, breaches or any kind of malicious activity when added to the applications.
2. Remote Code Execution: Using this attack, attackers can execute arbitrary code within the application’s context and can even gain control over the entire system.
3. Credential Harvesting: Might attempt to harvest user credentials and other sensitive information by mimicking login prompts, or API endpoints.
4. Dependency Confusion: If developers have misconfigured their package manager, it may fetch the malicious package from the public registry instead of the intended internal package, leading to security compromises.
5. Supply Chain Attacks: The attacker can further exploit vulnerabilities within the application’s ecosystem, compromising the entire software supply chain.

How to identify these fake and malicious packages?

Consider this package for example, named ‘lobash’. Did you read it as ‘lodash’? 😆

Well, we do not know if this is a typosquatting attempt or some junk/testing package.

snapshot of a package named ‘lobash’

1 — Package name: Be more cautious about the spelling of the intended package names. This is pretty easy to miss. In addition, it could also be a few minor character changes instead of the spelling. For example, cross-env was named as crossenv and cross-env.js. 🚩🚩🚩🚩

2 — Published time: If you come across a package with only one version published a long time ago, it may indicate that it is either a test package or some irrelevant package not intended for actual use. Be cautious when encountering such packages. Some malicious packages may have been recently published but already reached higher versions. This can be a 🚩🚩, as it indicates rapid version increments within a short period.

3 — Description: Check the README of the package. It might either contain too little information or no information at all (🚩) or might just have the entire content copy-pasted from another package.

4 — Dependencies and Dependents: Don’t just check the count of dependencies and dependents, but also verify what those packages are. In most cases, having no dependent and dependency packages are also a 🚩.

5 — Version: Suspicious packages will have very few versions or too many versions in a short period of time. Keep an eye :) 🚩🚩

6 — Popularity of the package: Weekly downloads of a package tells about the popularity of that package. Think several times before using a package with very few downloads 🚩🚩.

7 — Total files: It is better to check the total file count of the package as any normal node.js application will have at least two files (including the package.json file). In the provided screenshot, it is just 1 file and an npm project cannot be built using just one file. 🚩🚩

8 — Collaborators: Always check the collaborator's profile, their reputation in the open-source community and the other projects that they have developed. Of course, someone who wants to perform a targeted attack on the applications could fake their online presence, yet it is worth going after this exhibit in addition to the others. 🚩

How to report these threats?

There is an option to report these malicious packages to npm. They have provided a document on how they will handle these malicious packages.

Or we can also report suspicious packages to Snyk. It can be done either by submitting the issue on the Snyk Vulnerability Disclosure page or by sending an email to report@snyk.io.

I am still in the process of learning more about this type of attack and this post is inspired by several other academic and non-academic resources. Go check them out if you are more interested :)

Credits:

• SpellBound: Defending Against Package Typosquatting
• NPM Typosquatting
• 25 Malicious JavaScript Libraries Distributed via Official NPM Package Repository
• What is typosquatting and how typosquatting attacks are responsible for malicious modules in npm?
• Beyond Typosquatting: An In-depth Look at Package Confusability

Stay tuned for the upcoming posts, where we’ll equip ourselves with the knowledge and tools to tackle security-related issues head-on!

Also, check out my posts on Prototype pollution in Javascript part 1 and part 2.

Happy coding and stay secure!