An NPM supply-chain attack dating back to December 2021 used dozens of malicious NPM modules containing obfuscated Javascript code to compromise hundreds of downstream desktop apps and websites.
As researchers at supply chain security firm ReversingLabs discovered, the threat actors behind this campaign (known as IconBurst) used typosquatting to infect developers looking for very popular packages, such as umbrellajs and ionic.io NPM modules.
If fooled by the very similar module naming scheme, they would add the malicious packages designed to steal data from embedded forms (including those used for sign-in) to their apps or websites.
For instance, one of the malicious NPM packages used in this campaign (icon-package) has over 17,000 downloads and is designed to exfiltrate serialized form data to several attacker-controlled domains.
IconBurst "relied on typo-squatting, a technique in which attackers offer up packages via public repositories with names that are similar to — or common misspellings of — legitimate packages," said Karlo Zanki, a reverse engineer at ReversingLabs.
"Furthermore, similarities between the domains used to exfiltrate data suggest that the various modules in this campaign are in the control of a single actor."
Some malicious modules still available for download
While the ReversingLabs team reached out to the NPM security team on July 1, 2022, to report its findings, some IconBurst malicious packages are still available on the NPM registry.
"While a few of the named packages have been removed from NPM, most are still available for download at the time of this report," Zanki added.
"As very few development organizations have the ability to detect malicious code within open source libraries and modules, the attacks persisted for months before coming to our attention."
Even though the researchers could compile a list of malicious packages used in the IconBurst supply-chain attack, its impact is yet to be determined, seeing that there's no way to know how much data and credentials were stolen via infected apps and web pages since December 2021.
The only metrics available at the time are the number of times each malicious NPM module has been installed, and ReversingLabs' stats are quite startling.
"While the full extent of this attack isn’t yet known, the malicious packages we discovered are likely used by hundreds, if not thousands of downstream mobile and desktop applications as well as websites," Zanki said.
"Malicious code bundled within the NPM modules is running within an unknown number of mobile and desktop applications and web pages, harvesting untold amounts of user data.
"The NPM modules our team identified have been collectively downloaded more than 27,000 times."
Comments
Icepop33 - 1 year ago
Thanks for the article. You guys rock!
FTLOYCD, if you're uh...slapping up a dynamic website, please use npm as a time-saver and not as a coding knowledge proxy. I will not use NPM until I know what I'm doing and can review the code and also understand EXAGTLY (lol) what packages might be being automatically updated. It's the least I can do to improve a worsening baseline security picture (after years of relative improvement). Hey, with automated code buddies and massive repositories, now everybody can write code! Well, no, no they can't. They can download it.
Big difference.
chadf - 1 year ago
Perhaps they should start implementing project signing. You only get this kind of signing "badge" if you have a project which is widely used (by actual users, not just download counts). Then when installing packages in secure mode (enabled by default), it will abort/complain if installing a new package which isn't signed.
Of course, the user would easily be able to install them anyway, either a blanket allow, or on a per package basis. Existing packages would be allowed to upgrade by default (i.e. grandfathered in) as not to break automated updates with the newer defaults. However, if an extra secure mode is enabled, then all non-signed ones would cause an error (unless otherwise white-listed). This might be of use to test if some project got their badge revoked and are no longer signed. Or maybe just emitting a warning (regardless of mode) when upgrading to a package version that is no longer signed, but previously was.
This kind of system would at least give developers a pause to perhaps ask themselves "why am I getting an error trying to install this well known library?"