A coordinated token farming campaign continues to flood the open source npm registry, with tens of thousands of infected packages created almost daily to steal tokens from unsuspecting developers using the Tea Protocol to reward coding work.
On Thursday, researchers at Amazon said there were over 150,000 packages in the campaign. But in an interview on Friday, an executive at software supply chain management provider Sonatype, which wrote about the campaign in April 2024, told CSO that number has now grown to 153,000.
“It’s unfortunate that the worm isn’t under control yet,” said Sonatype CTO Brian Fox.
And while this payload merely steals tokens, other threat actors are paying attention, he predicted.
“I’m sure somebody out there in the world is looking at this massively replicating worm and wondering if they can ride that, not just to get the Tea tokens but to put some actual malware in there, because if it’s replicating that fast, why wouldn’t you?”
When Sonatype wrote about the campaign just over a year ago, it found a mere 15,000 packages that appeared to come from a single person.
With the swollen numbers reported this week, Amazon researchers wrote that it’s “one of the largest package flooding incidents in open source registry history, and represents a defining moment in supply chain security.”
This campaign is just the latest way threat actors are taking advantage of security holes in a number of open source repositories, which runs the risk of damaging the reputation of sites like npm, PyPI and others.
Related content: Supply chain attacks and their consequences
“The malware infestation in open-source repositories is a full-blown crisis, out of control and dangerously eroding trust in the open-source upstream supply chain,” said Dmitry Raidman, CTO of Cybeats, which makes a software bill of materials solution.
As evidence, he pointed to the Shai‑Hulud worm’s rapid exploitation of the npm ecosystem, which shows how quickly attackers can hijack developer tokens, corrupt packages, and propagate laterally across the entire dependency ecosystem. “What began as a single compromise explodes in a few hours, leaving the whole ecosystem and every downstream project in the industry at risk in a matter of days, regardless of whether it is open source or commercial.”
This past September, Raidman wrote about the compromise of the Nx build system after threat actors pushed malicious versions of the package into npm. Within hours, he wrote, developers around the world were unknowingly pulling in code that stole SSH keys, authentication tokens, and cryptocurrency wallets.
These and more recent large scale uploads of malicious packages into open source repositories are “just the beginning,” he warned, unless developers and repository maintainers improve security.
The Amazon and Sonatype reports aren’t the first to detect this campaign. Australian researcher Paul McCarty of SourceCodeRed confirmed to us this is the worm he dubbed ‘IndonesianFoods’ in a blog this week.
The Tea Protocol
The Tea Protocol is a blockchain-based platform that gives open-source developers and package maintainers tokens called Tea as rewards for their software work. These tokens are also supposed to help secure the software supply chain and enable decentralized governance across the network, say its creators on their website.
Developers put Tea code that links to the blockchain in their apps; the more an app is downloaded, the more Tea tokens they get, which can then be cashed in through a fund. The worm scheme is an attempt to make the blockchain think apps created by the threat actors are highly popular and therefore earn a lot of tokens.
At the moment, the tokens have no value. But it is suspected that the threat actors are positioning themselves to receive real cryptocurrency tokens when the Tea Protocol launches its Mainnet, where Tea tokens will have actual monetary value and can be traded.
For now, says Sonatype’s Fox, the scheme wastes the time of npm administrators, who are trying to expel over 100,000 packages. But Fox and Amazon point out the scheme could inspire others to take advantage of other reward-based systems for financial gain, or to deliver malware.
What IT leaders and developers should do
To lower the odds of abuse, open source repositories should tighten their access control, limiting the number of users who can upload code, said Raidman of Cybeats. That includes the use of multi-factor authentication in case login credentials of developers are stolen, he said, and adding digital signing capabilities to uploaded code to authenticate the author.
IT leaders should insist all code their firm uses has a software bill of materials (SBOM), so security teams can see the components. They also need to insist developers know the versions of the open source code they include in their apps, and confirm only approved and safe versions are being used and not automatically changed just because a new version is downloaded from a repository.
Sonatype’s Fox said IT leaders need to buy tools that can intercept and block malicious downloads from repositories. Antivirus software is useless here, he said, because malicious code uploaded to repositories won’t contain the signatures that AV tools are supposed to detect.
In response to emailed questions, the authors of the Amazon blog, researchers Chi Tran and Charlie Bacon, said open source repositories need to deploy advanced detection systems to identify suspicious patterns like malicious configuration files, minimal or cloned code, predictable code naming schemes and circular dependency chains.
“Equally important,” they add, “is monitoring package publishing velocity, since automated tools create at speeds no human developer could match. In addition, enhanced author validation and accountability measures are crucial for prevention. This includes implementing stronger identity verification for new accounts, monitoring for coordinated publishing activity across multiple developer accounts, as seen in this campaign, and applying ‘guilt by association’ principles where packages from accounts linked to malicious activity receive heightened scrutiny. Repositories should also track behavioral patterns like rapid account creation followed by mass package publishing, which are hallmarks of automated abuse.”
CISOs discovering these packages in their environments “face an uncomfortable reality,” the Amazon authors add: “Their current security controls had failed to detect a coordinated supply chain attack.”
SourceCodeRed’s McCarty said IT leaders need to protect developers’ laptops, as well as their automated continuous integration and delivery pipelines (CI/CD). Traditional security tools like EDR and SCA don’t scan for malware, he warned. “The number of people that buy Snyk thinking it does this is huge,” he said.
McCarty has created two open source malware scanning tools. One, opensourcemalware.com, is an open database of malicious content like npm packages. It can be checked to see if a package being used is malicious. The second is the automated open-source MALOSS tool, which is effectively a scanner that checks opensourcemalware.com and other sources automatically. MALOSS can be used in a CI/CD pipeline or on a local workstation.
He also recommends the use of a commercial or open source package firewall, which effectively allows a developer to only install approved packages.
“The enterprise has more options than I think they realize,” he told CSO. “They just often don’t realize that there are tools and solutions to address this risk. Maturity is really low in this space.”
This article originally appeared on InfoWorld.
