Skip to main content

Lottie Player npm package compromised for crypto wallet theft

Escrito por:
wordpress-sync/feature-open-source

31 de outubro de 2024

0 minutos de leitura

On October 31st, 2024, another package compromise and cryptocurrency hijack story unfolded for a popular npm package.

The TL;DR for Lottie Player npm package compromise

The popular npm library @lottiefiles/lottie-player was found to contain malicious code that prompts for connecting to users' crypto wallets.

The malicious code was added to npm releases 2.0.5, 2.0.6, and 2.0.7 after an npm registry account token used for publishing npm packages was compromised. These versions have been pulled from npm and 2.0.8 was then released from the safe code in the project’s GitHub code repository with identical content to that of 2.0.4.

Safe and vulnerable version ranges for Lottie Player npm package

Depending on your ability to respond, both an upgrade and a downgrade allow you to remediate the three known malicious versions that were published:

  • Known to be safe: @lottiefiles/lottie-player <= 2.0.4 

  • Known to be vulnerable: @lottiefiles/lottie-player@2.0.5, @lottiefiles/lottie-player@2.0.6, and @lottiefiles/lottie-player@2.0.7

  • Known to be safe: @lottiefiles/lottie-player@2.0.8

How to tell if you’re vulnerable using Snyk

You may have used a dependency automation tool to manage your dependency tree and upgraded to one of the malicious versions pushed to the npm registry. Alternatively, you may have blindly upgraded to the latest versions in CI or development environments and persisted those changes.

You can use Snyk in various ways to tell if you have installed the malicious versions.

Snyk Dependency Reports UI

Navigate to the “Dependencies” menu item for your group or your organization, apply any filters you’re interested in narrowing down the search, and then open the “Dependencies” search box to type in “lottiefiles” for a free-text search.

See below for an example demonstrating that no results are found, and hence these projects that I am searching under are not using this dependency at all:

1_Lottie_Player_npm_package_compromised_for_crypto_wallet_theft

If I change the text to just “lottie” I would find some other dependencies with that text in their name:

2_Lottie_Player_npm_package_compromised_for_crypto_wallet_theft

Once selected, I can confirm which projects they are used, which vulnerabilities apply to them, license issues, and other supply chain security information:

3Lottie_Player_npm_package_compromised_for_crypto_wallet

Snyk CLI

If you’re using the Snyk CLI in your development workflows or CI build processes, then you’ll find out by the Snyk scan resulting in a piece of vulnerable package information, such as:

$ snyk test

Testing /Users/lirantal/projects/repos/your-project-name...

Tested XXX dependencies for known issues, found 1 issue, YYY vulnerable paths.

Issues with no direct upgrade or patch:
  ✗ Embedded Malicious Code [Critical Severity][https://security.snyk.io/vuln/SNYK-JS-LOTTIEFILESLOTTIEPLAYER-8310516] in @lottiefiles/lottie-player@2.0.5
    introduced by [path to the package]
    No upgrade or patch available (Upgrade to versions <2.0.4 || >2.0.8 recommended)

What’s happening with @lottiefiles/lottie-player

In a similar attack vector that impacted the Polyfill library to compromise users via a CDN back in June 2024 and has been traced back to earlier January of that year, this incident follows the same attempt to steal cryptocurrency through a crypto wallet financial theft.

Users reported in the lottie-player code repository that by using the library through CDN from sources such as https://unpkg.com/@lottiefiles/lottie-player@latest/dist/lottie-player.js or https://cdn.jsdelivr.net/npm/@lottiefiles/lottie-player@2.0.5/dist/lottie-player.min.js, they would observe a crypto wallet login screen such as this, from the GitHub issue thread:

3_Lottie_Player_npm_package_compromised_for_crypto_wallet_theft

Many users using the @lottiefiles/lottie-player dependency via third-party CDNs without properly pinning the dependency version were automatically served the compromised version as the latest release. By publishing a new version with known-to-be-safe source code (essentially, reverting the code to the 2.0.4 version), those users are presumed to have automatically received the fix too.

That said, the impact appears to be quite large given the number of dependent projects on the lottie-player component and the number of versions that were already downloaded malicious versions:

  • 73 npm packages are dependent on the package

  • 36,762 downloads were recorded for the 2.0.4 known-to-be-safe version over the last 7 days

  • ~890 downloads were recorded for the 2.0.8 recently published fix over the last 12 hours

How to mitigate CDN-related supply chain security concerns?

To prevent future security incidents such as the lottie-player web component compromise or the polyfill malicious dependency, it is advised to follow some security best practices such as:

  • Adopt a Content Security Policy to prevent unwanted and untrusted sources from injecting scripts, image tags, and other objects into your web application.

  • Always pin your dependencies, whether pulled via on-the-network CDN assets or through a package manager.

  • Follow mitigation recommendations from the official Lottie Player team through their comment here and other official channels

Verifying your applications

If you'd like to test your applications and projects but you're not a Snyk customer, you can sign up for a free trial to perform the above tests. With the trial, you can scan open source dependencies and container images, in the CLI or your SCM to determine if you're using one of the vulnerable versions of lottie-player, and potentially uncover any other security vulnerabilities you may have in your projects.