:
Skip Navigation
Resources Blog Crypto enthusiasts flood npm with more than 281,000 bogus ...

Crypto enthusiasts flood npm with more than 281,000 bogus packages overnight

Crypto enthusiasts flood npm with more than 281,000 bogus packages overnight
6:23

Crypto enthusiasts have lately been flooding software registries like npm and PyPI with thousands of bogus packages that add no functional value and instead put a strain on the entire open source ecosystem.

A single instance, recorded by Sonatype in July 2024, saw 281,512 distinct packages appearing on the npmjs.com registry overnight — each package named a gibberish Latin phrase akin to Lorem Ipsum. 

The world's largest JavaScript registry remains a target for miscreants who keep flooding it

Last month, our systems noticed something strange: 281,512 distinct npm components appearing in a short span (a day) overnight.

Tracked as sonatype-2024-1996, this uptick was caused by just a handful of npm accounts relentlessly publishing new packages with gibberish, Latin names.

An example package, '@zitterorg/a-eius-dolorem' ("eius-dolorem" translates to "his pain" in English), describes itself as an ESLint "plugin" and is among a set of 300+ packages published by one npm account alone.

This package lists several other packages published by the same author under its dependencies:

What do these packages do?

Many of these contain skeleton code, while others contain code forked from a GitHub repository called, ReguideWIKI/teaSimple-vCore, which is related to a blockchain-based project called "Tea," a protocol designed to reward OSS developers in the form of crypto "tokens."

Most of the files in the "lib" folder of the repository are empty or contain comments (no code) making them functionally useless. Interestingly, it's the "web3c.js" file in almost every package that helps us link distinct 215,000 versions of different packages to this single campaign.

The author of these packages has yet to change the hardcoded blockchain addresses in the file to theirs:

 

Not the first flood, but begs the question

Abuse of open source registries like npm and PyPI is a growing problem, particularly when these are flooded in a brief span of time.

Traditionally launched to make it easy for developers to publish and distribute their components with minimal friction, these registries have become a hot bed for users using them for unconventional means: from hosting movies ripped from DVDs, to spamming them with pirate links for SEO, to now being abused by blockchain enthusiasts.

In an April 2024 incident identified by Sonatype, some developers flooded npm registry with 15,000 bogus packages to reward themselves with Tea (crypto) tokens.

Other than potentially violating the terms of service of these registries, spikes like these can and have caused Denial of Service (DoS) attacks on a registry — a real threat to the entire open source ecosystem and developers who rely on these platforms to fetch components during the course of developing applications.

Moreover, the act of @zitterorg/... packages interlinking each other via "dependencies," may not necessarily generate Tea tokens for their publisher but risks causing a problem with their removal, similar to the 'everything' incident.

Essentially, when installed, "everything" attempted to download every single npm package that's ever been published to the registry to your machine, by resolving what is referred to as transitive dependencies. Other than causing a DoS (storage space shortage) on the machine it was installed on, "everything" blocked all npm developers from removing their own packages from npmjs.com registry.

Even if these packages did not contain obvious malicious code, the spikes could be a smokescreen, designed to distract sysadmins and security analysts from real threats being snuck onto these platforms or packages over time.

At the same time, cases like these fall under a "gray" area from a registry hygiene and policing perspective.

It is, by itself, not illicit for example, to fork an existing open source package and publish thousands of copies of it on npm. Forking and cloning are the basic principles that empower much of the open source software development. However, these floods in turn, end up putting a strain on a registry's resources without adding any value and potentially cause problems for other parties and developers relying on these registries.

Sonatype Repository Firewall stays on top of floods, blocks unsafe components

Time and time again, we have seen proof-of-concept campaigns eventually turning rogue and evolving into info-stealing campaigns and even "researchers" introducing malicious code into legitimate OSS components. As such, it may be neglectful to dismiss seemingly-benign campaigns like these — just because these are not malicious today, does not mean they won't become so tomorrow.

Among so much noise out there in the wild, picking safe open source components remains a key priority and a battle for developers without any form of automation in place.

Sonatype products including Sonatype Lifecycle and Sonatype Repository Firewall make this process a breeze by automatically blocking malicious components, vulnerable components, and Potentially Unwanted Applications (PUAs) from reaching your builds.

Our proprietary technologies such as "Secondary Expansion" and Advanced Binary Fingerprinting are additionally able to extrapolate our existing research to components published in the future and can therefore block unsuspected campaigns that may appear tomorrow without notice:

Instances of threat actors creating and distributing malicious software components through public open source repositories have gained popularity and are rapidly expanding.

Between 2019 and May 2024, Sonatype caught more than 342,922 individual malicious projects — a figure that has almost doubled after this incident:

Malicious open source is designed to evade typical software composition analysis (SCA) scanners. However, users of Sonatype Repository Firewall can rest easy knowing that these packages would automatically be blocked from reaching their development builds and keep their software development life cycle (SDLC) hygienic.

SmartRepo-06272024@2x

Picture of Ax Sharma

Written by Ax Sharma

Ax is a Staff Security Researcher & Malware Analyst at Sonatype with a penchant for open source software. His works and expert analyses have frequently been featured by leading media outlets including the BBC. Ax's expertise lies in security vulnerability research, reverse engineering, and cybercrime investigations. He has a passion for educating a wide range of audiences through writing and vlogs.