Coinminer and npm: What you see is not always what you get

Russia's war on Ukraine has resulted in increased malicious activity in cyberspace. Even before the Russian aggression started, malicious actors connected to the Russian state were quite active on the supply chain attack field, with the biggest incident probably being the SolarWinds compromise. Security analysts presume that more of these supply chain compromises exist — they just haven’t been detected or disclosed (yet).

Still, the growing number of software supply chain incidents is forcing the security community to improve security procedures and standards, in order to enforce verifiable security and integrity of software products. The SLSA framework is an example of a security framework designed to provide an industry standard to confront potential risks related to the software supply chain. The SLSA framework divides security threats into three main groups: source threats, build threats, and dependency threats, based on where the potential threat is introduced.

To detect and mitigate security risks, every piece of software should go through some form of software auditing to detect the presence of previously described threat types. However, many software development organizations aren’t yet aware of some of these threat vectors. They focus only on source code-related threats, letting the rest pass undetected. For example, source code analysis (SCA) helps you detect threats very early in the development process, lowering the costs of fixing the issue. But it shouldn’t be the only tool in your security tool belt. SCA can't assess the integrity of the precompiled dependencies or the integrity of your final deliverables. However, such elements have to be verified if you want to have confidence that the product you ship hasn’t been tampered with and doesn’t contain unwanted functionalities.

I know what you're thinking: "Sure. But how likely are we to be the target of a supply chain attack?" The answer is: more likely than you want to believe. Here's how a simple crypto mining functionality can unknowingly be included into your software if you rely only on the source code review.

Public Package Repositories: A Growing Risk

When looking at supply chain security, public software package repositories are becoming a pain point in the whole ecosystem. Malicious actors like to target package repositories for many reasons. The first is their growing popularity. Developers like to use public packages because they provide an easy way to implement new functionality. Developers need only install the package and upgrade the entire dependency tree. The second reason public packages are a target of attack is the lack of security practices governing them. As it stands, there is no standardized security protocol for including public packages from such repositories into private and proprietary software products. Finally, there is the fact that security analysis of packed software components is significantly harder than typical code reviews. This results in a foggy security view of the overall application. Rather than wade into that fog, however, developers often maintain an uncritical and unjustified trust that third-party components they use are secure. Or, they are willing to trade security for expedience - a faster way to implement needed functionality. Needless to say: this security compromise often comes at the cost of unexpected security compromises.

One of our previous blog posts described the problems developers can encounter when they wish to analyze native binary executables without access to the source code. In this instance, an npm package was discovered with its source code available in a GitHub repository, but that code differed from the contents of the npm package. According to the already mentioned SLSA framework, this would fall into the “using a bad dependency” threat category.

Contents of the npm repository were processed with our secure.software platform to extract behavior indicators from packages, which could reveal unexpected behaviors. A package named maintainancewebsite immediately looked suspicious, and spelling mistakes were not the only reason.

Figure 1: Description of the maintainancewebsite npm package

The npm package description suggests this is a “Generic temporary website replacement for pages currently in maintenance mode”. A developer would expect exactly and only that from such a package. However, the extracted behavior indicators suggest this package is capable of a bit more than it claims.

Figure 2: Behavior indicators extracted from the maintainancewebsite npm package

Mind the Crypto Mining

One of the observed behaviors is the presence of crypto mining-related domains. There is no legitimate reason for such a simple, temporary website to contain crypto mining domains. Looking at the extracted files shows that the HTML page downloads a crypto mining script from the coinhive.com domain. After a visitor lands on a webpage with the embedded script, the browser executes this script and starts using the visitor’s computer power to mine crypto currencies for the owner of this npm package.

Figure 3: Extracted crypto mining script

But looking at the current state of the referenced GitHub repository doesn’t show any signs of such crypto mining activity. Only by looking at the commit history can you conclude that on September 17th 2017, the maintainer of this package published the code responsible for crypto mining, and only after user complaints had he removed the same from the codebase on July 19th, 2019. However, it still remained in the npm package repository ever since.

Figure 4: Commit responsible for adding the crypto mining script

Figure 5: Commit responsible for deleting the crypto mining script

This isn’t the only package with embedded coinhive crypto mining scripts. Another example are eye.js and display.js packages, which also had the same crypto mining script. Again, they were removed from the GitHub codebase only after user complaints. Unlike the author of the maintainancewebsite package, this developer published newer versions of the npm package with the coin mining script removed.

