Web3 Wallets Have Serious Privacy and Security Flaws
The dangers of wallet browser extensions, and how to fix them.
When I started implementing the StarShell Wallet browser extension, I noticed a handful of unexposed privacy concerns and a security risk affecting (as far as I can tell) all current wallet extensions.
This article briefly describes those flaws and motivates the need for better privacy and stricter security in wallet extensions.
StarShell is an upcoming Web3 wallet that will deploy as a browser extension and is introducing novel privacy and security features that address such issues.
—by Blake Regalia, Creator of StarShell
Browser extensions such as MetaMask, Phantom, and Keplr have filled a very important role in the Web3 ecosystem. These extensions are what make rich decentralized web apps possible. They provide a mediated connection to your accounts on the blockchain. Everything from DeFi platforms to NFT markets rely on the so-called Provider APIs that these wallets enable in your browser.
As decentralized web apps (dApps) and the Web3 wallets that support them become more popular, they both become bigger targets for advertisers, aggregators, agencies and hackers — not only for the cryptocurrencies they handle but also for the sensitive information they are supposed to protect.
Surprisingly, all of these browser extension wallets are currently neglecting several major privacy concerns, and seem to be exposed to a certain attack vector that has not been widely discussed or acknowledged.
Privacy Concern #1: Indiscriminate Transparency
Wallet extensions make Provider APIs available by injecting a JavaScript variable into the global scope of every webpage you visit. These variables serve as entry points for dApps to connect with your wallet, but to every other site, these variables essentially act as a giant banner exclaiming, “Hello world! This user has the following wallet extensions installed: […]”.
Aside from enhancing browser fingerprinting, this leaky practice also informs every random website you visit which cryptocurrencies you use. Here is a list of at least some of the variables exposed by major network providers:
- window.ethereum
- window.solana
- window.cardano
- window.keplr
- window.klaytn
However, it doesn’t have to be like this. Your wallet does not need to go around advertising its presence to every website you visit by default. In fact, if you are using one of these extensions now, you should consider taking advantage of improved browser privacy by limiting which sites the extension has access to read and change data on.
Privacy Concern #2: Forced Doxxing
As a Web3 user, you may be familiar with these sorts of prompts:
But did you know that every time you approve a connection, you are actually trusting the website with potentially compromising information about your identity? In addition to tracking cookies, browser fingerprinting, and your geo-locatable IP address, you are also sharing your wallet address, which is the last line of defense protecting the anonymity of your entire transaction history on chain. This extra dimension of information is like a treasure trove for organizations that are capable of leveraging it for their benefit, and let’s just say that their motivations are typically not aligned with your best interest.
It doesn’t have to be like this. Remember how MAC address tracking was used to non-consensually track people via their mobile devices as they walked by wireless access points? Eventually, vendors started introducing MAC address anonymization to combat what had become a rampant violation of user privacy. We now need that in Web3.
An Underestimated Attack Vector
Something that I have yet to see acknowledged is a potential attack vector from malicious web extensions co-installed in the browser.
The problem is that communication between websites and wallet extensions can easily be spoofed or intercepted by a malicious extension. This could lead to a situation where the user is tricked into approving actions generated by the attacker. For example, the attacker could act as a MITM by reading and modifying transaction data sent from the website to the wallet. All the while, any prompts to the user would appear as though they were produced by the trusted website, perhaps in response to user input.
Unfortunately, it would appear that this attack vector is not seen as a threat by today’s wallet vendors because there do not seem to be any counter-measures being used. Perhaps the developers are placing their trust in extension stores’ anti-malware services, or they believe users will do their due diligence, or that it would complicate the API, or maybe they simply haven’t even realized it. None of these excuse relaxed security.
History has shown that niche, obscure, malicious extensions have the potential to go undetected in stores for a while before they are discovered. Just take a look at the arms race currently taking place between browser vendors and extensions. There have been dozens of cases of malware and spyware extensions discovered after reaching millions of downloads, particularly in the cryptocurrency realm. The bottom line is that wallet extensions should not take a secure browser environment for granted.
There are actually methods to protect against such MITM attacks from co-installed extensions — all it takes is a bit of clever engineering.
Enter StarShell
Privacy by default is at the core of StarShell’s ethos. Users should not have take extra steps to protect their identity. Privacy settings should be enabled by default for everyone, not something they have to opt-in to take advantage of.
The rest of this article describes how StarShell will address each of the aforementioned privacy and security issues. While I attempt to keep the explanations high-level, please be aware that some sections require more technical language.
Addressing Privacy Concern #1
Rather than advertising its presence to every website by default, StarShell will employ a Covert Discovery process. This requires websites to first make a request in order to see if the wallet is installed, giving users the ability to browse undetected, i.e., without exposing the extension’s presence.
See the prerelease documentation for a detailed explanation of this process.
Addressing Privacy Concern #2
Web dApps typically use your wallet address to generate transaction data, embedding the address into a smart contract call, or using the address as a key to store session data associated with the account. However, similar to the MAC address tracking debacle, this address is exploitable beyond its function.
To combat this type of exploitation, StarShell will offer an address randomization service when exporting accounts’ public keys to web dApps. This service, known as Shadow Accounts, ensures the integrity of produced transactions by replacing the shadow address with the real address before transactions are submitted. With Shadow Accounts, the shadow addresses are derived from the user’s mnemonic, ensuring that in the event a shadow address is used by the site outside the wallet’s control (for example, in the event a site records addresses to later be used for an airdrop), the user can still claim the shadow account by deriving its private key.
Addressing the MITM (Malicious Extension) Attack Vector
This problem took quite a bit of contemplation. How can a website’s JavaScript application and the wallet extension establish a private and trusted communication channel? I explored everything from stack trace checking to native function verification to cryptographic key exchange. The underlying challenge is that user scripts and so-called inpage content scripts have no guarantee that any window property hasn’t been redefined by an attacker. This means that none of the built-in functions and Web APIs can be trusted from the “MAIN” world.
A malicious actor could theoretically redefine any tools at the page’s disposal, Math.random, crypto.subtle, Object.defineProperty, Function.prototype, Array.prototype, and so on. In fact, the only operations that can be reliably used in the MAIN world of the browser’s JavaScript environment (assuming the presence of a malicious extension) are ones that cannot be redefined: operators.
It turns out this is a complex problem with a somewhat-yet-also-not-so-simple solution. The answer lies with non-configurable JavaScript properties, reference comparison, stack signing, and out-of-band authentication. Given its technical nature, I will present a detailed explanation of this process in the next revision of the prerelease documentation. Make sure to join our Discord server if you would like to be notified of new material.
That’s all for now! If you care about privacy and the future of Web3, please consider following us on Twitter, or joining our Discord server.
Learn more about StarShell at our website: https://starshell.net/
