By: Kong@慢雾安全团队

前言

本文旨在为审计人员提供以 EIP4337 标准实现的账户抽象钱包的安全审计检查项，并提供部分针对性的审计指南。本文假设审计人员已经对 EIP4337 账户抽象标准和 EIP7562 账户抽象验证范围规则标准较为熟悉，因此不再赘述这两个标准。接下来，我们将简单介绍 EIP4337 架构与钱包交易执行流程。

架构

交易执行

在 EIP4337 设计标准中，首先由 EOA 签署 `UserOperation` 类型的数据，并通过 RPC 提交到一个单独的 Alt Mempools。此内存池独立于以太坊内存池，其汇总了用户提交的 UserOp 数据。Bundler 会从此内存池中提取 UserOp 以帮助用户执行，在执行之前将进行本地模拟，模拟失败的 `UserOp` 将被丢弃。所有的 UserOp 执行都由 Bundler 调用 EntryPoint 合约执行。EntryPoint 经过一系列验证后将调用用户的 AA 钱包，执行用户的 calldata。在此过程中，用户需要向 Bundler 支付交易上链执行的手续费，或者指定一个 Paymaster 进行代付。

执行详情

以下是 Bundler 通过 EntryPoint 调用用户钱包的详细过程，审计人员应熟悉此流程。

