本文旨在为审计人员提供账户抽象钱包的安全审计检查项,并提供部分针对性的审计指南。
作者:Kong@慢雾安全团队
前言
本文旨在为审计人员提供以 EIP4337 标准实现的账户抽象钱包的安全审计检查项,并提供部分针对性的审计指南。本文假设审计人员已经对 EIP4337 账户抽象标准和 EIP7562 账户抽象验证范围规则标准较为熟悉,因此不再赘述这两个标准。接下来,我们将简单介绍 EIP4337 架构与钱包交易执行流程。
架构
交易执行
在 EIP4337 设计标准中,首先由 EOA 签署 `UserOperation` 类型的数据,并通过 RPC 提交到一个单独的 Alt Mempools。此内存池独立于以太坊内存池,其汇总了用户提交的 UserOp 数据。Bundler 会从此内存池中提取 UserOp 以帮助用户执行,在执行之前将进行本地模拟,模拟失败的 `UserOp` 将被丢弃。所有的 UserOp 执行都由 Bundler 调用 EntryPoint 合约执行。EntryPoint 经过一系列验证后将调用用户的 AA 钱包,执行用户的 calldata。在此过程中,用户需要向 Bundler 支付交易上链执行的手续费,或者指定一个 Paymaster 进行代付。
![图片](https://web3caff.com/wp-content/uploads/2024/07/69_640wx_fmtpngampfromappmsgamptpwebpampwxfrom5ampwx_lazy1ampwx_co1.png)
执行详情
以下是 Bundler 通过 EntryPoint 调用用户钱包的详细过程,审计人员应熟悉此流程。
![图片](https://web3caff.com/wp-content/uploads/2024/07/70_640wx_fmtpngampfromappmsgamptpwebpampwxfrom5ampwx_lazy1ampwx_co1.png)
检查项
慢雾安全团队依据上述架构列出以下检查项,建议审计人员在对每个 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 查看。
免责声明:作为区块链信息平台,本站所发布文章仅代表作者及嘉宾个人观点,与 Web3Caff 立场无关。文章内的信息仅供参考,均不构成任何投资建议及要约,并请您遵守所在国家或地区的相关法律法规。