Full Report
SolChat claimed to be an encrypted chat application and audio calls using WebRTC. So, the author decided to take a look at it. They first took to reviewing the JavaScript code. Since the JS map files were easy to download they could deobfuscate it using sourcemapper. While doing this, they discovered that the encryption/decryption of messages was happening client side with a large coded key! In particular, these were stored within process.env.REACT_APP_API_URL. Since the client side needs this information, it was exposing the secret information when used there. I'm guessing that the developer didn't understand the difference between frontend and backend. So, they took some messages off of Solana and decrypted them on the spot. Talk about a horrible blunder! Even after making this only on the server side, it's still bad that a single entity has all of the keys for decrypting all messages. I love that the author went and verified these claims. People who make bad claims about the security of something need to be exposed in order for the world to be more secure.
Analysis Summary
# Vulnerability: SolChat Client-Side Encryption Key Leak and Centralized Decryption Capability
## CVE Details
- CVE ID: N/A (This appears to be a proprietary application flaw without a formal CVE assignment at the time of the report.)
- CVSS Score: N/A (No standardized score provided, however, the technical impact suggests **Critical** severity due to mass data exposure risk.)
- CWE: CWE-321: Hard-coded Credentials (Specifically relates to hardcoding the encryption key in client-side code) and CWE-311: Missing Encryption (The key management makes the encryption effectively broken).
## Affected Systems
- Products: SolChat application (Web client)
- Versions: Prior to the March 3, 2024 patch/update.
- Configurations: Any configuration where the client-side JavaScript bundle was accessible, particularly by analysts with access to map files.
## Vulnerability Description
The SolChat application stored its monolithic symmetric encryption key directly within the client-side JavaScript code bundle, sourced from the `process.env.REACT_APP_API_URL` variable. Because this key was exposed on the frontend, any user capable of downloading the deobfuscated JavaScript (via available source map files) could retrieve the secret key. This key was used to encrypt and decrypt all messages stored on the Solana blockchain.
A secondary, related design flaw is that the application relied on a single entity (the service operator) holding the master decryption key, irrespective of where the encryption logic was executed (client-side or server-side post-fix). This central control compromises user confidentiality even if the initial key leak is fixed, as the operator can decrypt all past and future messages.
## Exploitation
- Status: **Proof of Concept (PoC) available and demonstrable.** The vulnerability was exploited locally by the researcher to decrypt sample messages.
- Complexity: **Low**. The attacker only needed to download the map file, deobfuscate the client code to find the key, and then parse public transaction data from the Solana blockchain to extract ciphertext.
- Attack Vector: **Network** (To download JS/map files and transaction data).
## Impact
- Confidentiality: **High**. All chat messages sent through the platform prior to the fix were fully readable by anyone possessing the leaked key.
- Integrity: **None** (The vulnerability does not allow modification of the blockchain state or messages).
- Availability: **None** (The service remained fully operational).
## Remediation
### Patches
- SolChat patched the immediate vulnerability on March 3, 2024, by:
1. Removing the hardcoded encryption key from the client-side JavaScript.
2. Moving the encryption/decryption logic to the server-side. (Note: This fixes the *leak* but not the *centralized key management* issue).
### Workarounds
- **Immediate Action:** Users should cease sending confidential information until the platform implements true end-to-end encryption (E2EE).
- **Design Consideration:** The vendor intends to address design concerns regarding key centralization in "version 2" by moving operations on-chain.
## Detection
- **Indicators of Compromise (IoCs):** Logs showing access to `.js.map` files corresponding to bundled application code may indicate reconnaissance efforts.
- **Detection Methods and Tools:** Monitoring application endpoints for bulk retrieval of obfuscated Javascript files and associated map files could indicate hostile activity targeting key extraction. Standard blockchain explorers can be used to identify transactions containing 'SendMessage' instructions.
## References
- [Initial Analysis/Blog Post](https://h0wl.substack.com/) (Defanged: hxxps://h0wl.substack.com/)
- Transaction examples used for PoC confirmation on Solscan (e.g., tx: 43k5nkiBhwM5Ln5CQZbXM8fJAUQ49ii4uryv1cqQBBgCpqjkeVhM3c7eJ9prSt4Gt2c3CSYvTT8wcpMfkNTRsnLP)