Business

NPM flaw let attackers add anyone as maintainer to malicious packages

Published

on

A ‘logical flaw’ in the npm registry enabled authors of malicious packages to quietly add anyone and any number of users as ‘maintainers’ to their packages in an attempt to boost the trust in their packages.

The GitHub-owned repository of NodeJS components has now fixed the flaw after the issue was responsibly reported by cloud native security company, Aqua.

Package planting: add any popular dev or company as a maintainer

A security flaw in the npm registry, dubbed ‘package planting’ allowed threat actors to silently add any developer (and any number of them) as ‘maintainers’ to their malicious packages.

“Up until recently, npm allowed adding anyone as a maintainer of the package without notifying these users or getting their consent,” explains Yakir Kadkoda, a security researcher at Aqua’s Team Nautilus.

The move would neither notify nor require any approval from the person or company being added as a maintainer to an illicit package.

To make matters worse, after adding other maintainers to their malicious package, the attacker could quietly remove themselves from the list of the package’s maintainers—now leaving only new maintainers on the package who have got nothing to do with it.

A technique like this can turn out to be extremely lucrative for a threat actor looking to lend credibility to their malicious components.

By adding credible developers, and popular companies as maintainers to their malicious packages, attackers have much better chances of tricking developers into installing their packages without raising an eyebrow. 

To better demonstrate the concept, Kadkoda published a test package, ‘fb_npm_package’ to the registry, initially with his demo npm account being the only maintainer on the package.

The researcher then added the official accounts of Facebook (Meta) and npm to the project’s list of maintainers, and then removed himself.

An example ‘fb_npm_package’ library with Facebook added as a maintainer (BleepingComputer)

Anyone visiting the npm page of ‘fb_npm_package’ would now perceive the package’s ownership to exclusively include Facebook and npm, which is highly misleading.

In March 2021, as reported by BleepingComputer, security researcher Alex Birsan had also applied one use case of the technique to get his fake, test package listed on Microsoft Azure SDK’s official site.

“Since you could assign poisoned packages under any popular maintainers, we named this logical flaw and its implications ‘package planting,'” writes the Aqua researcher in a report published this week.

Granted, source code control systems like GitHub do allow some room for pranks where code commits can be submitted on anyone’s behalf—some have time and time again made mock commits appearing to come from Linux kernel creator Linus Torvalds. But, cryptographical features like GPG signing make it possible to authoritatively sign code commits and eliminate any and all doubt with regard to their origin.

Things get more complicated, however, when a project’s entire ownership and list of maintainers is altered—that too in a software registry designed to ship finished packages, not source code.

A matter of reputation, not just security

Kadkoda stresses that other than being a security flaw, a technique like “package planting” can be abused by adversaries to tarnish the reputation of otherwise well-respected developers in the community.

“If the attacker carefully handpicks these future maintainers, this will affect the reputation and appearance of the package,” states Kadkoda.

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

Should the malicious package later be caught by npm, one plausible scenario that comes to mind is the registry potentially suspending the “new” maintainers’ accounts who are erroneously perceived to be in violation of the platform’s policies.

Kadkoda did eventually take down his test package from npm and reported the flaw to npm.

An archived copy of ‘fb_npm_package’ obtained from open source security firm Sonatype that I’m a part of, shows the package is clean and comprises no functional code, just a manifest file:

Inside Aqua’s ‘fb_npm_package’ mock library (BleepingComputer)

But, an opportunistic threat actor can achieve far more with a flaw like “package planting.”

Even without such flaws, attackers have been able to repeatedly poison open source repos—npmPyPI, and RubyGems, with malicious packages garnering thousands of downloads.

A technique like this would further empower threat actors to add a major seal of legitimacy to their otherwise illicit and malicious packages.

Aqua reported its findings to GitHub’s HackerOne bug bounty program on February 10th and received an acknowledgment on the 13th.

By April 26th, GitHub fixed the flaw on npmjs.com and introduced safeguards:

Inviting a new maintainer to your npm package now asks them to approve your request before they can be added to your project.

npm now asks newly added project maintainers to accept the invite (Aqua)

There is no way to replicate the issue anymore on npm, nor any indication so far that the technique was actively leveraged by threat actors.

Regardless, Kadkoda warns existing developers to double-check the projects listed under their npm account:

“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,” concludes the researcher.

Update April 28th, 08:14 ET: Added reference to Alex Birsan having demonstrated one use case of the technique in 2021.

Source: https://www.bleepingcomputer.com/news/security/npm-flaw-let-attackers-add-anyone-as-maintainer-to-malicious-packages/

Click to comment
Exit mobile version