Over the years, security experts have helped raise awareness of threats targeting software release, deployment, and management processes. Today almost everyone knows that they need to protect their publicly exposed services and applications against the potential attacks from the outside. Wide range of tools have been developed to provide protection mechanisms against such threats.
With more sophisticated security solutions being deployed, threat actors have shifted focus on spots where the defense measures are the weakest or absent. Latest trends show that software supply chain attacks have become a popular tactic for threat actors of all sophistication levels. They are now commonly aimed at the providers of low-level software components as means to infiltrate development organizations, or even to subvert the release process.
One of the ways of doing this is by abusing the level of trust that developers have in the third-party code. Growing popularity of software package repositories and their ease of use make them a perfect target. When developers reuse existing libraries to implement the needed functionality faster and easier, they rarely make in-depth security assessments before including them into their project. This omission is a result of the overwhelming nature, and the vast quantity, of potential security issues found in third-party code. Hence in general, packages are quickly installed to validate whether they solve the problem and, if they don’t, move on to the alternative. This is a dangerous practice, and it can lead to incidental installation of malicious software.
As a part of our continuous security research, ReversingLabs periodically scans public package repositories to track the malicious attempts to compromise software developers. This blog discusses the process used to find another NPM package that steals saved Chrome browser passwords.
The aforementioned file was found in several versions of the nodejs_net_server package using static analysis. Metadata collected from these packages shows that the original name of the file was “a.exe”, and that it was located inside the “lib” folder. While threat hunting, files with filename consisting of a single letter and an extension immediately raise a red flag for additional inspection. A detailed look into this particular case revealed that “a.exe” is, in-fact, a ChromePass utility, a tool which can be used to recover passwords stored inside of a Chrome web browser.
Figure 1: Screenshot of ChromePass tool
It isn’t malicious by itself, but it can be when put into the malicious use context. For instance, this package uses it to perform malicious password stealing and credential exfiltration. Even though this off-the-shelf password recovery tool comes with a graphical user interface, malware authors like to use it as it can also be run from the command line.
This might sound very familiar, as one of our previous blog posts disclosed a similar password stealing PE executable found in another NPM package. It seems that true and tested techniques have a tendency to repeat themselves.
Figure 2: nodejs_net_server NPM package summary
NPM repository pages for the nodejs_net_server package show that the latest version of this package, v1.1.2, was published 6 months ago. URL references for the package homepage and repository lead to non-existing locations hosted on GitHub. The author of this package goes by the name chrunlee and seems to be an active developer on GitHub working on 61 repositories. GitHub account also contains a link to a web page hxxps://chrunlee.cn where the author actively publishes blog posts related to developer thematics.
Figure 3: chrunlee’s github profile
NPM version history shows that this package has 12 published versions, totalling in over 1,283 downloads since the package was first published at the end of February 2019. The analysis that follows details the evolution process of this malicious NPM package.
|Version number||Publish date|
Table 1: nodejs_net_server version history
The first version was published just to test the publishing process of an NPM package. Three months later, the developer implemented a remote shell functionality which was polished over several subsequent versions. In April 2020, minor modifications to the shell functionality were made in the versions 1.0.7 and 1.0.8. Finally, in December 2020, the author made an upgrade to version 1.1.0 by adding a script to download the aforementioned password stealing tool hosted on their personal website, with the URL location hxxps://chrunlee.cn/a.exe. In versions 1.1.1 and 1.1.2, this script was modified to run TeamViewer.exe instead, probably because the author didn’t want to have such an obvious connection between the malware and their website.
Fun fact related to versions that contain the password recovery tool is that the package author accidentally published their own, stored login credentials. It appears that the published versions 1.1.1 and 1.1.2 from the NPM repository include the results of testing the ChromePass tool on the author’s personal computer. These login credentials were stored in the “a.txt” file located in the same folder as the password recovery tool named “a.exe”.
This textual file contains 282 login credentials created between March 20th 2020 and December 2nd 2020. There is a possibility that at least a part of these passwords are still valid. While their validity wasn’t verified, just looking at some of the recovered credentials visible in Figure 4. shows that the author didn’t always care about best password policy practices.
Figure 4: some of the passwords malware author recovered from his browser
Another interesting fact is the way the author intended to trick the targets to execute the malicious package. In cases of malware placed in package repositories, attackers usually rely on typosquatting. They disguise their packages by using names similar to some other popular package so that they could easily lure their targets into installing the package. In this case, the author took a different approach and decided to abuse the configuration options of NPM packages.
NPM packages provide a way to install one or more executable files into the PATH by providing a “bin” field inside the package.json configuration file. Upon package installation, NPM will symlink that file to the prefix/bin folder for global installs, or ./node_modules/.bin/ folder for local installs. Any name can be assigned to these executables and, in case when a module with the same name already exists, it would be overwritten and mapped to the script provided by the malware. Even though NPM requires the “--force” flag for this to work in case of global installs, it isn’t necessary for local package installations.
Figure 5: Abusing “bin” field inside package.json for execution hijacking
After the package installation and the successful execution hijacking, persistence is accomplished by installing the lib/test.js script as a Windows service.
Figure 6: Installation of persistent windows service
This service opens a socket for listening to incoming commands on port 7353. Supported commands include reverse host and port configuration, directory content listing, file lookup, file upload, shell command execution and screen and camera recording. Screen and camera recording are accomplished using the embedded ffmpeg executable. Browser password stealing is accomplished through shell command execution of the previously downloaded ChromePass hack-tool.
Figure 7: Creation of the listening socket
As noted earlier, homepage and GitHub repository links of this package lead to non-existing webpages. Looking at the other NPM packages published by the author chrunlee reveals another package with non-existing links. This package is named tempdownloadtempfile, and has only one version published June 17th 2019. It contains only the package.json and file/test.js files. While the file/test.js file implements the same remote shell functionality as the ones found in different versions of nodejs_net_server package, this package does not perform execution hijacking and does not have a persistence mechanism, which makes its purpose a bit unclear.
Software supply chain attacks ramp up
Software supply chain attacks are becoming a powerful strategy for malicious actors. Security community needs to pay more attention to these types of threats. Everyone involved in the software development process needs to understand that malicious actors today are trying to compromise the development process across all of its stages. Developers are being targeted as a critical entry point to their organization and its client base.
One of the most frequent attack vectors targeting developers is exploitation of public package repositories. As these repositories have a large number of hosted packages, they offer a good hiding place for malware to lurk in. Repetitive discovery of malicious packages in these repositories has proven that there is a growing need for security solutions that can provide reliable identification and protection against these types of attacks.
ReversingLabs is continuously developing and improving tools that can be incorporated into the software development process to provide a reliable and efficient detection of software supply chain attacks. Its powerful static analysis engine can generate a software security report which provides an exact and complete insight into the contents of a release package in the form of a Software Bill Of Materials, or SBOM. The report provides information on possible unknown or unexpected software dependencies, and unwanted licencing restrictions found in third-party software. In addition to in-depth malware identification, it also provides an early warning about leaked sensitive information like private SSH keys and certificates. With powerful software behavior diffs, released packages can also be compared to their previous versions to observe and recognize possibly unwanted changes in code functionality. Every detected problem is scored with a grade describing its severity, remediation complexity, and offers a recommendation towards problem resolution.
The ReversingLabs software quality assurance report enables critical security improvement tracking during the software development process. This report is specifically designed for developers looking to take that next step in implementing best practices needed to produce quality and secure software. An example report for the package analyzed within this blog can be found here.
Affected packages and SHA1:
07/02/2021 - Contacted NPM security team about nodejs_net_server and tempdownloadtempfile packages
07/15/2021 - NPM security team was once more notified about malware in nodejs_net_server and tempdownloadtempfile packages, because they still haven’t removed them from NPM repository
07/21/2021 - NPM security team removes nodejs_net_server and tempdownloadtempfile packages