Login
At least 18 popular JavaScript code packages that are collectively downloaded more than two billion times each week were briefly compromised with malicious software today, after a developer involved in maintaining the projects was phished. The attack appears to have been quickly contained and was narrowly focused on stealing cryptocurrency. But experts warn that a similar attack with a slightly more nefarious payload could lead to a disruptive malware outbreak that is far more difficult to detect and restrain.
This phishing email lured a developer into logging in at a fake NPM website and supplying a one-time token for two-factor authentication. The phishers then used that developer’s NPM account to add malicious code to at least 18 popular JavaScript code packages.
Aikido is a security firm in Belgium that monitors new code updates to major open-source code repositories, scanning any code updates for suspicious and malicious code. In a blog post published today, Aikido said its systems found malicious code had been added to at least 18 widely-used code libraries available on NPM (short for) “Node Package Manager,” which acts as a central hub for JavaScript development and the latest updates to widely-used JavaScript components.
JavaScript is a powerful web-based scripting language used by countless websites to build a more interactive experience with users, such as entering data into a form. But there’s no need for each website developer to build a program from scratch for entering data into a form when they can just reuse already existing packages of code at NPM that are specifically designed for that purpose.
Unfortunately, if cybercriminals manage to phish NPM credentials from developers, they can introduce malicious code that allows attackers to fundamentally control what people see in their web browser when they visit a website that uses one of the affected code libraries.
According to Aikido, the attackers injected a piece of code that silently intercepts cryptocurrency activity in the browser, “manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user.”
“This malware is essentially a browser-based interceptor that hijacks both network traffic and application APIs,” Aikido researcher Charlie Eriksen wrote. “What makes it dangerous is that it operates at multiple layers: Altering content shown on websites, tampering with API calls, and manipulating what users’ apps believe they are signing. Even if the interface looks correct, the underlying transaction can be redirected in the background.”
Aikido said it used the social network Bsky to notify the affected developer, Josh Junon, who quickly replied that he was aware of having just been phished. The phishing email that Junon fell for was part of a larger campaign that spoofed NPM and told recipients they were required to update their two-factor authentication (2FA) credentials. The phishing site mimicked NPM’s login page, and intercepted Junon’s credentials and 2FA token. Once logged in, the phishers then changed the email address on file for Junon’s NPM account, temporarily locking him out.
Aikido notified the maintainer on Bluesky, who replied at 15:15 UTC that he was aware of being compromised, and starting to clean up the compromised packages.
Junon also issued a mea culpa on HackerNews, telling the community’s coder-heavy readership, “Hi, yep I got pwned.”
“It looks and feels a bit like a targeted attack,” Junon wrote. “Sorry everyone, very embarrassing.”
Philippe Caturegli, “chief hacking officer” at the security consultancy Seralys, observed that the attackers appear to have registered their spoofed website — npmjs[.]help — just two days before sending the phishing email. The spoofed website used services from dnsexit[.]com, a “dynamic DNS” company that also offers “100% free” domain names that can instantly be pointed at any IP address controlled by the user.
Junon’s mea cupla on Hackernews today listed the affected packages.
Caturegli said it’s remarkable that the attackers in this case were not more ambitious or malicious with their code modifications.
“The crazy part is they compromised billions of websites and apps just to target a couple of cryptocurrency things,” he said. “This was a supply chain attack, and it could easily have been something much worse than crypto harvesting.”
Akito’s Eriksen agreed, saying countless websites dodged a bullet because this incident was handled in a matter of hours. As an example of how these supply-chain attacks can escalate quickly, Eriksen pointed to another compromise of an NPM developer in late August that added malware to “nx,” an open-source code development toolkit with as many as six million weekly downloads.
In the nx compromise, the attackers introduced code that scoured the user’s device for authentication tokens from programmer destinations like GitHub and NPM, as well as SSH and API keys. But instead of sending those stolen credentials to a central server controlled by the attackers, the malicious code created a new public repository in the victim’s GitHub account, and published the stolen data there for all the world to see and download.
Eriksen said coding platforms like GitHub and NPM should be doing more to ensure that any new code commits for broadly-used packages require a higher level of attestation that confirms the code in question was in fact submitted by the person who owns the account, and not just by that person’s account.
“More popular packages should require attestation that it came through trusted provenance and not just randomly from some location on the Internet,” Eriksen said. “Where does the package get uploaded from, by GitHub in response to a new pull request into the main branch, or somewhere else? In this case, they didn’t compromise the target’s GitHub account. They didn’t touch that. They just uploaded a modified version that didn’t come where it’s expected to come from.”
Eriksen said code repository compromises can be devastating for developers, many of whom end up abandoning their projects entirely after such an incident.
“It’s unfortunate because one thing we’ve seen is people have their projects get compromised and they say, ‘You know what, I don’t have the energy for this and I’m just going to deprecate the whole package,'” Eriksen said.
Kevin Beaumont, a frequently quoted security expert who writes about security incidents at the blog doublepulsar.com, has been following this story closely today in frequent updates to his account on Mastodon. Beaumont said the incident is a reminder that much of the planet still depends on code that is ultimately maintained by an exceedingly small number of people who are mostly overburdened and under-resourced.
“For about the past 15 years every business has been developing apps by pulling in 178 interconnected libraries written by 24 people in a shed in Skegness,” Beaumont wrote on Mastodon. “For about the past 2 years orgs have been buying AI vibe coding tools, where some exec screams ‘make online shop’ into a computer and 389 libraries are added and an app is farted out. The output = if you want to own the world’s companies, just phish one guy in Skegness.”
Image: https://infosec.exchange/@GossiTheDog@cyberplace.social.
Aikido recently launched a product that aims to help development teams ensure that every code library used is checked for malware before it can be used or installed. Nicholas Weaver, a researcher with the International Computer Science Institute, a nonprofit in Berkeley, Calif., said Aikido’s new offering exists because many organizations are still one successful phishing attack away from a supply-chain nightmare.
Weaver said these types of supply-chain compromises will continue as long as people responsible for maintaining widely-used code continue to rely on phishable forms of 2FA.
“NPM should only support phish-proof authentication,” Weaver said, referring to physical security keys that are phish-proof — meaning that even if phishers manage to steal your username and password, they still can’t log in to your account without also possessing that physical key.
“All critical infrastructure needs to use phish-proof 2FA, and given the dependencies in modern software, archives such as NPM are absolutely critical infrastructure,” Weaver said. “That NPM does not require that all contributor accounts use security keys or similar 2FA methods should be considered negligence.”
Like its Windows counterpart, Winpmem, this is not a traditional memory dumper. Linpmem offers an API for reading from any physical address, including reserved memory and memory holes, but it can also be used for normal memory dumping. Furthermore, the driver offers a variety of access modes to read physical memory, such as byte, word, dword, qword, and buffer access mode, where buffer access mode is appropriate in most standard cases. If reading requires an aligned byte/word/dword/qword read, Linpmem will do precisely that.
Currently, the Linpmem features:
Cache Control is to be added in future for support of the specialized read access modes.
At least for now, you must compile the Linpmem driver yourself. A method to load a precompiled Linpmem driver on other Linux systems is currently under work, but not finished yet. That said, compiling the Linpmem driver is not difficult, basically it's executing 'make'.
You need make and a C compiler. (We recommend gcc, but clang should work as well).
Make sure that you have the linux-headers installed (using whatever package manager your target linux distro has). The exact package name may vary on your distribution. A quick (distro-independent) way to check if you have the package installed:
FreshRSS 
ls -l /usr/lib/modules/`uname -r`/
That's it, you can proceed to step 2.
Foreign system: Currently, if you want to compile the driver for another system, e.g., because you want to create a memory dump but can't compile on the target, you have to download the header package directly from the package repositories of that system's Linux distribution. Double-check that the package version exactly matches the release and kernel version running on the foreign system. In case the other system is using a self-compiled kernel you have to obtain a copy of that kernel's build directory. Then, place the location of either directory in the KDIR environment variable.
export KDIR=path/to/extracted/header/package/or/kernel/root
Compiling the driver is simple, just type:
make
This should produce linpmem.ko in the current working directory.
You might want to check precompiler.h before and chose whether to compile for release or debug (e.g., with debug printing). There aren't much other precompiler settings right now.
The linpmem.ko module can be loaded by using insmod path-to-linpmem.ko, and unloaded with rmmod path-to-linpmem.ko. (This will load the driver only for this uptime.) If you compiled for debug, also take a look at dmesg.
After loading, for talking to the driver, you need to create the device:
mknod /dev/linpmem c 42 0
If you can't talk to the driver, potentially check in dmesg log to verify that '42' was indeed the registered major:
[12827.900168] linpmem: registered chrdev with major 42
Though usually the kernel would try to really assign this number.
You can use chown on the device to give it to your user, if you do not want to have a root console open all the time. (Or just keep using it in a root console.)
There is an example code demonstrating and explaining (in detail) how to interact with the driver. The user-space API reference can furthermore be found in ./userspace_interface/linpmem_shared.h.
This code is important, if you want to understand how to directly interact with the driver instead of using a library. It can also be used as a short function test.
There is an (optional) basic command line interface tool to Linpmem, the pmem CLI tool. It can be found here: https://github.com/vobst/linpmem-cli. Aside from the source code, there is also a precompiled CLI tool as well as the precompiled static library and headers that can be found here (signed). Note: this is a preliminary version, be sure to check for updates, as many additions and enhancements will follow soon.
The pmem CLI tool can be used for testing the various functions of Linpmem in a (relatively) safe and convenient manner. Linpmem can also be loaded by this tool instead of using insmod/rmmod, with some extra options in future. This also has the advantage that pmem auto-creates the right device for you for immediate use. It is extremely portable and runs on any Linux system (and, in fact, has been tested even on a Linux 2.6).
$ ./pmem -h
Command-line client for the linpmem driver
Usage: pmem [OPTIONS] [COMMAND]
Commands:
insmod Load the linpmem driver
help Print this message or the help of the given subcommand(s)
Options:
-a, --address <ADDRESS> Address for physical read operations
-v, --virt-address <VIRT_ADDRESS> Translate address in target process' address space (default: current process)
-s, --size <SIZE> Size of buffer read operations
-m, --mode <MODE> Access mode for read operations [possible values: byte, word, dword, qword, buffer]
-p, --pid <PID> Target process for cr3 info and virtual-to-physical translations
--cr3 Query cr3 value of target process (default: current process)
--verbose Display debug output
-h, --help Print help (see more with '--help')
-V, --version Print version
If you want to compile the cli tool yourself, change to its directory and follow the instructions in the (cli) Readme to build it. Otherwise, just download the prebuilt program, it should work on any Linux. To load the kernel driver with the cli tool:
# pmem insmod path/to/linpmem.ko
The advantage of using the pmem tool to load the driver is that you do not have to create the device file yourself, and it will offer (on next releases) to choose who owns the linpmem device.
The pmem command line interface is only a thin wrapper around a small Rust library that exposes an API for interfacing with the driver. More advanced users can also use this library. The library is automatically compiled (as static portable library) along with the pmem cli tool when compiling from https://github.com/vobst/linpmem-cli, but also included (precompiled) here (signed). Note: this is a preliminary version, more to follow soon.
If you do not want to use the usermode library and prefer to interface with the driver directly on your own, you can find its user-space API/interface and documentation in ./userspace_interface/linpmem_shared.h. We also provide example code in demo/test.c that explains how to use the driver directly.
Not implemented yet.
If the system reports the following error message when loading the module, it might be because of secure boot:
$ sudo insmod linpmem.ko
insmod: ERROR: could not insert module linpmem.ko: Operation not permitted
There are different ways to still load the module. The obvious one is to disable secure boot in your UEFI settings.
If your distribution supports it, a more elegant solution would be to sign the module before using it. This can be done using the following steps (tested on Ubuntu 20.04).
$ sudo apt install mokutil
$ openssl req -new -newkey rsa:4096 -keyout mok-signing.key -out mok-signing.crt -outform DER -days 365 -nodes -subj "/CN=Some descriptive name/"
$ sudo mokutil --import mok-signing.crt
$ /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 path/to/mok-singing/MOK.key path/to//MOK.cert path/to/linpmem.ko
After that, you should be able to load the module.
Note that from a forensic-readiness perspective, you should prepare a signed module before you need it, as the system will reboot twice during the process described above, destroying most of your volatile data in memory.
(Please report potential issues if you encounter anything.)
Linpmem, as well as Winpmem, would not exist without the work of our predecessors of the (now retired) REKALL project: https://github.com/google/rekall.
Our open source contributors:
