Differential analysis raises red flags over @lottiefiles/lottie-player
ReversingLabs
ReversingLabs is the trusted name in file and software security. RL - Trust Delivered.
Welcome to the latest edition of Chainmail: Software Supply Chain Security News, which brings you the latest software security headlines from around the world, curated by the team at ReversingLabs .
This week: Differential analysis raises red flags over an infected legitimate package on npm. Also: GitHub projects targeted with malicious commits to frame a security researcher.
This Week’s Top Story
Differential analysis raises red flags over @lottiefiles/lottie-player
It’s not common for malicious campaigns to be disseminated on open-source repositories using legitimate packages, but it does happen. In October, RL researchers and other firms observed such an incident: Three versions (2.0.5, 2.0.6 and 2.0.7) of a popular, legitimate package, @lottiefiles/lottie-player, were infected and used to spread malicious code that was designed to steal crypto wallet assets from victims. Since then, LottieFiles maintainers worked with npm to remove malicious versions from the repository, and they have since published new, clean versions of @lottiefiles/lottie-player. Since the incident first became public, RL researchers took a closer look to understand how this exception became a reality.?
The package @lottiefiles/lottie-player, first published five years ago, is a legitimate npm package with an estimated 84,000 weekly downloads and 50 different versions since being released. The new, malicious versions 2.0.5, 2.0.6 and 2.0.7 were published eight months after the last, legitimate version release. The new versions of the package were quickly found to be malicious when developers started noticing the package behaving differently than prior releases. Sites that installed the malicious versions were displaying a pop-up to connect to Web3 wallets. Any user that connected their wallets would be connected to the attacker’s architecture and risked having their crypto assets drained, and their wallets emptied.?
RL researchers then asked an important question: What did the malicious actors do to alter versions of @lottiefiles/lottie-player? Using RL Spectra Assure, researchers performed differential analysis that allows them to compare two versions of the same package, which yielded how attackers altered the @lottiefiles/lottie-player package. Differences spotted include a big difference in size between two versions of the package — with no corresponding features to account for the extra code. RL researchers also found that there was an omission of normal behaviors that can usually be found in the file lottie-player.js.?
However, some behaviors that aren’t usually part of lottie-player.js files appeared, such as “Contains URLs related to Bitcoin exchange services.” These behaviors could have pointed to the new malicious functionality of @lottiefiles/lottie-player package.
“The lottie-player hack shows how malicious actors can hijack accounts of maintainers with privileged access and can publish a series of malicious versions of that package to the community of users and developers, polluting their product and causing supply chain attacks in different projects.” –Lucija Valenti?, RL Software Threat Researcher
(RL Blog)
This Week’s Headlines
GitHub projects targeted with malicious commits to frame researcher
The GitHub repository of the AI/ML startup EXO Labs was targeted with malicious commits and pull requests in an attempt to inject a backdoor into the project. This incident comes at a time when several other GitHub projects have been targeted by attackers in the same manner. On Tuesday, EXO Labs co-founder Alex Cheema shared the news of the backdoor attempt on X, stating that an "innocent looking" code change was submitted to the company’s GitHub repository. There still isn’t a clear answer about who carried out the attack, since the archived page for the attributed GitHub username and the domain evildojo(.)com point to security researcher Mike Bell, who has since denied on X that he carried this out and believes he was impersonated. (BleepingComputer)
2024 CWE Top 25 Most Dangerous Software Weaknesses
Common Weakness Enumeration (CWE), a DHS and CISA sponsored program, released its top 25 most dangerous software weaknesses. CWE lists the most severe and prevalent weaknesses behind more than 30,000 CVEs in the organization’s 2024 data set. The goal of the list is to help reduce vulnerabilities by pinpointing root causes, so that software teams can make necessary changes in the SDLC. The list also provides insight into how exploitable certain vulnerabilities are, allowing organizations to better prioritize risk management efforts. (CISA)
GitHub Secure Open Source Fund: Project maintainers, apply now!
GitHub is calling on maintainers of open source projects to apply for the new Secure Open Source Fund, which provides funding and knowledge to improve the security and sustainability of their software projects. The fund is backed by several companies, including American Express, Chainguard, Microsoft and others, along with the help of venture funds and nonprofits. Applicants who are chosen for the program will receive $10,000 per project, in addition to security education training, dedicated time with the GitHub Security Lab team, free access to training tools, and more. Applications are due by January 7, 2025. (HelpNet Security)
Supply chain threats highlight security gaps in LLMs and AI
LLMs and AI have expanded concern over supply chain security for organizations, particularly as interest in incorporating LLMs into product portfolios grows across a range of sectors. Steve Wilson , chief product officer at Exabeam and head of the OWASP Top 10 for LLM, argues that for cybersecurity leaders whose organizations are looking to adapt to the broad availability of AI applications, they must stand firm against risks introduced by suppliers. And not just for traditional DevSecOps – but now for ML operations (MLOps) and LLM operations (LLMOps) as well. Wilson walks through how threats to ML models can manifest, so that CISOs and security professionals can become more proactive in detecting malicious datasets and responding quickly to potential supply chain attacks. (Tech Radar)
For more insights on software supply chain security, see RL Blog.?
The Best of RL
Blog | Why shift left alone can't manage your software risk
The state of shift left was on the agenda at the Elephant in AppSec Conference. One clear takeaway: Modern threats demand an all-in approach. [Read It Here]
Webinar | AI in the Software Supply Chain: Balancing Innovation and Security in the AI Age
December 5 at 1 pm ET
GenAI, LLMs, and ML models provide a competitive edge. Gartner has predicted that by 2025, 70% of enterprises will have operationalized AI architectures. However, with this adoption comes novel threat vectors. In this live conversation, Thales’s Vis Chirravuri and RL's Joe Coletta will outline considerations that organizations must take when integrating AI into the software they build and buy. [Register Here]?
On-Demand | The 5 Misconceptions of Software Supply Chain Security
While many organizations are evolving their strategies to combat software supply chain attacks, several misconceptions about the threat may leave them vulnerable. This on-demand webinar exposes and clarifies five of the most common misunderstandings about software supply chain security, and provides actionable insights to strengthen your defenses. [Watch It Here]?
For more great conversations to watch, see RL’s on-demand webinar library.?
Great dad | Inspired Risk Management and Security Profesional | Cybersecurity | Leveraging Data Science & Analytics My posts and comments are my personal views and perspectives but not those of my employer
3 天前ReversingLabs It’s clear that managing open-source risks and supply chain attacks are increasingly challenging. The maintainers of the libraries are struggling and we are almost dependent on some developers who noticed strange changes in behaviors or are curious to do some security due diligence on these packages. This is definitely not enough and better ways to protect the open-source software ecosystem must be implemented