Malicious package previously removed are still accessible through jsdelivr and results in phishing attack

Highlights:

  1. CloudGuard Spectral detected a malicious package on NPM that applied a phishing attack to gain its user’s credentials

  2. To do so, the package relied on a file from a malicious package, already detected and removed from NPM, which was still available through a popular NPM CDN service – ‘jsdelivr’

  3. Once detected, we’ve alerted NPM and jsdelivr of the malicious package and the malicious flow

NPM and jsdelivr

NPM, short for Node Package Manager, is a widely used package manager for the JavaScript programming language, the default package manager for Node.js. It makes installing, managing, and sharing code packages easy. The NPM registry is a centralized repository of over a million open-source JavaScript packages. Developers can publish their packages to the NPM registry, making them available to others. This feature fosters code sharing and collaboration within the JavaScript community. NPM has various security features to protect developers from installing malicious or vulnerable packages. It includes automated vulnerability scanning, advisories, and the ability to audit installed packages for known vulnerabilities.

jsdelivr is a free, open-source content delivery network (CDN). It provides a fast and reliable way to host and distribute files, making it easier for developers to include external libraries and resources in their web projects. jsdelivr operates as a global CDN with numerous edge servers distributed worldwide. When developers have a file hosted on jsdelivr in their web page, the file is fetched from the server closest to the user’s location, reducing latency and improving performance. jsdelivr supports versioning of hosted files, allowing developers to reference specific versions of libraries. This ensures that projects continue to work reliably even if the library undergoes updates or changes over time. It also provides a fallback mechanism in case a specific version is no longer available.

One of the key benefits of jsdelivr is the direct file links: Instead of using NPM to install the package and reference it locally, you can directly link to the file hosted on jsdelivr’s CDN. But as we will see today, even legit services such as the jsdelivr CDN can be abused for malicious purposes. Meet reactenz.

reactenz

The entry point for this research was the package reactenz which our AI models have detected as malicious. An empty description page and zero dependent packages indicated that this package should be found and installed based on its naming (for malicious ones, probably by using name squatting techniques).

The reactenz package page on NPM

A simple GitHub search revealed that the package tried to mimic the popular react-enzyme package, commonly referenced on GitHub code snippets as ‘ReactEnzyme’.

Results from s GitHub search for code snippets, including the term ‘reactenz’

The package included an obfuscated index.js, which following de-obfuscation, turned out to be a client-side helper package with a simple and yet suspicious intent; once loaded, it downloads a .txt file from an NPM CDN service (jsdelivr), decodes it as HTML and adds it to the existing window in use.

The de-obfuscated index.js

The referenced .txt file was encoded, and following ‘HTML decoding’ and ‘beautifying’ it turned out to be a classic phishing HTML code; fooling users into resetting their Microsoft passwords and then stealing their updated credentials once they’re doing so.

The referenced .txt file

The reset password section from the beautified .txt HTML code

So far, this story seems usual; threat actors are stealing users’ credentials through embedded phishing attacks. The interesting part begins when we zoom into where the malicious .txt file was brought from; the package ‘standforusz’, which files were being served through the CDN service jsdelivr.com.

A quick search revealed that this package was marked as malicious on NPM a month ago, but still its files can be accessed through the CDN service. They were enabling attackers to keep reusing their malicious code for new campaigns even after removing their malicious package from NPM.

The package standforusz page on NPM

This finding was disturbing since two main issues –

  1. While NPM spends much effort to make sure malicious packages are not accessible once detected (publishing a new ‘0.0.1-security’ version which overrides the namespace on NPM and its mirrors, making previous versions un-accessible), we can see the malicious code was still accessible, even long after its detection, through the CDN service.
  2. Given that many of the existing security tools monitor actions like resources being downloaded from the web as a potential maliciousness indicator, threat actors can serve their malicious content through the CDN service, which will most likely enable them to easily go under the hood (given that many legit packages use jsdelivr to fetch legit NPM packages content). This makes these types of malicious packages invisible to security tools.

To make the story even worse, our analysis revealed another example case where malicious resources were accessible through jsdelivr long after they were removed from NPM – the package markedjs; was identified as malicious more than a year ago, but we could still access its malicious parts using the jsdelivr CDN service.

The markedjs package page on NPM

The malicious part of the package, accessible on the CDN more than a year after it was removed from NPM

Disclosure

We disclosed the potential breach and the malicious package to NPM, and soon after, the package was removed. We also reported to jsdelivr the existence of the malicious files on their service.

An increasing risk

It’s important to emphasize that the CDN hack was more disturbing than the malicious package, enabling threat actors to re-use their malicious code, share best practices, and evade common security monitory tools used by 3rd party components. It again highlights the open-source components risk; no one guarantees that the open sources we use are benign, and it’s our responsibility to verify them. Users must be aware that even if the platform seems to be working hard to prevent such attacks (like on thinNPM case), findings continue to indicate that risk is constantly out there. In this case, it was due to helper service (CDN), but in general, there are no bullet proof open-source services. Supply chain attacks are becoming more frequent, therefore it’s important to make sure you’re kept safe, to double check every software ingredient you use, especially the ones which weren’t created by yourself. As a community we need to make it easier to do the right things from a security standpoint in order to generate a secure development process. As part of this effort, we are constantly scanning PyPI and NPM after malicious packages to prevent such supply chain attack risks—making sure you are the first to know of new malicious actors out there.

You may also like