Adding new open source software from public registries like npm is easier than ever. At the same time secure management of dependencies is not always a priority when compared to development and deployment speed.
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 supply chain attacks, an attack vector that has been further highlighted recently with the emergence of the dependency confusion concept together with articles like typosquatting in the Go ecosystem.
The topics of typosquatting and dependency confusing are 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 place in the supply chain. Trust that all packages are always available from the public registries, trust that a specific package is not malicious, and trust that the package has not been compromised or taken over from its original creator.
To reduce the risk of this trust being exploited, this post will look into methods that can be used to imitate legitimate package names. Being aware of potential risks you stand a better chance to keep 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 inadvertently 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.
Different permutations of typosquatting
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
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.
Include private and public packages into Bytesafe. 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 to be reviewed 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.
As always, follow bytesafedev on twitter for continuous updates on everything security related. Stay safe!
