CVE-2017-11136 in StashCat
Summary
by MITRE
An issue was discovered in heinekingmedia StashCat through 1.7.5 for Android, through 0.0.80w for Web, and through 0.0.86 for Desktop. It uses RSA to exchange a secret for symmetric encryption of messages. However, the private RSA key is not only stored on the client but transmitted to the backend, too. Moreover, the key to decrypt the private key is composed of the first 32 bytes of the SHA-512 hash of the user password. But this hash is stored on the backend, too. Therefore, everyone with access to the backend database can read the transmitted secret for symmetric encryption, hence can read the communication.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2019
The vulnerability described in CVE-2017-11136 represents a critical flaw in the cryptographic implementation of heinekingmedia StashCat across its mobile, web, and desktop platforms. This issue stems from a fundamental misunderstanding of cryptographic security principles where the system fails to properly isolate sensitive cryptographic materials. The vulnerability manifests through a combination of poor key management practices and the exposure of critical cryptographic components to unauthorized parties. The system's design violates core security tenets by storing both the private RSA key and the password-derived decryption key on the backend server, creating a single point of failure that undermines the entire encryption scheme.
The technical implementation of this vulnerability involves a flawed cryptographic protocol where the private RSA key, which should remain confidential and reside solely on the client device, is transmitted to and stored on the backend server. This exposure is compounded by the fact that the decryption key for the private RSA key is derived from the first 32 bytes of the SHA-512 hash of the user's password, which is also stored on the backend database. This creates a scenario where any attacker with access to the backend can easily reconstruct the complete cryptographic key material needed to decrypt all encrypted communications. The vulnerability directly maps to CWE-310, which addresses cryptographic weaknesses, specifically focusing on the improper handling of cryptographic keys and the storage of sensitive information in insecure locations. The flaw also aligns with ATT&CK technique T1552.004, which covers "Unsecured Credentials" and represents a classic case of credential exposure through insecure storage mechanisms.
The operational impact of this vulnerability is severe and far-reaching, as it effectively nullifies the encryption protection that users expect from the application. Any individual with access to the backend database can immediately decrypt all communications that were supposedly protected by the RSA-based encryption scheme. This includes sensitive messages, personal data, and potentially confidential business information. The vulnerability affects all versions of the application across platforms, indicating a systemic flaw in the security architecture rather than a localized bug. The exposure of the password-derived key through SHA-512 hashing means that even if attackers do not have direct access to user passwords, they can easily compute the decryption keys through brute force or dictionary attacks against the stored hashes. This makes the vulnerability particularly dangerous as it can be exploited by both internal and external threat actors with database access privileges, creating a significant risk for organizations that rely on the application for secure communications.
The mitigation strategies for this vulnerability require immediate and comprehensive architectural changes to the cryptographic implementation. Organizations should implement proper key separation where private keys never leave the client device and are never transmitted to or stored on backend servers. The use of password-derived keys should incorporate proper key derivation functions with salted hashes and appropriate computational costs to prevent brute force attacks. Implementing a proper key management system that separates the storage of authentication credentials from encryption keys is essential. The solution should also include the adoption of secure key exchange protocols such as Diffie-Hellman or Elliptic Curve Cryptography for establishing secure communication channels without relying on password-derived keys for critical encryption operations. Additionally, the system should implement proper access controls and monitoring to detect unauthorized database access attempts and ensure that cryptographic materials are properly isolated from user authentication data to prevent the type of cascading security failures that this vulnerability represents.