Figure 6: Description of the commits related to crypto mining in display.js package

The obvious goal of these developers was to earn some extra money with small effort, and they were not ashamed to admit that. Deciding how they want to monetize their codebase is their prerogative, as long as they are transparent in how they are doing so.

Software Quality Assurance: A Focus on Application Behaviors

Shipping a dependency containing a crypto mining script with your software isn’t the worst thing that can happen, especially since the coinhive service has been shut down in the meantime. However, dependency based attacks like this can also be used to smuggle more serious malware into your software. That's why new security practices need to be adopted. Third-party dependencies and in-house software deliverables should be analyzed to ensure their quality and security.

ReversingLabs's secure.software platform helps improve the previously mentioned software aspects. It can detect the presence of potential malware and known software vulnerabilities inside your software package and its dependencies. The service generates a custom report with analysis results, software quality descriptions, and lots of valuable information. The base of the report is the Software Bill of Materials (SBOM), which contains information about all the components found inside the analyzed software package together with their dependencies. This SBOM can be exported to standard formats like CycloneDX.

Figure 7: SBOM part of an example report

Besides the SBOM, the report also contains information about known vulnerabilities affecting the discovered components. During software analysis, ReversingLabs advanced threat detection technologies are used to detect potential malware which, if present, also gets reported. The Software Quality Assurance platform is also capable of detecting sensitive information leaks and various other software quality issues, like absence of vulnerability mitigations or issues related to digital signatures.

Figure 8: Issues part of an example report

What sets this product apart from other, similar solutions is the analysis of application behaviors. The generated report contains a list of human-readable behavior indicators extracted from the software components. This gives analysts an insight into individual capabilities of the components, and also the package as a whole.

Figure 9: Behavior indicators from an example report

In addition to the comprehensive list of behavior indicators, our Software Quality Assurance platform can extract differences in the behavior of two versions of the same software package. This way, analysts can pinpoint behavior changes to specific components inside the package; check if those behavior changes are expected; and see if they correspond to feature changes introduced in the latest software version. This enables early detection of anomalies in software behavior before the product is released.

Figure 10: Behavior indicator diff from eye.js package report

In the case of maintainancewebsite and eye.js npm packages, the introduction of crypto mining capabilities in version 0.0.2 is clearly visible from behavior indicator differences, and can also be detected by looking at the extracted strings related to networking.

ReversingLabs technologies are capable of extracting a wide range of behavior indicators, enabling security analysts to detect various types of behavior - from networking capabilities to file system manipulations - for a wide range of platforms. The list of supported behavior indicators is continuously extended in order to improve detection capabilities.

Secure Software platform also gives analysts an option to write custom software quality or threat hunting policies based on these indicators, empowering them to use their specific knowledge and experience to enrich platform capabilities.

The Moral? Beware Dangerous Repos!

This blog tried to raise awareness about software supply chain risks related to the dependencies software relies on. Supply chain compromise can happen at several points, and a very common one is including bad dependencies from package repositories. Package repositories are becoming more popular every day, and at the same time, the packed code can be quite hard to analyze. This blog shows that you can’t rely on the contents of a package being identical to the code from its source code repository. One way to tackle these problems is to focus on the behavior of the packed dependencies, and the ReversingLabs Secure Software platform can significantly help you with that effort. It supports hundreds of file formats and can detect a wide range of software quality and security-related issues. The results of software package analysis are exported as a report that you can use to manage the risks related to detected issues across your organization. The earlier you detect a bad dependency, the lower the costs for removing that threat. Nevertheless, to make sure your software product contains only what you truly want, the final deliverables must also be checked and verified.

IOC list

https://www.npmjs.com/package/maintainancewebsite - removed in meantime

https://github.com/thaibault/maintenancewebsite

Version SHA1 hashes:

1.0.1 - e0691324cdae3b5d2b29e88f8cd70995aecb4a26

1.0.2 - ff779aaadd58a00dc359a787b309889b8135e936

1.0.3 - 91d5a0edae003b445cf18fa5e8d0c5de5a97e2b8

1.0.4 - 851bb8dc98be4b8fac429eb856fb0796a6654fb6

https://www.npmjs.com/package/eye.js

https://github.com/arguiot/EyeJS

https://www.npmjs.com/package/display.js

https://github.com/arguiot/DisplayJS