A few days ago, CISA published an alert regarding malicious code discovered in an NPM package with close to 8 million weekly downloads, ”ua-parser-js". A few days before, security researchers from Sonatype published a blog post reporting 3 malicious NPM package.
A few connecting lines between these two incidents seems to suggest they are related.
Looking at the packages, we may be able to draw the chain of events connecting them to one another:
First, a threat actor managed to gain access to the NPM account of the owner of a popular package named “UAParser.js”. Understanding the potential impact, they decided to test their malicious code before deploying it into the legitimate package. The attacker wanted to refrain from making a small mistake that would expose the fact that the package was compromised, before they had a chance to make their profit. To do so, they experimented with a few packages of their own. However, these experiments were caught by security researchers. As a result, the attackers chose to add the malicious code to the “UAParser.js” package before the opportunity to profit was lost.
While this chain of events is just a theory for how this attack came to pass, it’s highly likely this is how it progressed. One thing for sure, it can give us a better understanding of an attacker’s way of thinking based upon the following:
A brief recap
On October’s 20, the Sonatype research team published a blog reporting on three malicious NPM packages from the username ‘wozheqirsplu’:
- okhsa
- klow
- klown
The report indicated that these packages, in different ways, function as a dropper for a crypto miner and could infect both Linux and Windows users.
The report also included an image of the ‘package.json’ file, which shows a preinstall script running ‘calc.exe’. This is a classic POC behavior for security folks in order to prove they can launch an executable file.
In addition, it seems that at least one of the three packages copied the description from the popular UA-parser.js and its GitHub repository. (The original Sonatype report redacted this piece of information at the time of publication, since the second incident hadn’t occurred yet.)
These clues lead me to think that the packages discovered by Sonatype were the preparations for the real attack on UA-parser.js. I assume that the threat actor had somehow managed to gain access to the owner’s account of the original UA-parser.js and started preparing his attack by testing with these three packages.
This more impactful attack on the NPM package “UA-parser-js” was initially reported in this Github Issue.
From the changes between the original package to the malicious package, we can describe the likely attack course.
- The infected package.json file calls for ‘preinstall.js’ script before the installation begins.
- The ‘preinstall.js’ file is introduced by the attacker and wasn’t part of the package before the infection; the same applies for ‘preinstall.bat’ and ‘preinstall.sh’.
- ‘preinstall.js’ main function is to identify the OS and accordingly launch the dropper script. It seems like the attacker decided to spare MacOS users for some reason.
- The dropper scripts both download the crypto miner (xmrig variant) from the same URL and trigger it on the victim’s machine, but there are a few differences:
- Linux version:
- Won’t execute the malicious functionality if the victim’s IP is from Russia, Belarus, Ukraine, or Kazakhstan.
- Windows version:
- Downloads another payload, ‘sdd.dll’, and ensures its persistence by running it using regsvr32.exe.
- This .dll file is a password and credentials stealer (possibly DanaBot) - VT report
- Linux version:
Aside from the new additional payload, the wallet address, and the server’s IP address, the code from the “UA-parser-js” attack is practically identical to the one reported by Sonatype.
Conclusion
Developers who have used the following versions of the NPM package: “ua-parser-js” must consider themselves infected (Github advisory):
- 0.7.29
- 0.8.0
- 1.0.0
The crypto-miner infection can be removed from the machine. The machine’s passwords and credentials must also be considered compromised, and therefore, need to be changed.
What we can learn from these types of attacks is that they are not going away anytime soon. Attackers will always continue to maximize their reach and profit; therefore, researchers must investigate these attacks and their TTP’s and devise ways to thwart this type of activity.
To help combat the growing problem of similar attacks, Checkmarx acquired Dustico, a software as a service (SaaS) solution that detects malicious attacks and backdoors in open source software supply chains. Checkmarx will combine its Application Security Testing (AST) capabilities with Dustico’s behavioral analysis technology to give customers a unified view into the risk, reputation, and behavior of open source packages, resulting in a more comprehensive approach to preventing supply chain attacks. Dustico’s dynamic execution engine can protect organizations from this type of threat since it would not have allowed the malicious code to run on the developer’s machine.
