Source: www.securityweek.com – Author: Ionut Arghire
Threat actors injected malicious code into multiple highly popular NPM packages after their maintainers fell for a well-crafted phishing email.
The attack targeted several NPM package maintainers with messages asking them to update their two-factor authentication (2FA) information.
The emails were sent from the email address support[at]npmjs[dot]help. The messages directed victims to the npmjs[.]help domain that mimicked the npmjs.com website and created a sense of urgency by claiming that accounts with outdated 2FA credentials would be locked.
While some recipients found the email suspicious and reported the malicious website, package maintainer Josh Junon (Qix) fell for the trick, and the attackers took over his account.
A DuckDB maintainer was also phished, but the DuckDBLabs team was able to block the attacker’s access shortly after. However, the DuckDB distribution for Node.js on the NPM registry was injected with malware, the team announced.
The supply chain attack resulted in a total of 18 NPM packages maintained by Qix being poisoned. Collectively, these packages have over 2.5 billion weekly downloads.
The list includes ansi-styles, ansi-regex, backslash, chalk, chalk-template, color-convert, color-name, color-string, debug, error-ex, has-ansi, is-arrayish, simple-swizzle, slice-ansi, strip-ansi, supports-color, supports-hyperlinks, and wrap-ansi.
Junon disclosed the attack immediately after being locked out of his account and reported the intrusion to NPM, which started removing the malicious packages within two hours. The maintainer regained access to the account several hours later.
Advertisement. Scroll to continue reading.
The code injected in the compromised packages is a browser-based interceptor designed to hijack application APIs and network traffic. It scans for cryptocurrency-related transactions and replaces user-provided details with those of the attacker.
“That means any sensitive identifiers, such as payment destinations or approval targets, can be swapped out for attacker, controlled ones before the user even sees or signs them. To make the changes harder to notice, it uses string-matching logic that replaces targets with look-alike values,” security firm Aikido explains.
“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 notes.
According to cybersecurity outfit Wiz, if the malicious package versions were incorporated in frontend builds and shipped as web assets during the short timeframe they were available for download, the malicious payload would be executed in any browser loading the affected websites.
“A developer might happen to install a malicious version of one of the packages (or a dependent package) on their workstation, and the malicious code would then be bundled into applications they build. Alternatively, a CI/CD workflow might pull the latest available version of a package (or a dependent package), and use it as part of a build pipeline,” Wiz notes.
If the packages are used exclusively server-side, the impact is minimal, the cybersecurity firm says. Environments serving the poisoned code to users are at some level of risk, while applications that incorporate cryptocurrency wallets or payment flows are hit the most.
According to a GitHub advisory, any system on which the poisoned packages were installed should be considered fully compromised and all secrets and keys stored in that machine should be immediately rotated, from a different computer.
“The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it,” the advisory reads.
According to Wiz, cloud environments that resolved, bundled, and then served code using the infected package versions should be considered affected. These could be “production, staging, preview/pull request deployments, and local development servers used by employees”, Wiz says.
According to the security biz, 99% of cloud environments were running one of the packages prior to the attack, and the malicious code reached at least 10% of cloud environments.
“From this we can conclude that during the short 2-hour timeframe in which the malicious versions were available on NPM, the malicious code successfully reached 1 in 10 cloud environments. This serves to demonstrate how fast malicious code can propagate in supply chain attacks like this one,” Wiz says.
The overall impact from the attack, however, appears to be minimal, as the blockchain addresses included in the obfuscated code were swap contract addresses. Initial indicators suggest that the hackers stole almost no money during the attack.
Related: Ransomware Losses Climb as AI Pushes Phishing to New Heights
Related: High-Value NPM Developers Compromised in New Phishing Campaign
Related: Watch: The Four Stages of Zero Trust Maturity
Related: Ox Security Launches AI Agent That Auto-Generates Code to Fix Vulnerabilities
Original Post URL: https://www.securityweek.com/highly-popular-npm-packages-poisoned-in-new-supply-chain-attack/
Category & Tags: Application Security,Supply Chain Security,cryptocurrency,cryptojacking,Featured,NPM,Supply Chain – Application Security,Supply Chain Security,cryptocurrency,cryptojacking,Featured,NPM,Supply Chain
Views: 0