Just last week we saw the popular npm package `ua-parser-js` get hijacked. Malicious actors gained access to the project maintainer's npm account and published malicious versions that attempted to install a cryptominer on the compromised system and download a malicious DLL in charge of stealing credentials.
Well, it happened again. This time the `coa` and `rc` packages were hijacked, via an npm account takeover. The hijacked versions of these packages are tracked under sonatype-2021-1696.
Coa is a command line option parser with over 9 Million weekly downloads which hasn't been legitimately updated in 3 years. `Rc` is used to easily load configuration options with an astounding 14 million weekly downloads and just like Coa, it hasn't seen a new release in 3 years. Coincidence? Or, clue as to how attackers are choosing their targets?
Much like `ua-parser-js`, these packages are also used by tech industry giants, such as Microsoft and Meta (Facebook), according to grep.app results:
It all happened pretty quickly, but as soon as Sonatype became aware of the malicious versions of `coa` and `rc` appearing on npm, we expedited Deep Dive research on them.
What's inside the malicious `coa` and `rc` versions?
The malicious versions leverage built-in certutil binaries, also known as 'LOLBins,' to download a password stealing trojan, possibly Danabot once again. No crypto miner this time, but the same techniques are present, which indicate it is likely the same threat actors.
A lot of users quickly noticed this and began commenting on the project's GitHub Issues page. This was actually really helpful, the user that created the issue even shared the diff of the malicious version vs. the older legitimate one. This gave us an idea where to start looking.
A new preinstall script had been included in the package.json file that executed the compile.js script. Something interesting is that not all malicious versions actually had the compile.js and compile.bat files, perhaps they were tests, only version 2.0.4 and 2.1.1 were fully equipped with the payload.
Once we took a look at the JavaScript file we noticed it was obfuscated, not as heavily as some real head-scratchers we've seen, but still not really readable. After some de-obfuscation we had something we could make sense of.
All this was trying to hide from us is that it wants to run a Batch script, can it be that bad?
So now a new player now comes into play, compile.bat. This file implemented the variable expansion technique to attempt to hide its real intentions. All variable expansion really is, is a form of substitution cipher.
In the image above we see the variable `aim` defined as a sequence of seemingly random characters. Then we see a whole lot of variable expansion that looks like, %aim:~x,y%, where it's simply referencing our previously defined `aim` variable. X is the offset and y is the amount of characters to take. Notice that y is always 1. That way %aim:~4,1% really means aim[4] which is `e`. And at the end of it all, we have something like the following.
The attackers weren't taking any chances. They first attempt to download the payload with curl, in case that doesn't work they try with wget and then if that doesn't work either they go with the LOLBin certutil to do the trick. Finally, using the friend of all red teamers and likely some malicious actors, regsvr32.exe executes the DLL payload.
The DLL [VirusTotal] is a password-stealing trojan, likely Danabot, that was also seen in previous attacks. This trojan attempts to steal passwords from all flavors of web browsers, various applications including VNC and FTP clients, look for credit card numbers and even log keystrokes to report back to the attackers.
As quickly as all this took place, so did the fix; the malicious versions were removed from npm almost as soon as they were uploaded.
"Following ongoing investigations, we identified in real time multiple versions of the "rc" package containing identical malware to the "coa" package. malicious versions of "rc" were immediately removed from the registry and we have published an advisory," tweeted npm yesterday.
npm also suggests that open source project maintainers enable two-factor authentication to better protect their accounts.
All this raises two crucial questions:
-
How are the attackers choosing their targets? So far all hijacked components have been very popular with millions of weekly downloads.
-
And, more importantly, how do they keep compromising npm accounts? Easy to guess passwords? Or, a result of credential stuffing attacks?
Evolving open source supply-chain attacks warrant advanced protection
We've been saying for the past two years that developers are the "new" target for adversaries. This discovery, when added to the thousands of similar attacks Sonatype has been tracking, shows this attack vector is no longer novel, but has become the norm. We've come to a point where organizations can no longer ignore this reality. From Brandjacking, typosquatting, and cryptomining malware lurking in software repositories to critical vulnerabilities and next-gen supply-chain attacks, as well as copycat packages targeting well-known tech companies, advanced protection must be a part of everyone's 2022 plan.
The good news is, over the past few weeks, Sonatype's automated malware detection system has caught thousands of suspicious packages on npm. These components are either confirmed malicious, previously known to be malicious, or dependency confusion copycats.
We are now expanding our malware detection capabilities via Sonatype Intelligence to other ecosystems as well, such as PyPI.
All of this takes more than just due diligence and luck – it takes the expertise of experienced security professionals and hundreds of terabytes of data. In order to keep pace with malware mutations, Sonatype analyses every newly-released npm package to keep developers safe.
We help you remain proactive and safeguard your software supply chains against up-and-coming attacks. Our AI/ML-powered automated malware detection system (which is part of Sonatype Repository Firewall and powered by Sonatype Intelligence data), and security research team work together for full-spectrum protection. Sonatype determines a likely malicious component based on historical supply chain attacks and over five-dozen "signals." This insight enables flagging for potential new attacks before security researchers discover them.
As soon as our system flags a package or a dependency as "suspicious," it undergoes a quarantine queue for manual review by the Sonatype Security Research Team. Users of Sonatype Repository Firewall are then protected from these suspicious packages while the review is underway. Existing components are quarantined before they are pulled "downstream" into a developer's open source build environment.
Moreover, users that have enabled the "Dependency Confusion Policy" feature will get proactive protection from dependency confusion attacks. This works whether conflicting package names exist in a public repository or in your private, internal repos.
Sonatype's world-class security research data, combined with our automated malware detection technology safeguards your developers, customers, and software supply chain from infections.
