Hackers infected hundreds of npm packages with ransomware

The hacking of a single account on GitHub turned into the largest epidemic in the programming world in recent months: the infected code within a few hours spread across hundreds of libraries used by millions of developers around the world, including Russian.

It all started with one password

On August 4, someone gained access to the account of a developer named Jared Wray, a man who for years maintained two small but extremely popular tools for programmers: keyv and cacheable. These are libraries for jаvascript that help programs temporarily “remember” data so as not to request it again — something like a cache in a browser, only inside the code. It would seem like a trifle, writes xrust. But it is precisely such “little things” that half the Internet rests on: keyv alone has over 127 million downloads per week.

Having gained access to the account, the attacker quietly made changes directly to the main branch of the repository around 9 a.m. GMT and almost immediately released a new “version” of the package. Within minutes, the infected code appeared in eight more linked libraries by the same author.

How a harmless update turns into sabotage

Here it is worth explaining how installing programs for developers generally works. When a programmer connects someone else’s library to his project through the npm package manager, it’s like downloading an application from a store, only this store is open to everyone, and anyone can put something there. During installation, the package can automatically execute a service script — for example, to customize something for the user’s system. This function became a weapon.

Just such a script was added to the infected versions: it quietly downloaded the legitimate Bun program (this is an alternative engine for running jаvascript code) and with its help launched the actual malicious content — about 700 kilobytes of confusing, specially mutilated code, which analysts could not immediately read with their eyes.

And then the most unpleasant thing began: the parasite program scoured the computer or server in search of anything that looked like passwords and access keys — npm tokens, access to the Amazon cloud, GitHub keys, Kubernetes configurations and even crypto wallets. Everything found was encrypted and quietly sent to the “owner” — so that only he himself could decipher what was stolen.

A worm that copies itself

An ordinary virus program would have calmed down on this. But here the scenario turned out to be much more inventive: if the infected machine had the developer’s access keys to npm, the malware used them to… publish infected versions of its own packages. The result is a classic chain reaction: one compromised account infects the library, through it — the computer of another developer, and he unwittingly infects his own projects. By the evening of the same day, the number of infected packages had grown to hundreds, and versions to thousands.

Security experts quickly dubbed the attack after the fantastic giant worms from Dune — this is not the first such epidemic in the npm world, and in style it resembles past waves of the same family of malware.

The most alarming thing is that the code looks absolutely “real”

A separate headache for specialists is that the infected packages went through the official, completely legal GitHub build system and received a real, verifiable digital signature. Formally, everything is clean: the code is actually collected in the same repository, by the same automatic process. It's just that the code itself is malicious. That is, the usual ways to check “is this really the official version?” in this case, they are powerless: the fake is indistinguishable from the original with all its seals and signatures.

The stolen data leaked in two ways. The main one is through hundreds of specially created public repositories on GitHub with a self-explanatory name in the description, referring to those same “worms”. The backup channel is a separate website, the address of which the attacker can change at any time: the program pulls the required domain each time from a smart contract in the Ethereum blockchain, so it will not be possible to block the infrastructure in one fell swoop.

What does this mean for the average developer — and not only

History with keyv — not an isolated case, but another reminder of the chronic disease of all modern software development. We are used to assembling programs from hundreds of other people's “cubes” — libraries written by strangers, which we, in fact, blindly trust. One compromised password from one not-so-famous author and thousands of companies are at risk, using his code somewhere deep in their systems, often without even knowing it.

For Russian companies that actively use open jаvascript libraries in the web and backend, the risk is exactly the same: npm is an international ecosystem without borders, and an infected package can be equally likely to end up in a startup from San Francisco, and in an online store from Yekaterinburg. Security experts unanimously advise what many previously considered excessive reinsurance: do not allow packages to automatically run scripts during installation, regularly check the versions of dependencies in projects and, if there is a suspicion of infection, change all passwords and access keys that the infected computer could theoretically reach.

By the time of publication, more than two thousand infected versions of packages had been posted online, and the list continues to grow — security specialists are monitoring the situation in real time.

Sources: wiz.io, microsoft.com, snyk.io

Xrust Hackers infected hundreds of npm packages data ransomware virus