• The popular NPM package @lottiefiles/lottie-player enables developers to seamlessly integrate Lottie animations into websites and applications.
• On October 30, the community reported existence of malicious code within versions 2.0.5, 2.0.6, and 2.0.7 of the npm package.
• The package maintainers replied and confirmed the attackers were able to take over the NPM package using a leaked automation token which was used to automate publications of NPM packages.
• The malicious code displays a UI overlay, asking to connect the crypto wallets by clicking or scanning a QR. By doing so, this prevent usage of the infected website
• This is yet another reminder on how sensitive the software supply chain is

Would MFA Have Prevented This?

Multifactor authentication is designed to challenge humans. There are three authentication factors that can be used and 2FA requires two:

1. something you know (like a password)
2. something you have (like a one-time-use token)
3. something you are (a biometric identity like a fingerprint or a speech pattern)

Going back two years ago - NPM decided to enforce 2FA on all users. Great move on NPM side as we witnessed many account takeover incidents happening.

Sounds Great, Doesn’t Work (?)

While this does secure NPM account takeover attacks from the interactive login page, enforcing 2FA on all accounts comes with a side-effect:

• non-human identities can’t answer 2FA challenges.

So, when you define an NPM automation token — whoever gets your long-auto generated password is able to bypass your 2FA controls to make new version releases.

Back to @lottiefiles/lottie-player , even with 2FA configured, the threat actors somehow got the NPM automation token set in the CI/CD pipeline to automate version releases to publish the malicious versions 2.0.5, 2.0.6, and 2.0.7 of the npm package

The Malicious Code

All it does is displaying a UI overlay to steer the victim’s focus on connecting its crypto wallets to the malicious interface:

Kudus to The Package Maintainers

The compromised package maintainers quickly released an incident response report:

Incident Response for Recently Infected Lottie Web Player versions 2.05, 2.06, 2.07

Comm Date/Time: Oct 31st, 2024 04:00 AM UTC

Incident: On October 30th ~6:20 PM UTC — LottieFiles were notified that our popular open source npm package for the web player @lottiefiles/lottie-player had unauthorized new versions pushed with malicious code. This does not impact our dotlottie player and/or SaaS services. Our incident response plans were activated as a result. We apologize for this inconvenience and are committed to ensuring safety and security of our users, customers, their end-users, developers, and our employees.

Immediate Mitigation Actions

Published a new safe version (2.0.8)

Unpublished the compromised package versions from npm

Removed all access and associated tokens/services accounts of the impacted developer

Impact

Versions 2.0.5, 2.0.6, 2.0.7 were published directly to npmjs.com over the course of an hour using a compromised access token from a developer with the required privileges.

The unauthorized versions contained code that prompted for connecting to user’s crypto wallets.

A large number of users using the library via third-party CDNs without a pinned version were automatically served the compromised version as the latest release. With the publishing of the safe version, those users would have automatically received the fix.

Recommended Steps

If using 2.0.5, 2.0.6 and 2.07 versions please update to the latest version 2.0.8
SHA: sha512-PWfm8AFyrijfnvGc2pdu6avIrnC7UAjvvHqURNk0DS748/ilxRmYXGYkgdU1z/BIl3fbHCZJ89Zqjwg/9cx6NQ==

If you are unable to update the player immediately, it is recommended that you communicate to Lottie-player end-users to NOT accept any attempts to connect their crypto wallets.

Next Steps

LottieFiles continues to work through its incident response plan and has also engaged an external incident response team to help further investigate the compromise.

We have confirmed that our other open source libraries, open source code, Github repositories, and our SaaS were not affected.

If you believe you’re affected, don’t hesitate to reach out to us at priority_support@lottiefiles.com

Conclusion

Freeze your deps tightly. Don’t rush to update to the latest if it’s not a security update and it’s a new release.

Check and make sure you don’t have the malicious versions 2.0.5, 2.0.6, and 2.0.7 of lottie-player npm package.

The incident highlighted limitations of 2FA in automation environments, as automation tokens bypass these controls. This can happen to any major project.

When ‘Everything’ Goes Wrong: NPM Dependency-Hell Campaign — 2024 Edition

Happy New Year! What a way to open 2024! NPM user account gdi2290 aka PatrickJS published a troll campaign to the NPM registry by uploading a package named “everything” that relies on every other public NPM package, resulting in millions of transitive dependencies.

This leads to a Denial of Service (DOS) for those who install “everything,” causing issues such as storage space exhaustion and disruptions in build pipelines.

The creators of the “everything” package have published over 3000 sub-packages. These sub-packages are designed to split the dependencies into chunks and comprehensively depend on all publicly available NPM registry packages.

The creators have also registered the domain https://everything.npm.lol/. On this website, they showcase the ensuing chaos and incorporate a famous meme from The Elder Scrolls V: Skyrim, adding an extra layer of humor or mockery to the situation.

Not the first time this has happened.

A year ago, we encountered an intriguing situation with the package “no-one-left-behind” by Zalastax. This unique package depended on every publicly available npm package, creating an intricate web of dependencies. Despite being removed by the npm security team, a new development emerged on Jan 28th, 2023. Over 33,000 packages under the scope “infinitebrahmanuniverse,” prefixed with “nolb-,” surfaced as sub-packages of “no-one-left-behind.”

The downsides of those trolls

Imagine you did an experiment, published a package to NPM and now you want to remove your NPM package. You can’t do it if other packages are using it. The problem is, since “everything” relies on every package, including yours, your package gets stuck, and there’s some unknown package preventing you from removing it.

An attempt to delete the packages

It doesn’t seem PatrickJS realized the headache his troll would cause to some users. Two days after the prank packages were published, he created an issue and shared that he is unable to delete the packages since the NPM mechanism prevents deletion of published packages once they are being used by other projects and calls for help from NPM support team.

Summary

This act of digital mischief by PatrickJS echoes past incidents, highlighting ongoing challenges in package management and the cascading effects of dependencies within the NPM ecosystem. The situation underlines the comedic yet serious consequences of such pranks in the developer community.

When ‘Everything’ Goes Wrong: NPM Dependency-Hell Campaign — 2024 Edition was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.