Fraud and scams are high margin activities where malicious coders unfortunately have more time to spend than the good guys.
A few days ago harmful code was found in a couple of packages on the public npm registry: electorn, loadyaml. Even though they have now been removed, they were previously available to coders around the world. This technique is called typosquatting and the intention is to make you believe you are downloading official packages, while you are actually downloading packages with similar spelling that contain malicious code.
In these most recent cases the packages focused on collecting user data and push it to public pages on GitHub as Base64 encoded strings.
A similar example from a few years ago was the package babelcli. Is it obvious that this package is fake when compared to the authentic package babel-cli?
Clearly not, which is also the reason the package saw quite a few downloads for the two weeks it was allowed to exist in the public registry.
A few years ago our team developed a series of web components that extensively used the React library.
As pretty much every component had this dependency, npm install react was not uncommon.
But what happens when you have “fat fingers”, mistype and misspell when using commands like npm install?
If you misspell react you easily may type reavt (as v is next to c on the keyboard). At the time nothing happened when you tried to install reavt.
Partly as a joke and partly to to see how many would download reavt we published a public react package. Fortunately we are good guys, but the same technique is used by bad guys who do the same thing with multiple variations of well-known packages.
|
|---|
| This is the the account that stored extracted data from users |
Alright, I think you get the picture. Now, let’s dive a little deeper and see how common this is and what you can do to prevent this behavior.
Typo…what…squatting? How does it work?
Typosquatting (and the similar combosquatting) are examples of software supply chain attacks, where malicious packages are published with the intent of free-riding on the trust people put onto their third party components.
By relying on the fact that people make typos all the time and usually don’t deep dive into their dependencies, the intent is getting their packages pulled into your project (supply chain) and use that to get access to whatever system your project is finally deployed to. Developers are often targeted as they often have goodies such as SSH keys laying around or other stuff that can be misused…
The devil is in the details - With the structure of how you use JavaScript packages and the convenience the public registry brings, this is more true now than ever.
The use of open source components within JavaScript is extensive, and the use of such components from external sources enjoy a remarkable level of trust from developers. Most developers simply don’t consider that the dependencies they rely on could potentially contain malicious content (intentionally or not).
But when installing packages from npm or any other repository you simply manually enter a command in a terminal and the package is automatically installed and added to your workstation. Including all related dependencies!
To be on the safe side you need to make sure you are pulling the packages you intended to.
What are the implications?
You can imagine the consequences when for example a bank unintentionally deploys a package that tracks its customers bank details and sends the data to a remote server.
It is also common for packages to target the cryptocurrency segment. Either as a supply chain attack to get into cryptocurrency exchanges or also more targeted at individuals where packages install malicious content into a workstation to look for crypto wallets and send that information to a remote server.
Either way, it is always bad news to install something else than the package you intended…
How to protect yourselves?
How do you restrict malicious packages from being included into your organization’s supply chain? As with most security related issues there are no magic fixes, but there are recommended steps to take.
Use a npm proxy and visualize your code supply chain
Knowing about a potential issue and taking action to prevent it is most likely your first (recommended) step. But how do you visualize all your open source dependencies identify issues?
By using a Bytesafe registry as the source for packages for your organization you get a central registry within your control. Configure your Bytesafe registry to pull package versions from a public registry as one of its upstreams and all packages used by your organization will be visualized in the Bytesafe registry.
Simply navigate to the registry in Bytesafe to access the overview of all available packages and versions.
If you are already using a Bytesafe registry with a public registry configured as an upstream, then you have a npm proxy already!
Using a npm proxy has several benefits:
- Apply Bytesafe Policies & Plugins to your registries
- Visualization of packages dependencies
- Curate packages (by yourself or your SecOps team)
To learn why we recommend using a npm proxy, see the previous post on using and setting up a npm proxy
Scan for known vulnerabilities
Let Bytesafe scan your packages for known vulnerabilities and get notifications if something is found. You can also enable the Secure & Scanned Policies to make sure that your private registry only allows scanned and secure packages. If you are on the Teams plan you can also get notifications to your own Slack. Sign up for a trial of our Teams Plan to try this out for yourself.
Review your package dependencies
Depending on the scope of your project(s) this may be more or less manageable to do manually.
In any case there are a few things to keep in mind when trying to identify malicious packages:
- Duplications of names - if your list of dependencies includes several variations of the same package name, this is a red flag and should trigger further investigation.
- Weekly download numbers - Higher is normally better. Check the public registry if in doubt regarding a package
Block / allow-only specific packages
Known malicious packages can of course be blocked with the Block policy to ensure they are not used by your organization. And the reverse, to allow only known, good and approved package versions is also an applicable approach.
And what about our example - reavt
So what about our example package reavt?
Does it have thousands of downloads does it have each week? Not exactly. It usually has between 1 and 200 downloads each week.
And what does it do? If you run npm install reavt you are greeted with a friendly error message notifying you that you most likely wanted to install react instead.
But the simple fact that the package is continuously downloaded illustrates the fact that typos do happen.
Want to give Bytesafe a try? Go ahead and Sign up for Bytesafe.
