Part 2: The ERC-6492 – Exploiting Counterfactual Signature Verification

In Part 1, we explored the benefits and functionality of ERC-6492, a standard that enables signature verification for undeployed smart contract accounts. While ERC-6492 is a powerful tool for improving user experience and reducing gas costs, it also introduces potential security risks if not implemented carefully. In this part, we will dive into a critical vulnerability in ERC-6492 implementations, how it can be exploited, and the steps developers can take to mitigate these risks.

1. Exploiting Arbitrary Calls in ERC-6492

• Part 1 of ERC 6492

• Cantina Report : Coin base SpendPermission Audit

• If you do not want to download above report, read it from : Bug Report - Solodit

• ⭐️ Very Detailed Thread on X by Cantina

1.1 Overview of the Vulnerability

The vulnerability arises from the interaction between ERC-6492, the SpendPermissionManager, and the Coinbase Smart Wallet. Specifically, the issue lies in how arbitrary calls are allowed during the ERC-6492 signature validation process, combined with the ability to manipulate the ownerIndex in the signature.

Key Components of the Vulnerability

1. ERC-6492 Signature Wrapping:

   • ERC-6492 introduces a magic wrapper (0x6492) to indicate that the signature is for a counterfactual contract.

   • If the magic wrapper is present, the contract attempts to deploy the counterfactual contract or prepare it for signature validation by making an arbitrary call to the contract.

2. Arbitrary Calls:

   • During the ERC-6492 validation process, if the signature fails initially, the contract makes an arbitrary call to the signer address to prepare it for validation.

   • This arbitrary call can be exploited to execute malicious transactions, such as draining funds or modifying the wallet's state.

3. OwnerIndex Manipulation:

   • The Coinbase Smart Wallet expects signatures to be wrapped with the ownerIndex of the signer.

   • Since the ownerIndex is not part of the signed message, an attacker can modify it to point to a different owner or the nextOwnerIndex.

---

2. How the Attack Works

2.1 Step-by-Step Exploitation

The attack involves the following steps:

Step 1: Obtain a Valid Signature

• The attacker obtains a valid signature from the wallet owner for a SpendPermission (e.g., granting permission to spend funds).

• This signature is wrapped with the ownerIndex of the signer.

Step 2: Unwrap and Modify the Signature

• The attacker unwraps the signature to separate the signature data from the ownerIndex.

• The attacker modifies the ownerIndex to point to the nextOwnerIndex (an invalid index for the current owner).

• The modified signature is rewrapped with the new ownerIndex.

Step 3: Trigger ERC-6492 Validation

• The attacker submits the modified signature to the SpendPermissionManager.

• Since the ownerIndex is invalid, the initial signature validation fails, triggering the ERC-6492 execution path.

Step 4: Execute Arbitrary Call

• The ERC-6492 validation process makes an arbitrary call to the SmartWallet to prepare it for signature validation.

• The attacker crafts the prepareData to include a malicious transaction:

  1. Drain Funds: Transfer all funds (native tokens and ERC-20 tokens) to the attacker's address.

  2. Remove Owner: Remove the original owner from the wallet's owner list.

  3. Add Owner: Add the original owner back to the wallet's owner list with a new ownerIndex.

Step 5: Pass Second Signature Check

• After the arbitrary call, the ownerIndex is reset to the value used by the attacker.

• The second signature check passes because the ownerIndex now matches the modified value.

• The transaction is executed, and the attacker drains the wallet's funds.

---

3. Why the Attack Works

3.1 Exploiting Arbitrary Calls

The ability to make arbitrary calls during ERC-6492 validation is the root cause of the vulnerability. By crafting malicious prepareData, the attacker can execute transactions that modify the wallet's state and drain funds.

3.2 Manipulating ownerIndex

The ownerIndex is not securely bound to the signature, allowing the attacker to modify it without invalidating the signature. This enables the attacker to bypass security checks and reset the wallet's state.

3.3 Lack of Replay Protection

The vulnerability is exacerbated by the lack of replay protection, allowing the attacker to reuse signatures across different contexts.

---

Conclusion

The vulnerability in the ERC-6492 implementation highlights the risks associated with allowing arbitrary calls during signature validation. By exploiting this issue, an attacker can drain funds from a SmartWallet and modify its state. To prevent such attacks, it is crucial to implement additional checks, secure signature wrapping, and limit the use of arbitrary calls. These measures will ensure the safe and secure use of ERC-6492 in smart contract wallets and permission management systems.

---