Full Report
nthLink VPN claims to be a VPN that doesn't allow the sniffing of internet traffic. They had two security audits: two from Cure53, where both were found to be secure. The author set out to dispute this claim. The audit and source code could be requested but weren't public. Since this was written in Electron, it was trivial to extract though. Although this claims to be a VPN, it's not. Under the hood, it redirects all TCP and UDP sessions into shadowsocks, which is just a proxy. The credential request was as following: Find the domain to retrieve the credentials. This should either be a static S3 bucket or a dynamically calculated one. Make request to get the data. Decrypt the server credentials using the hardcoded key in the app. All cryptographic keys in shadowsocks must be derived from a shared password. If all clients know the Pre Shared Key, they can use this to MitM connections to the same server. This is a major problem, especially considering the whole purpose of the app is to secure the connection. The author includes a demo with nice screenshots as well. Overall, this feels like a architecture design flaw and would require major rework. Good and concise article.
Analysis Summary
# Vulnerability: Shared Cryptographic Key Leading to Man-in-the-Middle Attacks in nthLink (Shadowsocks Implementation)
## CVE Details
- CVE ID: [Not Assigned] (This appears to be a design flaw in the proprietary implementation rather than a specific, tracked CVE number at the time of the report.)
- CVSS Score: N/A (Severity is based on design flaw analysis)
- CWE: CWE-320 (Key Exposure) implied by shared, extractable keys, and CWE-311 (Missing Encryption) if the core issue invalidates the perceived confidentiality.
## Affected Systems
- Products: nthLink VPN (Application claiming to be a VPN service built on Electron).
- Versions: All versions where the configuration retrieval and Shadowsocks implementation details described apply (Android App v5.1.0 cited). The specific vulnerability exists at the architectural level based on the shared secret nature of the Shadowsocks configuration.
- Configurations: Any operational environment using nthLink where the attacker can intercept or retrieve the hardcoded decryption key and the universally shared Shadowsocks symmetric key.
## Vulnerability Description
The nthLink application is not a true VPN but functions as an Electron wrapper redirecting traffic through Shadowsocks. The core security failure lies in the **Symmetric Pre-Shared Key (SPSK)** used for deriving all cryptographic keys within the underlying Shadowsocks instances.
1. **Key Extraction:** The encryption key used to decrypt the server credentials JSON payload is hardcoded within the Electron application binary, allowing trivial extraction (e.g., using standard Electron unpacking tools).
2. **Shared Secret:** Because all Shadowsocks cryptographic keys are derived from this shared password/key, any entity that obtains this key (which is publicly derivable from the hardcoded elements in the client) can impersonate the legitimate nthLink server or act as a Man-in-the-Middle (MitM) to intercept traffic from any user connecting to that same server configuration.
This fundamentally defeats the purpose of the application, as the confidentiality promised by the "VPN" is invalidated by the shared key scheme.
## Exploitation
- Status: **PoC available** (The author demonstrated a successful Man-in-the-Middle attack by setting up a rogue Shadowsocks server using the derived credentials and redirecting victim traffic.)
- Complexity: **Low** (Trivial extraction of keys from Electron code; standard network redirection techniques like `iptables` demonstrated for MitM setup leveraging the shared key.)
- Attack Vector: **Network** (Requires the attacker to control a network point or redirect traffic destined for the legitimate server.)
## Impact
- Confidentiality: **High** (An attacker with the shared key can decrypt and view all traffic routed through the affected Shadowsocks connection, including sensitive information.)
- Integrity: **High** (An attacker controlling the MitM position can modify the decrypted traffic before re-encrypting and forwarding it, or injecting malicious data.)
- Availability: **Low** (The primary impact is on secrecy, not service uptime, although a poorly implemented MitM could cause connection disruption.)
## Remediation
### Patches
- **No vendor patch information provided.** Remediation requires fundamentally redesigning the authentication and key derivation mechanism.
* The vendor must move away from using a universally shared symmetric pre-shared key across all users connecting to the same server infrastructure.
* Key exchange must be secured using robust, distinct per-session or per-user key material, likely involving modern TLS-based key establishment, rather than relying on hardcoded secrets and shared secrets for the entire system.
### Workarounds
- **Stop using nthLink VPN:** Users relying on nthLink for security guarantees should discontinue use immediately until a rigorous, verifiable security overhaul, including key management, is implemented.
- **Use established, audited VPN protocols:** Switch to protocols (like OpenVPN with strong configurations or WireGuard) that utilize established, non-shared key management practices.
## Detection
- **Indicators of Compromise:** Observing traffic patterns that show connections being unexpectedly mirrored or terminated at an unknown intermediary server hosting a Shadowsocks service using the expected client credentials.
- **Detection methods and tools:** Analyzing network traffic flows for unexpected proxy endpoints. For advanced detection, monitoring for connection attempts that match the publicly derivable Shadowsocks URI format (`ss://...`) pointing to non-whitelisted IPs could be an indicator, although this is noisy.
## References
- Vendor advisories: None found (Vendor was not notified or has not responded).
- Relevant links - defanged: hxxps://snawoot.github.io/stripping_nthlink_vpn_encryption/