Full Report
There has been a healthy reaction to our initial post on our research into the RSA SecureID Software Token. A number of readers had questions about certain aspects of the research, and I thought I’d clear up a number of concerns that people have. The research pointed out two findings; the first of which is in fact a design vulnerability in RSA software’s “Token Binding” mechanism. The second finding is another design issue that affects not only RSA software token but also any other software, which generates pseudo-random numbers from a “secret seed” running on traditional computing devices such as laptops, tablets or mobile phones. The correct way of performing this has been approached with hardware tokens, which are often tamper-resistant.
Analysis Summary
# Vulnerability: Design Flaws in RSA SecureID Software Token and General Software Token Cloning
## CVE Details
- **CVE ID:** No specific CVEs are provided in the summary for these two distinct findings.
- **CVSS Score:** Not specified.
- **CWE:**
* Finding 1 (Token Binding Bypass): Likely related to CWE-287 (Improper Authentication) or CWE-613 (Sensitive Data Exposure).
* Finding 2 (Secret Seed Extraction/Cloning): Related to CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) or weaknesses stemming from insecure storage/PRNG implementation on commercial OS (e.g., CWE-312: Exposure of Sensitive Information to an Unauthorized Actor due to weak storage).
## Affected Systems
- **Products:**
1. RSA SecureID Software Token (Specifically the "Token Binding" mechanism).
2. All other software tokens that generate pseudo-random numbers based on a "secret seed" running on traditional computing devices (laptops, tablets, mobile phones).
- **Versions:** Not specified, as the issues are described as **design vulnerabilities**.
- **Configurations:** Affected when tokens are deployed on standard operating systems (laptops, desktops, mobile devices) without hardware-based tamper resistance.
## Vulnerability Description
The research highlights two primary design vulnerabilities related to RSA SecureID Software Tokens and software tokens in general:
1. **Token Binding Bypass:** An attacker who captures the victim's token configuration file and initial activation password can import this configuration into their own token instance, bypassing the intended device binding mechanism. This attack is possible remotely without requiring a fully compromised machine, provided the necessary initial credentials/files are obtained.
2. **Secret Seed Extraction/Cloning (General Software Token Flaw):** Software tokens running on traditional computing environments (laptops/mobile) are inherently vulnerable because the underlying OS/storage is not tamper-resistant like hardware tokens. An attacker who has compromised the system can extract the secret seed used for pseudo-random number generation (PRNG). This can be achieved by either replicating DPAPI blobs (a time-consuming demonstration method) or, more practically via malware, by hooking into cryptographic functions like `CryptUnprotectData` to steal the decrypted secrets when the token process executes. This allows for easy cloning of the token on another machine.
## Exploitation
- **Status:** Concept demonstrated/Proof of Concept feasible. The article describes methods an attacker *would* use (API hooking) and historical methods used in testing (DPAPI blob replication).
- **Complexity:**
* Token Binding Bypass: Low/Medium (requires file compromise and knowledge of provisioning steps).
* Seed Extraction/Cloning: Low (if malware is deployed on the host, stealing decrypted secrets via API hooking is relatively straightforward).
- **Attack Vector:**
* Finding 1: Network (if configuration file/password is intercepted or acquired).
* Finding 2: Local/Adjacent (requires prior compromise of the host device).
## Impact
- **Confidentiality:** High (Successful cloning allows unauthorized access to resources protected by the token).
- **Integrity:** Medium/High (Unauthorized actors can authenticate as the legitimate user).
- **Availability:** Low (The primary impact is confidentiality/integrity breach related to token misuse, not system denial).
## Remediation
### Patches
- The article does **not** detail specific patches released by RSA or other vendors, as it focuses on design limitations. The implied solution for the general cloning issue is leveraging hardware security features (TPM, Secure Execution Environments).
### Workarounds
- **Mitigating Token Binding Bypass:** Ensure strong protection and secure delivery mechanisms for the initial configuration file and password to prevent interception.
- **Mitigating Seed Extraction:** Running token software within environments designed for better security abstraction (e.g., secure enclaves/Trusted Execution Environments like Intel TXT or ARM TrustZone) is suggested for future proofing, although the article implies standard OS environments are inherently risky for secrets.
- **Mobile Devices:** Application sandboxing on modern smartphones makes local extraction *more difficult* for malicious applications compared to traditional desktop OSes, but physical access remains a risk.
## Detection
- **Indicators of Compromise:** Successful token cloning and subsequent usage from an anomalous location or device might serve as an indicator, but direct detection of the extraction process relies on host-based security monitoring.
- **Detection Methods and Tools:** Monitoring for suspicious API hooking activities targeting core cryptographic libraries (`CryptUnprotectData`) on hosts running software tokens could potentially flag attempts to extract seeds.
## References
- SensePost | RSA SecureID software token update ([defanged link](http://sensepost.com/blog/7045.html) - referring to the initial post mentioned)
- SensePost Analysis/Research (General attribution)