Secure management of dependencies is not always a priority when compared to development speed. At the same time adding new open source software from public registries like npmjs is easier than ever.

As a consequence it's often easier for hackers to inject malicious code as part of the software supply chain instead of trying to exploit existing vulnerabilities.

This is known as a supply chain attack, an attack vector that has been further highlighted with the emergence of the dependency confusion concept
together with recent articles like typosquatting in the Go ecosystem.

The topics of typosquatting and dependency confusing are particularly interesting as they highlight two things that are central to package management.

• Package names matter. Alot. All that is required to install new packages is a valid name. If you misspell or remember a name incorrectly you will worst case install another package. Possibly a malicious one.

• How much trust (or risk) we put in our supply chain. We trust that packages are always available from the public registries, trust that packages are not malicious, and trust that packages has not been compromised or taken over from its original creator. Unfortunately this trust can be exploited...

To reduce some security risks, this post will look into methods that can be used to imitate legitimate package names. By being aware you stand a better chance of keeping your software supply chain secure!

What is typosquatting?

Typosquatting (in the context of package management) is the term for creating and publishing malicious packages with names imitating legitimate ones.

Through typos or mistakes, such packages are included in your supply chain. And package scripts can run during installs by default!

With package managers like npm, we can easily add new dependencies to our projects through the name alone.
Want to add that dependency you used from months ago by memory? Not really a problem, until you accidentally include a package other than you intended.

Hackers are relying on the fact that as long as their packages pass a shallow inspection the variations in package names doesn't raise any red flags.

One of the many examples include the now removed package electorn that was transposed from the legitimate package electron by switching the order of O and R.

# At a glance there's not much difference of malicious package name
$ npm install electorn
# compared to the legitimate package name
$ npm install electron

Different variations of typosquatting

What is combosquatting? Omission, repetition and transposition? Typosquatting is the collective term for imitating real package names.
But there are multiple variations on how this is achieved. Let's have a closer look, together with some real world examples from the npm ecosystem where this was used.

Combosquatting

Combosquatting consists of trying to imitate legitimate packages by appending common words, terms or letters on the original package name.

Example of combosquatting for package names:

• twilio -> twilio-npm
• cross-env -> cross-env.js
• fabric -> node-fabric
• lodash -> lodashs

Where npm, js and node are all common terms in npm and JavaScript.

Combosquatting is generally considered the most common of the permutations.

It is also common in website phishing attempts where URLs are appended with seemingly legitimate terms to fool unsuspecting users.

Omission

Omission is intentionally leaving out a character in a package name. Either a letter or some other character like a hyphen.
It is aimed at the times when we miss pressing one of the keys in a sequence, or simply to confuse developers with familiar sounding un-hyphenated names.

Example of omission for package names:

• mongoose -> mongose
• babel-cli -> babelcli
• cross-env -> crossenv

For the npm ecosystem, the package naming rules was updated to partially cover omission in package names.
But package names are still validated on a case by case basis.

Repetition

The inverse of omission is repetition with intentionally adding multiple instances of the same characters. This plays both to our nature of pressing the same key twice by mistake but also to spelling mistakes.

Example of repetition for package names:

• jquery -> jquerry

# Example of typosquatting dependency in package.json. 
# Would you notice the difference? 
...
"dependencies": {
    "jquerry": "^2.0.0",
    "react": "^17.0.1"
  }
...

Transposition

Transposition switches the position of two adjacent characters. Typos where we press keys in the wrong order, as well as common spelling mistakes are target for transposition (middle -> middel in the example below is a perfect example of this).

Example of transposition for package names:

• http-proxy-middleware -> http-proxy-middelware
• electron -> electorn

Control the risks by controlling your dependencies

A secure supply chain, from typosquatting or other attacks, starts with knowing what open source software you are using.

Use a service like Bytesafe to host both private and public packages. This enables a central hub with all your dependencies in one place. For both direct and transitive dependencies.

When new dependencies are added to a project, they are instantly available in Bytesafe as well. Allowing for continuous monitoring and control. Detect issues as they happen instead of waiting for point in time scans or critical issues in your build environments.

Scan dependencies for known vulnerabilities. Package typosquatting attempts are continuously being reported and flagged for vulnerabilities. Get notified or block any known vulnerabilities in your supply chain. Directly when adding them or anytime in the future.

Don't run scripts by default during install
When installing packages there are often scripts executed as part of the installation process. This is convenient and useful, but executing random scripts is also a major risk.

Make sure you know what is executed when installing packages. If you have not reviewed the scripts, you are much more likely to be safe installing with the --ignore-scripts attribute.

Want to know more about how Bytesafe can help secure your supply chain?

Visit our dedicated page on securing the software supply chain to learn more about the potential problems to look out for and how we can help.

Also, follow bytesafedev on twitter for continuous updates on everything security related. Stay safe!