Argent Recovery Without Guardians

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Argent

Argent allowed users to set up their wallet to have "guardians" who could assist in recovery.

By default, there were no guardians set up. If a user didn't set up guardians, then anyone could take their funds.

The issue wasn't exploited because there was a 36 hour cooldown and the problem was quickly identified.

This is a global/international case not involving a specific country.

About Argent

"Argent replicates the experience of using a crypto wallet as a CC card with the concept of Guardians. Guardians are trusted devices with limited permissions to a user’s wallet, helping recover access to a wallet if the original owner loses access."

"The guardian feature lets Argent users give selected accounts permission to execute actions on the wallet, like locking it or approving a wallet recovery." "Argent users can add “guardians” to their wallets. These are trusted accounts (externally-owned or contracts) that are given permission to execute specific actions on the wallet. Today, all Argent wallets created in the official mobile application include a default guardian (controlled by Argent), added during creation of the wallet, using Argent’s latest WalletFactory contract (deployed on March 30th 2020). However, all wallets created before March 30th 2020 were initially created without a guardian, since they were created using Argent’s old WalletFactory contract, which did not allow adding a guardian during creation."

"Furthermore, the contracts impose no restrictions on the number of guardians a wallet may have, allowing wallets without guardians." "Before March 30, 2020, users could create wallets without guardians by default." "Users may decide to revoke the default guardian added by Argent, add a user-controlled guardian (such as a hardware wallet), or add a trusted-party’s Argent wallet as a guardian."

"White-hat hackers found a severe vulnerability in the DeFi-focused mobile wallet Argent in OpenZeppelin on Jun. 18." "OpenZeppelin security researcher Alice Henshaw discovered a vulnerability within Argent that would have allowed user funds to be drained from wallets that did not have Argent’s “guardian” feature."

"A high-severity vulnerability in the Argent wallet would have allowed attackers to take over wallets with no guardians. User action would have been needed to prevent the takeover attack in less than 36 hours, which then would have opened an alternative Denial of Service (DoS) attack vector with potential to indefinitely freeze their funds." "The uncovered vulnerability would have enabled hackers to freeze funds in wallets without Guardians. By the time the vulnerability was discovered, over 300 wallets with more than 160 ETH were at risk."

"The guardianCount function of the GuardianStorage contract, in charge of keeping track of how many guardians wallets have, returns zero for wallets with no guardians. As a consequence, the executeRecovery function can be called without signatures for a wallet with zero guardians – and therefore be triggered by any attacker wishing to take control of the wallet and steal its funds."

"The only available mitigation for the described attack is to cancel the malicious recovery and add a guardian before the attacker can launch the attack again. While the mitigation would be effective, only technically skilled users, proficient in Ethereum and the wallet’s internals, would be able to execute the necessary actions to do it in less than 36 hours, while all their funds are at risk."

"Wallets had to meet 2 criteria to be at immediate risk of attack. They must have had 0 guardians, and have upgraded from the old RecoveryManager module to the new one which was deployed on May 7th. At the time of reporting the vulnerability, there were 329 wallets that met such criteria, 74 of which had positive ETH or token holdings. Only 13 of the 329 wallets had added a guardian after 3 days of our initial report."

"Considering the great number of deployed wallets with zero guardians, our preferred fix was to allow wallets with zero guardian, updating the logic in the getRequiredSignatures function of the RecoveryManager contract so that the case for wallet recovery execution ensured that if a wallet had no guardians, the function did not return 0."

"Argent’s team arrived at the same conclusions, and reported they would be implementing our suggested fix. We advised Argent that the fix should be reviewed by Argent’s trusted security auditors. In the meantime, Argent reported that they were already contacting affected users encouraging them to add at least one guardian to their wallets as soon as possible. Finally, Argent deployed the fixed version of the RecoveryManager contract to mainnet, which can be found at address 0xdc350d09f71c48c5d22fbe2741e4d6a03970e192."

"Fortunately, none of them suffered losses as the team implemented fixes in time." "No Argent funds were affected and a patch has been issued, according to the firm. Henshaw received $25,000 in dai as compensation."

"The Argent team has taken quick action to fix this issue so that no user funds were impacted," said Demian Brener, CEO of OpenZeppelin.

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Argent Recovery Without Guardians

Date	Event	Description
June 18th, 2020	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

No funds were lost.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

General Prevention Policies

There were no user funds lost in this case.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.