To the Secret community:
The purpose of this blog post is to inform you of some recently discovered vulnerabilities that could impact the privacy of certain data on commonly used Secret contracts, and how we are working to resolve them. Before diving into the details, we want to make it clear that these vulnerabilities do not impact the security of tokens on Secret Network, only the privacy. It’s also worth mentioning that these vulnerabilities are not related to the use of trusted execution environments for secure computation, but instead with how memory is accessed by a smart contract. Similar issues could occur with any type of secure computation technique, such as MPC or FHE.
What Happened?
Recently, a whitehat researcher team contacted SCRT Labs to report the ability to compromise the privacy of contracts that utilize the SNIP-20 reference implementation. SNIP-20 is a smart contract template for Secret Tokens, functioning similarly to ERC-20 tokens on Ethereum but with additional privacy and selective access-control built-in. The vast majority of tokens on Secret Network were created using this smart contract template and are thus affected.
These vulnerabilities make it possible for an attacker to obtain information such as wallet token balances, token transfer amounts, and which addresses a wallet has interacted with in the past. These vulnerabilities DO NOT affect the security of tokens, only their privacy. A malicious actor could not make use of these methods to steal tokens from a wallet that they do not own.
The methods used to demonstrate the ability to compromise private data are similar to those described in the Tx Replay/Side-Chain attacks in the Secret Network developer documentation, and also involve observing state access patterns. While the basic principle of these methods were already known, the details had not been fully understood until now, and other applications may unintentionally expose confidential data through the same channels. For more technical information on how this vulnerability works, see this article. We recommend application developers review their contract code to assess whether they could be affected by similar issues.
Internally, a security review uncovered an issue where during storage of key-value pairs, a final layer of encryption was not being applied on keys. This means that while keys can’t be decrypted outside the secure enclave, keys that use predictable values (for example, a user’s address in a SNIP20 contract) can be matched with their encrypted key-value pair in the chain state. From our analysis, the impact of this issue is mostly contained to SNIP20 variants, where the receiver’s privacy regarding historical data can be compromised over time.
How We’re Resolving This
With the most recent network upgrade, we’ve already completed the first steps to resolving these issues and increasing the security posture of the network. Secret Network v1.7 included changes to how keys are stored, as well as a long awaited feature – light-client validation inside a TEE. This means that transactions are now validated to be part of a block before being computed. The result of this is twofold – first, it protects against side-chain attacks. Second, we are now able to validate block time and height, allowing them to be trusted by contracts. This significantly raises the bar on the difficulty of manipulating the secure enclave, and increases the difficulty for a potential attacker to disclose confidential account balances and transfer values. Furthermore, with the goal to mitigate this issue entirely, we are working on an additional security mechanism of providing Merkle proofs to the enclave for every storage read. In simple terms, this means that during contract execution, the enclave would be able to verify for every storage read that the data it reads is the correct one for the respective block it executes.
In order to also solve the anonymity issue, and in particular, the ability to deduce the receiver in a SNIP-20 transaction, we are working on extensions to the SNIP-20 standard that will make secret tokens more secure. To start, we will add a decoy mechanism that will enable SNIP-20 users to obfuscate their activity. While it’s not perfect, we feel that it’s a sufficient short-term solution. For a longer-term solution, we are exploring different alternatives including ORAM schemes, storage bucketing and more. Our ultimate challenge here is to maintain top notch UX and low gas prices while providing the highest level of privacy.
Since upgrading the SNIP-20 standard is unavoidable, users will have to migrate tokens from the old SNIP-20 contracts to the new upgraded ones. The good news is that our existing roadmap already included this action as part of our migration plan from our custom Ethereum and Binance Smart Chain bridges to the more universal Axelar bridge. This migration is expected to begin next month. A token migration interface is currently being developed and will be announced soon. This is one of the ecosystem’s top priorities at the moment. We have also been working on a contract upgrade feature for a while now, and while this is not an easy task, we see it as an important part in handling contract migrations better in the future, SNIP-20s included. After contract migrations are complete, users can transfer their tokens to new wallet addresses in order to regain their anonymity. This is inconvenient, but out of necessary caution, users should assume historical wallet balances and transaction amounts to be potentially compromised.
Unrelated to the above privacy vulnerabilities affecting SNIP-20 contracts, we also wanted to mention a recent disclosure made by Intel regarding the security of SGX. Secret Network is not susceptible to this vulnerability, as we have taken measures to address it during a past upgrade.
Lastly, we understand that documenting and highlighting the unique challenges of Secret Network is an area where we can do better. As a pioneering network with private smart contracts, Secret Network raises intriguing issues that create exciting opportunities and challenges to overcome. To effectively address these issues, we must articulate the challenges that the network presents, including its potential limitations. Going forward, we are committed to making this information more accessible and understandable for application developers. In addition, we are shifting some of the focus of our roadmap to make sure that features that increase the security posture of the network receive more attention.
Onwards and Upwards!
As is the case in any complex system, new issues and improvements may continue to be discovered in the future. This process of continually identifying and resolving vulnerabilities is part of our regular work to keep the Secret community safe and strengthen our privacy technology. We will continue to keep the community informed if and when new potential vulnerabilities are discovered and resolved, whether at the network level, contract level, or otherwise.
All of this is in service of our broader mission: building the best possible privacy platform for web3. As part of our continued effort to improve on the privacy features of Secret Network, Secret 2.0 will integrate new cryptographic techniques into our existing infrastructure, hardening our defenses and making Secret Network more capable than ever before.
If you have any questions about what we’ve covered in this blog post, feel free to contact the SCRT Labs team at [email protected].
If you’re interested in building a dApp on Secret Network, check out our developer resources, learn about our grant funding, and join our developer community on the Secret Discord!
