Past audits, vulnerabilities and solutions
Has Leather been audited? Have there been any vulnerabilities with Leather, and what solutions have been built to handle those vulnerabilities?
Audits
Security Audit Report for Leather Wallet for Web
In Q1 2021, Leather (formerly Hiro Wallet) partnered with Least Authority, a leading security consultancy with experience in the crypto space, to audit what was then known as Hiro's Stacks Wallet for Web (now Leather). This was a browser extension for users to securely manage their STX holdings and connect to Stacks apps using their digital assets and identity. Download and read the full report here
Given the sensitive nature of cryptocurrency wallets, we considered a thorough code audit a prerequisite to publishing the Stacks Wallet on the Chrome and Firefox stores.
These are the results of the audit. We'll detail some of the key findings and the changes made to remedy them.
Initial Audit Findings
The results of the review indicated a handful of security improvements that needed to be made. Mostly notably, one abuse vector was found whereby the extension could be embedded into any website. This behavior needed to be prohibited to prevent sophisticated clickjacking attacks.
The Leather team swiftly patched this by enabling the frame-ancestors content security policy directive. A new version was published and the findings were disclosed in a forum post, requesting that users upgrade to the latest version of the wallet.
The wallet, however, had only been released for developer previews when the vulnerability was discovered. Therefore, we don’t believe that the vulnerability was ever exploited.
Other items from the initial report we’d like to highlight are:
Key derivation
Our initial implementation used PBKDF2, a CPU-bound key derivation function that is natively available to the browser as part of the WebCrypto API spec.
Key derivation is an important mechanism needed to secure encrypted keys against brute force attacks. Rather than using the password directly, it is used to derive an encryption key. This process is, by design, computationally expensive (slow).
While PBKDF2 is recommended by OWASP, a newer key derivation library, Argon2, has properties that makes it even more resistant to brute force attacks. We implemented this library in our key derivation logic.
Pinning dependencies
By default, NPM package versions are described with a caret, such as ^3.11.8. This tells NPMs to pull the latest patch version, according to semver, when installing dependencies. It was possible that a bug may have been released in one version. For this reason, Least Authority recommended that NPM packages be pinned to specific versions without the caret. This is done by using the --exact flag when installing the packing. To enforce this, a CI task was added to validate the project’s package.json for exact versions.
Check out the Github Action -->
Final report
On April 29th 2021, after addressing the major concerns described in the initial findings and obtaining a concluding sign off from the Least Authority team, a final report was delivered. We then felt confident in making the Stacks Wallet live to the public on Firefox and Chrome stores for our big release
Here are other issues we’ve solved related to the initial report -->
Vulnerabilities and solutions
2023 August - cached Secret Key
On August 8th, we received the following report: As the “import wallet through secret key” feature uses “textarea” tag to store the private key/mnemonics, it is possible for browsers to cache the key in the local storage (which is known as the “demonic vulnerability”). It could be dangerous when attackers get access to the users’ computer. Some references: 1, 2.
A fix went live on August 10th with version 6.3.1 of the wallet extension -->
Timeline
Reported: August 8th 22.11h Resolved: August 10th 13.04h
2022 July - appPrivateKey vulnerability
On July 7th, a vulnerability in the wallet web extension was reported that affected the wallet's authentication feature in versions prior to v3.11.2.
It was discovered that insufficient validation was taking place on the configuration passed to authentication mechanism. This would allow an attacker to craft a malicious authentication request and, if approved, obtain the appPrivateKey of any domain passed.
However, there have been no known cases of this vulnerability being exploited.
Impact
The appPrivateKey is passed to the app in order to encrypt data stored on Gaia, a Stacks storage solution. If an attacker could convince a user to perform an authentication, they would be able to access the appPrivateKey of any domain, putting user data at risk.
No funds were at risk because of this vulnerability.
Cause
The appPrivateKey is generated by the @stacks/wallet-sdk library. It is derived as a hash of:
The requesting app’s domain
A value derived from the user’s private key
The wallet passed the origin of the redirect_uri to the library rather than to the origin of the requesting domain. As this is set by the user, it could match any domain. This resulting key could then be returned to the app.
Patch
The wallet now validates that the redirect_uri value matches the origin of the requesting domain. Additionally, only the requesting origin’s domain is passed to the @stacks/wallet-sdk library.
Web extensions are automatically updated by the browser. Browser extension users do not need to take any direct action to get the latest version.
Timeline
Reported: July 7th 00.32h Resolved: July 7th 14.23h
Attributions
Credit to Hank Stoever (Mechanism.so) for the vulnerability report.
2022 December - Inadequate locking
With this vulnerability, if a user had two tabs or windows with the wallet app open, their wallet account would remain unlocked and accessible even if one tab or window was closed. The user's key was not compromised in any novel way. It would, however, remain unencrypted in the open window until the user closed that particular window. The user was just as safe / vulnerable as they'd usually be while signed / interacting with the wallet. The risk was that they could walk away from their computer and assume that they had locked their wallet entirely. Subsequently, if another party got physical access to their computer, they could interact with the unlocked wallet in the open window. This possible threat was resolved by locking and closing all windows when the wallet is locked in any window.
Timeline
Reported: December 4th Resolved: December 5th (version 3.27.0) for Chrome Resolved: January 25th 2022 for Firefox
2021 April - Plain text password in memory after checking STX address
This vulnerability would arise when the wallet executable (desktop wallet) was launched and the STX address was checked. The password and address would both be in memory as seen in a memory dump. You can view the fix here -->
Timeline
Reported: April 9th 2021 Resolved: May 5th 2021
Attributions Hackerone contributor
Last updated