Argent bug bounty awarded to OpenZeppelin (vulnerability fixed)

Summary

• On Friday, 12th June, OpenZeppelin, a leading auditor, disclosed a vulnerability in the latest version of our contracts that could have allowed an attacker to initiate recoveries on legacy wallets with no guardians.
• 61 wallets could have been impacted if the vulnerability had been exploited and the owners did not cancel the recovery attempts in the 36-hour window.
• Nearly all active wallets have guardians and were therefore unaffected.
• The 61 affected wallets were only those that joined us in our Beta, did not complete onboarding by adding a Guardian, yet added assets and upgraded to the latest version of Argent.
• On Friday, 19th June, we replaced the vulnerable code and released an update of the app to protect the remaining 7 ETH (~$1,600) that could have been impacted.
• The result: nobody was impacted, no funds were lost, and all wallets are secure. We thank OpenZeppelin for their help in making the Ethereum ecosystem safer.

What did OpenZeppelin find?

Argent's security model is based on guardians, which can be other Argent users, hardware wallets, MetaMask, or Argent Guard (an automated solution). guardians allow you to recover your wallet without a seed phrase. Having at least one Guardian is mandatory for new wallets, but when we first launched we gave people the choice while making it clear that a wallet without a Guardian cannot be recovered.

In a typical recovery, the wallet owner contacts their guardians and asks them to sign a proof that they are the legitimate owner of the wallet together with the address of their new owner key. These proofs are collected and sent to the wallet by calling the executeRecovery method. If a majority of guardians have provided their proof the recovery is initiated and can be completed after 36 hours.

If a recovery attempt is initiated, the wallet owner is notified by SMS, email and push notification. They then have 36 hours to cancel the recovery by calling the cancelRecovery method if they have access to their phone. (To do this they just open the app and tap 'Cancel').

In version 1.6.0 of our contracts deployed on 7th May we simplified the requirements needed to trigger a recovery. In this update the number of guardians needed to trigger the recovery is computed by the formula ceil(N/2) where N is the number of guardians. There is no problem with this formula for the large majority of users that have at least one Guardian.

However, for a minority of legacy users from our Beta who never setup their first guardians, OpenZeppelin discovered that the updated logic meant that a malicious recovery could be triggered on their wallet.

Assessing the issue

The potential impact of the vulnerability was mitigated by the fact that only 61 active wallets could have been affected, and wallet owners can cancel a recovery attempt by tapping a button in the app. We explain both points in more detail below.

Number of wallets potentially impacted:

61 wallets could have been affected. This is because guardians are the cornerstone of our security model and adding one is a crucial step in onboarding, and has been mandatory for new Argent wallets. The breakdown of wallets affected at the time of the vulnerability being disclosed is as follows:

• 61 wallets had the vulnerable version, no guardians, but had assets. They were at risk if they didn't cancel the recovery.
• 268 other wallets had the vulnerable version and no guardians, but they had no assets in Argent.
• 5,513 wallets had no guardians, no assets, but never had the vulnerable version. While they could have upgraded to that version, and a few have since the disclosure, the vast majority of them downloaded Argent in the Beta, never completed onboarding and never used it.

It should go without saying that we're not satisfied if any of our users could be negatively impacted. Here's how we assessed the significance.

Potential impact:

Argent's security model is designed so wallet owners can cancel a malicious recovery attempt. How? If someone maliciously triggers a recovery attempt a transaction is mined. Our dedicated monitoring service would immediately detect that a recovery is started on an Argent wallet and automatically send a security alert by email, SMS and push notification to the user. The user has 36 hours to cancel it. This layered security model protects users but, unfortunately, if the user does not react in this window, they may lose their assets.

Having assessed the issue, our security team acted rapidly.

How did we react?

