# Past audits, vulnerabilities and solutions ## Audits ### Security Audit Report for Leather Wallet for Web In Q1 2021, Leather (formerly Hiro Wallet) partnered with [Least Authority](https://leastauthority.com/), a leading security consultancy with experience in the crypto space, to audit what was then known as [Hiro's Stacks Wallet for Web](https://www.hiro.so/wallet/install-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](https://github.com/hirosystems/wallet/blob/main/public/docs/least-authority-security-audit-report.pdf) Given the sensitive nature of cryptocurrency wallets, we considered a thorough code audit a prerequisite to publishing the Stacks Wallet on the [Chrome](https://chrome.google.com/webstore/detail/stacks-wallet/ldinpeekobnhjjdofggfgjlcehhmanlj) and [Firefox](https://addons.mozilla.org/en-US/firefox/addon/hiro-wallet/) 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](https://forum.stacks.org/t/upgrade-stacks-wallet-for-web-alpha-now-to-patch-security-vulnerability/11789), 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](https://en.wikipedia.org/wiki/PBKDF2), a CPU-bound key derivation function that is natively available to the browser as part of the [WebCrypto API spec](https://www.w3.org/TR/WebCryptoAPI/#pbkdf2). 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](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2), a newer key derivation library, [Argon2](https://www.argon2.com/), has properties that makes it even more resistant to brute force attacks. We implemented this library in our key derivation logic. [*Learn more about Argon2* ](https://github.com/P-H-C/phc-winner-argon2/blob/master/argon2-specs.pdf)*-->* #### 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](https://semver.org/), 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* ](https://github.com/blockstack/stacks-wallet-web/blob/main/.github/actions/check-version-lock/check-version-lock.js)*-->* #### 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*](https://github.com/blockstack/stacks-wallet-web/issues?q=is%3Aclosed+label%3Aaudit) *-->* ## 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*](https://slowmist.medium.com/demonic-vulnerability-analysis-of-metamasks-wallet-browser-extension-8de529a70caf)*,* [*2*](https://www.halborn.com/disclosures/demonic-vulnerability)*.* [*A fix went live on August 10th with version 6.3.1 of the wallet extension*](https://github.com/hirosystems/wallet/commit/108fdf865e00b545f29f8fca15e7a7869a8da097) *-->* #### 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: 1. The requesting app’s domain 2. 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. [*See the pull request here →*](https://github.com/hirosystems/stacks-wallet-web/pull/2545) 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](http://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. [*You can view the fix here*](https://github.com/hirosystems/wallet/pull/2917) *-->* #### 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*](https://github.com/hirosystems/desktop-wallet/commit/bb71f4f051002b92f5f4509f573d8d59a3a868a0) *-->* #### Timeline Reported: April 9th 2021\ Resolved: May 5th 2021 **Attributions**\ Hackerone contributor