NPM Typosquatting

NPM (Node Package Manager) is fantastic! Modern software development wouldn’t have been near as impactful without the combined brain power of thousands of programmers. I’ve witnessed powerful projects built with these modules, saving untold amounts of developer time. However, there are some tradeoffs for this incredible service.

One of the most significant tradeoffs is security. There are many security concerns people have when it comes to NPM. OWASP has a good summary here, but searching for “NPM security issues” will turn up several good resources.

One security issue lacking attention is NPM typosquatting. NPM typosquatting is where the attacker slightly changes the name of a popular package and republishes it. The attacker lies in wait for people to mistype the name of their package when installing it into their project.

What is the threat?

I created a fake package to demonstrate how horrifying (and easy to do) this is. I changed the name of a popular package very slightly and just let it sit there for a couple of months.

I changed the second and third letters in the name and added a disclaimer at the top. I exerted minimal effort here.

Amazingly, people downloaded it! Roughly a couple of hundred people over the last couple of months. The original package has over four million weekly downloads, so by volume, I can see potentially thousands of potential victims here over other mis-spellings on multiple packages easily over a more extended period. On a larger scope, this attack is a long con if played right (like the shocking cross-env story).

So what could I do with this now? I’m sure that a good fraction of these developers will automatically have this added to their package.json file. I’m also confident many developers included the lovely “^” symbol to the version number in the package.json file. Those two likely facts mean I can now add new code and be reasonably sure it will make it into many of their machines without immediate notice. If I wanted to and was reasonably sly and patient enough, I could:

• add in new sub-dependencies to bloat and slow down their application (denial of service attack of sorts, but from the inside)
• add in code to attempt remote execution of code
• try to run a crypto-miner on the down low
• try to steal credentials and phone home
• attempt to siphon data
• try to install malware/ransomware

Yeah, terrifying, right?

I haven’t gone crazy (yet), so thankfully, I’ll shut down this package.

How to spot the threat

Let’s take a closer look at that NPM package and see if there are any red flags:

Exhibit #1 — The name is spelled wrong. “crypto-js” vs “cyrpto-js” is easy to miss, especially on a package with millions of downloads! Typosquats can also manifest as added/removed hyphens (cryptojs), capitalization changes (cryptoJS), and added spaces (crypto js).

Exhibit #2 — This was just published only two months ago. It’s suspect, considering it’s on version 4.1.1 already.

Exhibit #3 — No dependencies or dependents. Not necessarily a deal breaker, but if there is a sudden surge of added dependencies, better scrutinize it more closely!

Exhibit #4 — Too few versions for sure. A good added check is to see the consistency of versions. Consistent and periodic version releases are a sign of a healthy project.

Exhibit #5 — Short download history. As you can see, some people have been downloading it, but the history looks weird and short. Question everything!

Exhibit #6 — Sus publish date. The last publish date is a good indicator of the health of a project, not only for security purposes but also reliability. If something breaks, your options are limited. If there is a new vulnerability uncovered, how will it get patched?

Exhibit #7 — Do you trust that face? You can always do some added sleuthing by clicking the contributor’s portrait; you might find some other dirt or make lifelong friends.

Other Clues — Is there a valid link to the repository? Do the contributors match between NPM and the GitHub repository?

The evidence is piling up!

How to defend against the threat

Granted that NPM typosquatting is a social engineering exploit, there are still a few things you can do to protect yourself:

1. Make use of automated tools such as NPQ or Snyk. These will automatically check for suspicious signals outlined above and against lists of known vulnerabilities.
2. Prevent scripts in the package from running automatically during the install phase using the--ignore-scripts flag (this is the same flag for both NPM and Yarn)
3. Take the time to do a gut check. When installing new packages, visit the NPM site for each and see if anything looks off. Use the previous section as your guide.
4. Check the spelling and punctuation for your existing packages and see if your current set of packages is from legit sources.

How to attack the threat

1. Report suspicious packages to NPM. NPM has a process to handle vulnerable packages outlined here. On each package’s page, there is a “Report malware” button:

2. Report suspicious packages to Snyk. Disclosure can be made by email to report@snyk.io or through Snyk’s vulnerability disclosure form:

You can also report vulnerabilities for other popular package managers as well!

3. Bring awareness to your team and share this article! The more who know, the harder it is for bad actors to pull off these schemes.

If you found this valuable, please follow the blog, where I’ll continue to post on security topics and more! Stay safe out there!