Package Planting: Are You [Unknowingly] Maintaining Poisoned Packages?

Aqua’s Team Nautilus found a logical flaw in npm that allows threat actors to masquerade a malicious package as legitimate and trick unsuspecting developers into installing it. Up until recently, npm allowed adding anyone as a maintainer of the package without notifying these users or getting their consent. Since you could assign poisoned packages under any popular maintainers, we named this logical flaw and its implications “package planting”. We reported these techniques to the npm team and they fixed the underlying issue.

What is package planting?

Npm users can add others as package maintainers without getting these users’ approval.

An attacker can create a malicious npm package and add a few users as its maintainers. If the attacker carefully handpicks these future maintainers, this will affect the reputation and appearance of the package. In other words, an attacker can build a malicious package and add trusted and popular maintainers.

For instance, the package lodash is highly popular and credible. If we add its owners Mathias, jdalton, and bnjmnt4n to a new, malicious package, many developers may be tricked into thinking that this package is legitimate and even appealing.

Below are a couple of scenarios for package planting.

Masquerading a malicious package

An attacker can take any malicious package and masquerade it to look legitimate and attractive by using package planting. Here, we illustrate the concept and show how it was possible to take advantage of this flaw:

1. Create and publish an npm package with the name fb_npm_package.
   
2. Add the users we wish to incriminate as owners. In this case, we chose to use npm and the Facebook npm profiles.
   3. Remove ourselves from the package.

So, with these three simple steps, npm and Facebook are now the owners of our package, and it looks legitimate from all perspectives. The new “forced maintainer” isn’t aware that someone added him as the package maintainer.

The main problem is that any npm user can perform this and add other npm users as maintainers of their own package. The proper invite confirmation mechanism would have prevented this: as it currently works when adding a user to your organization on npm or when inviting collaborators on GitHub.

Developer defamation

An attacker can use package planting to create a malicious package, add developers in npm he wishes to defame, and report to npm that these developers are abusing the platform. This can lead to embarrassing the developer or even banning them from the platform. If you think that this scenario isn’t plausible, here’s an interesting story that will change your mind.

WhatsApp banned users that were part of the groups with insensitive names that may imply illegal or malicious activity. In some cases, a member of the group as a joke changed the name of the group to the one that suggested illegal activity. As a result, each member of the group was immediately blocked on WhatsApp.

In other cases, a malicious actor created a new group, added other contacts (whose WhatsApp settings allowed this), then renamed the group, which caused WhatsApp to ban all its team members.

The patch: Confirmation mechanism

Npm promptly fixed the flaw after we reported it by adding a confirmation mechanism for all new package maintainers.

At the moment, the issue has been resolved, and adding a new maintainer without confirmation from the user is no longer possible.

Now, when you invite new maintainers, an email with an invitation link will be sent to their email address:

Summary

The issue described in this blog was fixed by npm, and there’s no way to replicate it at this moment. We’d like to thank the GitHub/npm security team for their quick response and professional remediation process.

Over the past few years, open source projects have significantly improved their security. However, attackers get more sophisticated and come up with new ways to exploit them.

Eventually, developers are responsible for what open source packages they use when building applications. To mitigate the risks, it’s important to use reliable sources for any third-party components and to secure your environment with solutions that can detect software supply chain threats such as package planting.

Finally, npm users should check that all the packages that are listed under their name truly belong to them, to make sure they weren’t added to any projects without their consent.

The timeline of the discovery

• 10-02-2022: The issue was reported to GitHub’s bug bounty program at HackerOne.
• 13-02-2022: Response received from GitHub that this issue is being tracked internally and they are actively working on remediating it.
• 26-04-2022: Issue patched on npmjs.com.