1. We updated our smart contracts To fix the issue we simply added a check (a require in the smart-contract language) for 0 guardians in the vulnerable method of our contracts. This means that it is no longer possible to call the executeRecovery method on wallets with 0 guardians. The updated contract was deployed on June 17th (https://etherscan.io/address/0xdc350d09f71c48c5D22fBE2741e4d6A03970E192).
2. Simultaneously, we asked affected users to add a Guardian or move assets out We asked the 61 users to add their first Guardian or to move their assets out of Argent. Following this, there were 35 wallets remaining that had over $1 each. Their assets totaled 7 ETH. For the 35, we shared that our security team would initiate a precautionary security measure by a certain time if they didn't add guardians or move assets out.
3. Initiated precautionary security measure on the last affected wallets For our security measure on the 35 wallets, we decided to exploit the vulnerability ourselves to trigger a recovery, in order to prevent a malicious actor from doing so. Owners were given advance notice and can cancel it during the 36 hours window, which some have done. For those owners that don't cancel, after the security window, we will update the wallet to the fixed version and transfer ownership back to the owner. This involves only $1,000 worth of assets. It's important to note that Argent is a non-custodial wallet and cannot access users' assets. Our action on this occasion was only possible due to the exploit and the owner not canceling it at any time during the 36 hours. We could not have done this under normal circumstances. A wallet with a Guardian is always in full control.

Learnings and next steps

We're grateful to OpenZeppelin for their diligent work. Even though no funds were lost we apologize for causing any concern. This event highlights the benefits of an open-source security model and having an ecosystem of talented auditors. We continue to welcome further submissions for our bug bounties. The bounties go up to $50,000 (in DAI) and more information can be found here. You can also examine our smart contracts and read our previous independent audits here.

As a next step, we'll ensure any older wallets without guardians add one so they can be recovered if they change phone. We'll update the mobile app so it constantly reminds people they should add one.

We will also start a new collaboration with a second well-respected auditing company on the principle that the more eyes looking at something the better.

Last, if you have any questions, please email us at support@argent.xyz.

FAQs

How many wallets could have been affected?

• 61 wallets could have been affected.
• 0 wallets were actually impacted.
• 0 funds were lost.

Were my assets at risk?

• If you had a guardian: No, you could never have been affected.
• If you had no guardians but hadn't updated in May: No.
• If you were one of the 61 with assets and no Guardian who upgraded to the affected version: You could have blocked any recovery attempts. You would have received an email and SMS saying recovery started and you would have just opened the app and press 'Cancel'.

How long were assets at risk for?

The 61 wallets could have been impacted since the update of 7th May, but they still could have canceled any recovery attempts.

Was the vulnerability exploited?

No.

Are wallets without guardians safe now?

Yes - in terms of the vulnerability being fixed. But it's important to note that a wallet cannot be recovered without a Guardian so you should add one anyway.

What's the best configuration of guardians for my wallet?

It's up to you. With just one Guardian you get all the protection of our security model: recovery, locking, approving large transfers. The extremely security conscious may prefer combinations of hardware wallets and MetaMask guardians.

Can Argent take control of my assets?

No. We're a non-custodial wallet. The fix we used for this vulnerability was an exploit that only could have applied to a small number of legacy wallets with no guardians that did not cancel it after getting advance notice. Even before the fix, neither we nor anyone else could have performed the same action on a wallet with a Guardian or without the vulnerable code.

Where can I find your audits and contracts?

Both can be found at our Github: https://github.com/argentlabs

How did the vulnerability come about?

In version 1.6.0 of our contracts deployed on 7th May we simplified the requirements needed to trigger a recovery. In this update, the number of guardians needed to trigger the recovery is computed by the formula ceil(N/2) where N is the number of guardians. There is no problem with this formula for the large majority of users that have at least one Guardian. However, we failed to cover and test the edge case of 0 guardians on legacy wallets.

Are my assets covered by insurance?

No. We have though been talking to both decentralized and centralized providers and we hope to have an update later this year.

Shouldn't I just use a hardware wallet?

Aside from being a black box, a hardware wallet is only as safe as the security of your seed phrase. There are countless examples of people misplacing their seed and losing everything.

You can anyway use your hardware wallet alongside your Argent wallet, including as a Guardian. If you're particularly security conscious you can set a low daily transfer limit in Argent and then use your hardware wallet Guardian(s) to approve every transfer.

The issue validated why our open source security model enhances security. And the security feature of being able to cancel a recovery was an important protection.