(https://www.figma.com/board/dWu1j2He9WaJin5pW6o3Hx/4337-Execution-Details_CN?node-id=0-1&t=Iy1930ilcXQY6m9v-1)

检查项

慢雾安全团队依据上述架构列出以下检查项，建议审计人员在对每个 4337 钱包进行安全审计时都确保其通过下述检查项：

1. 检查是否兼容所有 EVM 兼容链

大部分 AA 钱包可能不止部署在 Ethereum 主网，因为主网在上海升级后新增了 `PUSH0` 字节码，而 Solidity 在 0.8.20 版本及之后编译版本都默认为上海升级后的版本，因此其编译后的字节码可能不适用于所有的 EVM 兼容链。

审计人员在审计时应该检查合约编译使用的 Solidity 版本，或检查编译后的文件是否包含 `PUSH0` 字节码。在进行多链部署时，建议使用小于 0.8.20 版本的编译器，或者指定编译版本为 `paris`。

solc = "0.8.19"evm_version = "paris"

2. 检查接口实现与返回值是否符合 EIP4337 标准规范

EIP4337 标准规定钱包必须实现以下核心接口，其返回值 `validationData` 必须包含三个值：authorizer、validUntil 和 validAfter。

function validateUserOp    (PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)    external returns (uint256 validationData);

同样的，代付合约 Paymaster 也必须实现以下核心接口，其中 `validatePaymasterUserOp` 的返回值 `validationData` 也必须包含三个值：authorizer、validUntil 和 validAfter。

function validatePaymasterUserOp    (PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost)    external returns (bytes memory context, uint256 validationData);
function postOp    (PostOpMode mode, bytes calldata context, uint256 actualGasCost, uint256 actualUserOpFeePerGas)    external;

当签名验证失败时，authorizer 需要返回 `SIG_VALIDATION_FAILED`（即 1 值），验证成功时，authorizer 需要返回 `SIG_VALIDATION_SUCCESS`（即 0 值），而不是 `revert`。如果是其他情况导致的失败交易都必须 revert。

3. 检查钱包调用者是否可信

在 EIP4337 标准中，要求钱包或代付人实现的 validateUserOp、executeUserOp、validatePaymasterUserOp、postOp、数据执行接口等函数都应该只允许可信的 EntryPoint 进行调用，以避免钱包被未授权的使用导致资产丢失等风险。

function entryPoint() public view virtual override returns (IEntryPoint) {   return _entryPoint;}
function execute(address dest, uint256 value, bytes calldata func) external {    _requireFromEntryPointOrOwner();    _call(dest, value, func);}
function executeBatch(address[] calldata dest, uint256[] calldata value, bytes[] calldata func) external {    _requireFromEntryPointOrOwner();    ...}

4. 检查是否实现手续费支付功能

在用户钱包中有充足原生代币情况下，其可以无需在 EntryPoint 中质押且无需指定代付人，即可使用钱包中的代币付款。付款费用由 EntryPoint 在调用 validateUserOp 函数时通过 `missingAccountFunds` 参数传入。因此审计人员需要检查钱包中的 validateUserOp 函数是否实现了向 EntryPoint 合约转账 `missingAccountFunds` 数额的原生代币的逻辑。

function validateUserOp(    PackedUserOperation calldata userOp,    bytes32 userOpHash,    uint256 missingAccountFunds) external virtual override returns (uint256 validationData) {    ...    _payPrefund(missingAccountFunds);}

5. 检查钱包创建方式

当用户钱包尚未创建时，其可以在 UserOp 中指定工厂进行钱包创建。工厂必须使用 `CREATE2` 创建钱包，以避免创建地址受到创建顺序的干扰。一些用户需要在还未完成创建之前就知道钱包地址，并向其转移资金以支付创建费用，因此审计人员在对工厂合约进行审计时，需要确保钱包创建方式使用了 `CREATE2`。

function createAccount(address owner,uint256 salt) public returns (SimpleAccount ret) {    address addr = getAddress(owner, salt);    uint256 codeSize = addr.code.length;    if (codeSize > 0) {        return SimpleAccount(payable(addr));    }    ret = SimpleAccount(payable(new ERC1967Proxy{salt : bytes32(salt)}(            address(accountImplementation),            abi.encodeCall(SimpleAccount.initialize, (owner))        )));}

6. 检查重复创建同一钱包的返回值

EIP 4337 标准要求，对于已经创建的钱包，如果传入相同的数据，应返回同一地址。这是为了让客户端更容易查询地址，而无需知道钱包是否已部署，也为了避免非预期的创建失败或者创建非预期地址的钱包。

function createAccount(address owner,uint256 salt) public returns (SimpleAccount ret) {    address addr = getAddress(owner, salt);    uint256 codeSize = addr.code.length;    if (codeSize > 0) {        return SimpleAccount(payable(addr));    }    ...}

7. 检查钱包创建时是否可被接管

在钱包创建前，用户可能会先向预创建地址转入手续费以供创建时支付费用，并且使得在创建同一地址时也不会交易失败。因此，审计人员需要检查钱包是否可以被抢先创建，如果可以，应该检查被抢先创建后的钱包所有权是否正确，并着重检查是否存在未参与地址计算的初始化参数，这些参数又能否被修改。

错误示例代码（entryPoint 不参与地址计算，可被抢先创建修改为恶意的 entryPoint）：

function deployCounterFactualWallet(address _owner, address _entryPoint, address _handler, uint _index) public returns(address proxy){    bytes32 salt = keccak256(abi.encodePacked(_owner, address(uint160(_index))));    bytes memory deploymentData = abi.encodePacked(type(Proxy).creationCode, uint(uint160(_defaultImpl)));    // solhint-disable-next-line no-inline-assembly    assembly {        proxy := create2(0x0, add(0x20, deploymentData), mload(deploymentData), salt)    }    require(address(proxy) != address(0), "Create2 call failed");    // EOA + Version tracking    emit SmartAccountCreated(proxy,_defaultImpl,_owner, VERSION, _index);    BaseSmartAccount(proxy).init(_owner, _entryPoint, _handler);    isAccountExist[proxy] = true;}

8. 检查签名有效性验证

钱包必须支持 `validateUserOp` 接口以验证 EntryPoint 传入的 UserOp 的有效性，同样的，Paymaster 也必须支持 `validatePaymasterUserOp` 接口以验证代付信息的有效性。因此，审计人员必须在 validateUserOp/validatePaymasterUserOp 中严格检查 UserOp 中签名的有效性以避免钱包被恶意执行，或签名被重放。

function validateUserOp(    PackedUserOperation calldata userOp,    bytes32 userOpHash,    uint256 missingAccountFunds) external virtual override returns (uint256 validationData) {    _requireFromEntryPoint();    validationData = _validateSignature(userOp, userOpHash);    _validateNonce(userOp.nonce);    _payPrefund(missingAccountFunds);}

9. 检查是否正确实施了 ERC1271

账户抽象钱包可能实施 EIP1271 标准以支持验证来自合约的 1271 签名，标准规定了通过 `isValidSignature` 接口以实现具体的验证逻辑。审计人员需要严格检查 ERC1271 标准的实施是否符合规范，且确保签名验证逻辑安全可靠。

function isValidSignature(bytes32 _dataHash, bytes calldata _signature) public view override returns (bytes4) {    // Caller should be a Safe    ISafe safe = ISafe(payable(msg.sender));    bytes memory messageData = encodeMessageDataForSafe(safe, abi.encode(_dataHash));    bytes32 messageHash = keccak256(messageData);    if (_signature.length == 0) {        require(safe.signedMessages(messageHash) != 0, "Hash not approved");    } else {        safe.checkSignatures(messageHash, _signature);    }    return EIP1271_MAGIC_VALUE;}

10. 检查向 EntryPoint 的质押代币是否可被永久锁定

账户抽象钱包为了支付执行费用，可能实现向 EntryPoint 质押 Native 代币的逻辑。同样的，为了提高声誉，代付合约 Paymaster 与钱包工厂合约也可能实现向 EntryPoint 质押原生代币的逻辑。EIP7562 标准要求质押实体的最小质押时间必须是 `MIN_UNSTAKE_DELAY`（1 天），因此通常质押时间是由调用者自行决定或合约硬编码决定。审计人员需要检查是否任何人都可以传入任意锁定时间 `unstakeDelaySec` 进行质押，这可能导致质押代币被永久锁定。

function addStake(uint32 unstakeDelaySec) external payable onlyOwner {    entryPoint.addStake{value: msg.value}(unstakeDelaySec);}

11. 检查钱包是否可以不通过 EntryPoint 执行交易

EIP4337 标准要求 EntryPoint 通过直接调用钱包执行用户 calldata 或者调用 executeUserOp 函数以执行数据，并由钱包验证调用者与签名。因此，审计人员需要检查钱包是否允许在不通过 EntryPoint 的情况下执行调用者的数据。如果可以，审计人员需要检查钱包是否正确实施了权限检查，以避免钱包被执行恶意数据。

function execute(address dest, uint256 value, bytes calldata func) external {    _requireFromEntryPointOrOwner();    _call(dest, value, func);}

12. 检查钱包是否只访问与发送者关联的存储字段

为了避免 Bundler 执行 UserOp，遭受 DoS，然后使得 Bundler 无法收回 gas 费成本，EIP7562 标准规定了只允许钱包访问与其相关联的存储，否则 Bundler 将不会接受此 UserOp。审计人员需要检查钱包中对存储的访问是否符合规定。

13. 检查执行失败后 Paymaster 的处理逻辑是否符合预期

在 EntryPoint 中，当 innerHandleOp 执行后，EntryPoint 将通过 _postExecution 函数进行后续的手续费处理逻辑，并调用 Paymaster 的 postOp 函数对手续费进行处理（例如：多退少补）。而当 innerHandleOp 执行失败时，也会通过 postExecution 进行费用处理，但此时不会触发 Paymaster 的 postOp 函数（即使用户指定了代付）。因此在审计 Paymaster 时，需要特别注意用户恶意使得 innerHandleOp 和 postOp 都执行失败的情况下，Paymaster 能否正确地处理费用，以避免 Paymaster 中的资金被耗尽。

14. 检查模块化钱包的实施是否安全

EIP4337 钱包可能支持用户自定义拓展钱包功能，如：运行社交恢复、合约升级、保险库等模块。审计人员需要检查钱包能否安全地对模块的“增加/移除/使用”进行管理。如果使用了 `DELEGATECALL` 运行模块，审计人员应确保钱包插槽存储的数据安全。

总结

上述基础检查项基于当前 EIP4337 的账户抽象标准，供审计人员对账户抽象钱包进行检查。不同的钱包实现不尽相同，且目前基于 EIP4337 的实施还处于早期阶段，因此审计人员仍需要根据钱包的实际实现情况进行严格地检查。对于正在开发的项目来说，慢雾安全团队建议开发者在开发过程中仔细考虑上述检查项。最后，文中相关链接可通过点击阅读原文跳转至 GitHub 查看。