Comment on page
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?
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
These are the results of the audit. We'll detail some of the key findings and the changes made to remedy them.
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 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).
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.
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
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.
Reported: August 8th 22.11h Resolved: August 10th 13.04h
On July 7th, a vulnerability in the wallet web extension was reported that affected the wallet's authentication feature in versions prior to
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
appPrivateKeyof any domain passed.
However, there have been no known cases of this vulnerability being exploited.
appPrivateKeyis 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
appPrivateKeyof any domain, putting user data at risk.
No funds were at risk because of this vulnerability.
appPrivateKeyis generated by the
@stacks/wallet-sdklibrary. It is derived as a hash of:
- 1.The requesting app’s domain
- 2.A value derived from the user’s private key
The wallet passed the origin of the
redirect_urito 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.
The wallet now validates that the
redirect_urivalue matches the origin of the requesting domain. Additionally, only the requesting origin’s domain is passed to the
Web extensions are automatically updated by the browser. Browser extension users do not need to take any direct action to get the latest version.
Reported: July 7th 00.32h Resolved: July 7th 14.23h
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.
Reported: December 4th Resolved: December 5th (version 3.27.0) for Chrome Resolved: January 25th 2022 for Firefox
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 -->
Reported: April 9th 2021 Resolved: May 5th 2021
Attributions Hackerone contributor