Full Report
On October 30, 2024, a supply chain attack was initiated against the popular JavaScript library lottie-player, injecting malicious code that populates a Web3 wallet connection prompt on legitimate websites using the library, potentially targeting prominent cryptocurrency platf...
Analysis Summary
# Incident Report: Supply Chain Compromise of lottie-player Library
## Executive Summary
On October 30, 2024, a supply chain attack successfully compromised the popular JavaScript library `lottie-player`. Attackers gained unauthorized access to a maintainer's token and injected malicious code into versions 2.0.5, 2.0.6, and 2.0.7, causing affected websites to display fraudulent Web3 wallet connection prompts targeting users, notably impacting cryptocurrency platforms like 1inch. Swift action involved publishing a safe version (2.0.8) and removing malicious versions from major repositories to contain the threat.
## Incident Details
- **Discovery Date:** October 30, 2024 (Reported via GitHub)
- **Incident Date:** October 30, 2024 (Between 8:12 PM and 9:57 PM GMT)
- **Affected Organization:** Third-party developers and users of the `lottie-player` library (including 1inch trading platform)
- **Sector:** Software/Web Development, Cryptocurrency/Web3
- **Geography:** Global (Distribution via CDNs and npm)
## Timeline of Events
### Initial Access
- **Date/Time:** October 30, 2024 (Prior to 8:12 PM GMT)
- **Vector:** Compromised Maintainer Token (Supply Chain Compromise)
- **Details:** Malicious actors gained unauthorized access to a token belonging to one of the library's maintainers (Aidosmf).
### Lateral Movement
- **Details:** No evidence of traditional network lateral movement; access was leveraged directly within the software publishing infrastructure (npm/CDN distribution).
### Data Exfiltration/Impact
- **Date/Time:** Upon user interaction with infected websites (Post-publishing, Oct 30, 2024)
- **Details:** Malicious code prompted users to connect to their Web3 wallets and potentially sign transactions, aiming to compromise cryptocurrency assets.
### Detection & Response
- **Date/Time:** October 30, 2024 onwards
- **Details:** Incident reported by a user on GitHub noticing unexpected Web3 wallet prompts. Affected versions (2.0.5, 2.0.6, 2.0.7) were pulled by maintainers, and a safe version (2.0.8) was published immediately.
## Attack Methodology
- **Initial Access:** Supply Chain Compromise via Unauthorized Token Access.
- **Persistence:** Malicious code persisted in published package versions (2.0.5, 2.0.6, 2.0.7) hosted on CDN/npm.
- **Privilege Escalation:** N/A (Attacker used compromised maintainer credentials/token access to publish malicious updates).
- **Defense Evasion:** The malicious payload was integrated directly into legitimate, widely used versions of the library files.
- **Credential Access:** N/A (The goal was direct access to victim crypto wallets, not system credentials).
- **Discovery:** N/A (Attacker exploited existing trust in the software update mechanism).
- **Lateral Movement:** N/A (Targeted end-user interaction).
- **Collection:** Harvesting wallet connection credentials/session information via crafted prompts.
- **Exfiltration:** Potential exfiltration of victim wallet keys/session tokens (implied by wallet connection requests).
- **Impact:** Direct financial compromise of end-users via fraudulent transaction signing requests.
## Impact Assessment
- **Financial:** Potential high financial loss for end-users whose cryptocurrency wallets were compromised via signature requests.
- **Data Breach:** Compromise of Web3 wallet connection details/signing authorization attempts.
- **Operational:** Disruption to cryptocurrency platforms (e.g., 1inch) whose users encountered the prompt, requiring immediate remedial action.
- **Reputational:** Harm to the trust surrounding the `lottie-player` library and the general security of transitive dependencies in software development.
## Indicators of Compromise
- **Network Indicators (Defanged):**
- Dependency on unpinned versions from CDNs serving `lottie-player` version 2.0.5, 2.0.6, or 2.0.7.
- Malicious sourcing URLs observed during the incident: `hxxps://unpkg.com/@lottiefiles/lottie-player@latest/dist/lottie-player.js` and `hxxps://cdn.jsdelivr.net/npm/@lottiefiles/[email protected]/dist/lottie-player.min.js`.
- **File Indicators:** Malicious logic embedded within the JavaScript code of versions 2.0.5, 2.0.6, and 2.0.7 of `lottie-player`.
- **Behavioral Indicators:** Unexpected Web3 wallet connection prompts appearing on websites utilizing the library where such prompts were not expected or initiated by the site itself.
## Response Actions
- **Containment Measures:** Immediate removal of compromised versions (2.0.5, 2.0.6, 2.0.7) from npm and major CDN providers.
- **Eradication Steps:** Publishing a safe version (2.0.8) to overwrite malicious builds.
- **Recovery Actions:** Encouraging all consuming applications to update immediately to version 2.0.8 or roll back to a known safe version (e.g., 2.0.4).
## Lessons Learned
- **Key Takeaways:** Trust in upstream dependencies, even for widely used front-end components, remains a critical vulnerability vector (Supply Chain Risk). Repository access control (like 2FA on publishing tokens) is paramount for maintainers. Unpinned version dependencies amplify the blast radius instantly.
- **What could have been done better:** If consumers had pinned dependencies to specific, verified versions, the automatic serving of compromised "latest" versions would have been mitigated.
## Recommendations
- **Prevention Measures for Similar Incidents:**
1. **Strict Dependency Pinning:** All consuming applications must rely on explicit, pinned versions of third-party libraries rather than `@latest` tags or implicit version ranges.
2. **Dependency Monitoring:** Implement automated tools to monitor key dependencies for sudden version changes or suspicious activity.
3. **Maintainer Security:** Ensure all maintainer accounts with publishing rights have mandatory Multi-Factor Authentication (MFA) and review token access regularly.