Supply Chain Attack
Learn about the recent supply chain attack on the Solana web3.js npm library, im...
A recent supply chain attack on the [`@solana/web3.js`](https://www.npmjs.com/package/@solana/web3.js)[ library](https://www.npmjs.com/package/@solana/web3.js) has underscored the need for heightened security in software development. This [Threatfeed](https://www.secureblink.com/cyber-security-news) offers a detailed analysis of the incident to help developers, security researchers, and organizations understand the attack and implement preventive measures.
## Background of the Attack
On December 2, 2024, versions `1.95.6` and `1.95.7` of the popular `@solana/web3.js` library was compromised by a supply chain attack. A supply chain attack occurs when an attacker compromises a trusted software component at the source, introducing malicious code that gets distributed to end users.
This library is a crucial JavaScript client that allows interaction with the Solana blockchain, used extensively by decentralized applications (dApps) to interface with the blockchain network. More information can be found on the [official Solana JavaScript client documentation](https://solana.com/docs/clients/javascript).
The incident exposed sensitive private keys to threat actors. In blockchain, private keys are used to authorize transactions and manage cryptocurrency wallets. If compromised, these keys allow attackers to drain funds, creating severe financial risks for developers and organizations.
A supply chain attack occurs when a trusted software component is compromised at the source, leading to the introduction of malicious code into the software. In this case, attackers leveraged compromised developer credentials to publish malicious versions of the library. The compromised versions included malicious code designed to steal private keys, enabling attackers to drain cryptocurrency wallets.
### Example of Supply Chain Attack
For example, in a typical supply chain attack, an attacker might compromise a developer's credentials or use phishing techniques to gain access to the publishing environment of a popular library. Once they have access, they introduce malicious code that gets distributed to end users who trust the library.
This was precisely the scenario that occurred with `@solana/web3.js`, where the malicious versions were able to steal sensitive data from unsuspecting users.
## Affected Versions and Technical Details
### Versions Impacted
- **Affected Versions**: `1.95.6` and `1.95.7`.
- **Safe Version**: Developers are advised to update to version `1.95.8`, that was released to remove the malicious code. You can find more details in the [official GitHub release notes](https://github.com/solana-labs/solana-web3.js/releases/tag/v1.95.8).
- **Vulnerability Detection**: npm swiftly unpublished the compromised versions once the attack was detected. Detailed information on the detection and response can be found in this [Socket.dev blog post](https://socket.dev/blog/supply-chain-attack-solana-web3-js-library).
### Nature of the Malicious Code
- The injected code targeted private keys, stealing them and transmitting them to a **hardcoded wallet address**. The data was disguised using legitimate-looking CloudFlare headers, making it difficult to detect, and it was transmitted without encryption, leaving sensitive information vulnerable to interception.
- The associated **Solana address** (`FnvLGtucz4E1ppJHRTev6Qv4X7g8Pw6WPStHCcbAKbfx`) received the stolen credentials, putting affected wallets at significant risk. Mentioning the specific address helps in tracking the movement of stolen assets and providing transparency for affected users.
### Attack Timeline
- The affected versions were available from **3:20 p.m. UTC to 8:25 p.m. UTC on December 2, 2024**.
- The attack targeted projects that directly handled private keys within this narrow timeframe.
## Impact on Developers and Projects
### Who Was Affected?
- Projects that **directly handle private keys** and updated to one of the compromised versions during the affected window.
- **Non-custodial wallets** were **not affected** as they generally do not expose private keys during transactions, minimizing the risk of compromise. Non-custodial wallets are wallets where users retain full control over their private keys without relying on a third party.
### Scope of the Risk
- **Developers and dApps**: Developers who used these versions in their projects faced the risk of having their private keys compromised, leading to a significant security breach.
- **Financial Risk**: Exposure of private keys puts connected funds and wallets at risk of being drained by attackers.
## Mitigation Steps for Developers
To mitigate the impact of the attack and ensure ongoing security, it is crucial to take immediate action to prevent further risks. The following actions are recommended:
### 1. **Update to Version 1.95.8**
- **Upgrade Immediately**: All Solana developers must update to version `1.95.8` immediately to protect against vulnerabilities. Developers with pinned dependencies to `latest` must also ensure their environments are updated.
### 2. **Rotate Compromised Keys**
- Developers who suspect compromise should **rotate authority keys** immediately, including:
- **Multisignature Keys** (multisigs).
- **Program Authorities** (used for smart contracts).
- **Server Keypairs** (used for backend operations).
- To rotate keys, developers should generate new keypairs and update their configuration files or environments to reflect the new keys. This will prevent attackers from continuing to use compromised credentials.
### 3. **Audit Dependencies**
- **Check for Suspicious Code**: Review the `node_modules` directory and dependency trees to ensure no unauthorized modifications were made.
- Use **Socket's CLI** (`socket scan create .`) or the **Socket GitHub app** to detect compromised dependencies.
### 4. **Revoke Permissions**
- Revoke permissions granted to any compromised authority keys to prevent unauthorized access and minimize potential damage.
## Detailed Analysis of the Malicious Function
### `addToQueue` Function
- The attack involved the addition of a **malicious function** named `addToQueue`, as shown in Where 1.
- **Purpose**: The function exfiltrated private keys by injecting itself into legitimate code paths that accessed private key data.
- **Exfiltration Mechanism**: It used **CloudFlare headers** to disguise the traffic as legitimate, effectively bypassing most security detection systems that might monitor for anomalous behavior.
### Command-and-Control Server
- **Domain**: The C2 server (`sol-rpc[.]xyz`) was registered on **November 22, 2024**, via **NameSilo** and was hosted behind **CloudFlare**.
- The server was used to collect stolen credentials but is currently **offline**, suggesting ongoing mitigation efforts by security teams.
## Root Cause Analysis and Attack Mechanism
***Figure 2: The 'addToQueue' function repeatedly called with secret key data, exfiltrating sensitive information.***
### Publish-Access Compromise
- The root cause of the attack appears to be a **phishing/social engineering** attack that compromised the **publish-access account** for the `@solana/web3.js` library. Common signs of phishing attacks include unexpected emails or messages asking for sensitive information, suspicious links, and requests for credentials that seem urgent or out of context. For further information on these incidents, refer to [this post by Christophe Tafani-Dereeper on Bluesky](https://bsky.app/profile/did\:plc\:zwlpsxw2udovqf4mbfi4ibqf/post/3lcgt6l7s4c2a). Developers should be vigilant about these warning signs to help prevent similar incidents in the future.
- Phishing attacks typically involve tricking the target into revealing sensitive information, such as account credentials, which the attacker then uses to gain unauthorized access, as illustrated in Figure 2. Once the account was compromised, the attacker could publish unauthorized versions, embedding the malicious code.
### Abuse of Open Source Trust
- The attack emphasizes the inherent **vulnerabilities of the open-source ecosystem**, which arise from the trust developers place in shared libraries that may not always be securely maintained. Trust in these libraries can be risky because attackers can exploit them by injecting malicious code, as was the case in this incident.
- Attackers exploited this trust, embedding backdoors in widely used packages, highlighting the need for **additional security checks** and **code audits**.
## Preventive Strategies for Developers
To prevent similar incidents in the future, developers should adopt the following strategies:
### 1. **Implement Secure Key Management**
- **Avoid Hardcoding Keys**: Never hardcode private keys directly into your code. Use secure environment variables or external secret management systems.
- **Use Hardware Security Modules (HSMs)**: Utilize HSMs or secure key storage services to handle sensitive key material, reducing the chances of exposure.
### 2. **Apply Principle of Least Privilege**
- **Limit Access**: Only provide the minimum required access permissions to accounts that interact with publish-access controls. This limits the potential damage if an account is compromised.
### 3. **Conduct Regular Security Audits**
- **Static Code Analysis**: Use static code analysis tools to identify vulnerabilities and malicious changes in code dependencies.
- **Dependency Monitoring Tools**: Tools such as Dependabot or Snyk can automatically notify developers of vulnerabilities in third-party libraries. Additionally, you can read more about similar malicious packages in this [Socket.dev blog post](https://socket.dev/blog/malicious-npm-packages-threaten-crypto-developers).
### 4. **Use Multi-Factor Authentication (MFA)**
- Require **MFA** for all developer accounts that have access to publish or modify packages, adding an extra layer of protection against unauthorized access.
### 5. **Implement Supply Chain Security Tools**
- Utilize specialized tools such as **Sigstore** to verify the provenance of open-source packages. Supply chain security tools help ensure that the code being deployed has not been tampered with.
