Home

Awesome

All Blockchain Audits

A collection of my personal blockchain security audits.

My publications on Substack.

My Youtube Account.

For enquiries and quotes on private audits or audit consultations, reach out to me on

BailSec

DateProtocol Name
2024-12Undisclosed

Shieldify Security

DateProtocol Name
2024-12Undisclosed
2024-12Undisclosed
2024-11Dinero
2024-11HoneyPot Finance
2024-10Vyper

Pashov Audit Group

DateProtocol Name
2024-11Undisclosed
2024-11Rivus
2024-10LaPoste
2024-10Ethena
2024-09Interpol
2024-07Curio
2024-07GroupCoin
2024-06Bio
2024-05Fyde
2024-05Aburra
2024-05Rivus
2024-04Open Dollar
2024-04Curio
2024-03Fyde
2024-02Tapioca DAO

Cantina

DateProtocol NameHighMediumLowRank
2024-07Grass2--8
2024-04Curvance4--9

Code4rena

DateProtocol NameHighMediumLowNon-CriticalGasRank
2024-05Renzo23---16/122
2024-02UniStaker-----12/47
2024-01Decent23---11/113
2024-01Salty.IO13---12/177
2023-12Shell-----1/22
2023-10Ethena-3---1/147
2023-06Stader-2---20/75
2023-05Venus-3---12/102
2023-04Frankencoin-2---52/199
2023-04Caviar-1---31/120
2023-03Asymmetry2384-17/246
2023-03Wenwin -168-21/93
2023-02Popcorn 3-42-54/169
2023-01RabbitHole Quest1336-26/173
2023-01Ondo Finance1-42-6/69
2023-01Biconomy-353-21/105
2022-11Debt DAO-115441/120
2022-10Holograph-123235/144
2022-103xcalibur-213126/102
2022-10Inverse Finance-2---84/127
2022-10Juicebox---3-35/67
2022-09VTVL Protocol-11-479/198
2022-09Frax Finance----899/133
2022-09Y2k Finance----6102/110
2022-09PartyDAO----297/110

Sherlock

DateProtocol NameHighMedium
2023-01UXD Protocol13
2022-11Buffer Finance-1
2022-11Rage Trade1-
2022-11Astaria12
2022-10Union Finance-1

Sherlock Judging Contest

DateProtocol NameRank
2023-02Union Finance Update4/50
2023-01Ajna5/87
2023-01Cooler5/68
2023-01UXD Protocol10/69
2023-01Illuminate Round 212/33
2023-01Notional Update12/57

About Me

Top 76th Code4rena 2023 Leaderboards

Warden Name: peanuts

Sample Report (Biconomy)

Contest: https://code4rena.com/contests/2023-01-biconomy-smart-contract-wallet-contest

Findings Summary

IDTitleSeverity
M-01handleAggregatedOps() does not handle non-atomic transactions which results in whole function revert if one transaction does not go throughMedium
M-02EntryPoint address in SmartAccount.sol cannot execute certain functions because of the onlyOwner modifierMedium
M-03Protocol has upgradeable contracts that cannot be upgradedMedium
L-01Initializers can be frontrunnableLow
L-02Contract should adhere to two-step ownership processLow
L-03Unused/Empty receive()/fallback() functionLow
L-04OpenZeppelin's ECDSA is imported but not utilizedLow
L-05Import exact functions instead of the whole contract itselfLow
N-01Non-library/interface files should use fixed compiler versions, not floating onesInfo
N-02Avoid the use of sensitive terms in favour of neutral onesInfo
N-03Testing coverage is not adequate enoughInfo

Full Report

Medium Findings:

[M-01] handleAggregatedOps() does not handle non-atomic transactions which results in whole function revert if one transaction does not go through

Lines of code

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/aa-4337/core/EntryPoint.sol#L93 https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/aa-4337/core/EntryPoint.sol#L385 https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/aa-4337/core/EntryPoint.sol#L289

Impact

Function reverts if one account or paymaster is not validated, which leads to a waste of time and gas.

Proof of Concept

EntryPoint.UserOpsPerAggregator() takes in an array of opsPerAggregator in its parameter and loops through each struct. In the function, the function _validatePrepayment() is called which validates the account and paymaster from each opsPerAggregator.

function _validatePrepayment(uint256 opIndex, UserOperation calldata userOp, UserOpInfo memory outOpInfo, address aggregator)
private returns (address actualAggregator, uint256 deadline) {


    uint256 preGas = gasleft();
    MemoryUserOp memory mUserOp = outOpInfo.mUserOp;
    _copyUserOpToMemory(userOp, mUserOp);
    outOpInfo.userOpHash = getUserOpHash(userOp);


    // validate all numeric values in userOp are well below 128 bit, so they can safely be added
    // and multiplied without causing overflow
    uint256 maxGasValues = mUserOp.preVerificationGas | mUserOp.verificationGasLimit | mUserOp.callGasLimit |
    userOp.maxFeePerGas | userOp.maxPriorityFeePerGas;
    require(maxGasValues <= type(uint120).max, "AA94 gas values overflow");


    uint256 gasUsedByValidateAccountPrepayment;
    (uint256 requiredPreFund) = _getRequiredPrefund(mUserOp);
    (gasUsedByValidateAccountPrepayment, actualAggregator, deadline) = _validateAccountPrepayment(opIndex, userOp, outOpInfo, aggregator, requiredPreFund);
    //a "marker" where account opcode validation is done and paymaster opcode validation is about to start
    // (used only by off-chain simulateValidation)
    numberMarker();

The function then continues to call _validateAccountPrepayment which does another round of checks.

function _validateAccountPrepayment(uint256 opIndex, UserOperation calldata op, UserOpInfo memory opInfo, address aggregator, uint256 requiredPrefund)
internal returns (uint256 gasUsedByValidateAccountPrepayment, address actualAggregator, uint256 deadline) {
unchecked {
    uint256 preGas = gasleft();
    MemoryUserOp memory mUserOp = opInfo.mUserOp;
    address sender = mUserOp.sender;
    _createSenderIfNeeded(opIndex, opInfo, op.initCode);
    if (aggregator == SIMULATE_FIND_AGGREGATOR) {
        numberMarker();


        if (sender.code.length == 0) {
            // it would revert anyway. but give a meaningful message
            revert FailedOp(0, address(0), "AA20 account not deployed");
        }
        if (mUserOp.paymaster != address(0) && mUserOp.paymaster.code.length == 0) {
            // it would revert anyway. but give a meaningful message
            revert FailedOp(0, address(0), "AA30 paymaster not deployed");
        }
        try IAggregatedAccount(sender).getAggregator() returns (address userOpAggregator) {
            aggregator = actualAggregator = userOpAggregator;
        } catch {
            aggregator = actualAggregator = address(0);
        }
    }

If any opsPerAggregator is not validated, the whole function will revert, leading to a waste of time and gas.

Tools Used

VSCode

Recommended Mitigation Steps

Make the loop non-atomic by using a try/catch block. If the paymaster / account is not validated, skip the loop and validate the next one. In _compensate, make sure to count the collected amount correctly if some opsPerAggregator are skipped because of validation failure.

[M-02] EntryPoint address in SmartAccount.sol cannot execute certain functions because of the onlyOwner modifier

Lines of code

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L460 https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L465 https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L494

Impact

EntryPoint address in SmartAccount.sol cannot execute certain functions because of the onlyOwner modifier.

Proof of Concept The functions SmartAccount.execute() and SmartAccount.executeBatch() has an onlyOwner modifier.

function execute(address dest, uint value, bytes calldata func) external onlyOwner{
function executeBatch(address[] calldata dest, bytes[] calldata func) external onlyOwner{

However, both functions call another function _requireFromEntryPointOrOwner();

    _requireFromEntryPointOrOwner();

which checks if msg.sender is adderss(entryPoint()) or owner

function _requireFromEntryPointOrOwner() internal view {
    require(msg.sender == address(entryPoint()) || msg.sender == owner, "account: not Owner or EntryPoint");
}

Since execute() and executeBatch() has an onlyOwner modifier which checks if msg.sender is owner only,

modifier onlyOwner {
    require(msg.sender == owner, "Smart Account:: Sender is not authorized");
    _;
}

address(entryPoint()) cannot call the function execute() and executeBatch().

Tools Used

VSCode

Recommended Mitigation Steps

Either take out the onlyOwner modifer in the two functions or remove the _requireFromEntryPointOrOwner() check if the function intends to not allow the msg.sender to be address(entryPoint()).

[M-03] Protocol has upgradeable contracts that cannot be upgraded

Lines of code

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L28

Impact

Protocol cannot upgrade the upgradeable contract.

Proof of Concept

SmartAccount.sol uses ReentrancyGuardUpgradeable but not UUPSUpgradeable.

contract SmartAccount is
     Singleton,
     BaseSmartAccount,
     IERC165,
     ModuleManager,
     SignatureDecoder,
     SecuredTokenTransfer,
     ISignatureValidatorConstants,
     FallbackManager,
     Initializable,
     ReentrancyGuardUpgradeable
    {

Tools Used

Manual Review

Recommended Mitigation Steps

import UUPSUpgradeable, inherit the contract, and initialize the contract

import {UUPSUpgradeable} from "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
contract SmartAccount is
     Singleton,
     BaseSmartAccount,
     IERC165,
     ModuleManager,
     SignatureDecoder,
     SecuredTokenTransfer,
     ISignatureValidatorConstants,
     FallbackManager,
     Initializable,
     ReentrancyGuardUpgradeable
+    UUPSUpgradeable
    {
    function init(address _owner, address _entryPointAddress, address _handler) public override initializer {
        require(owner == address(0), "Already initialized");
        require(address(_entryPoint) == address(0), "Already initialized");
        require(_owner != address(0),"Invalid owner");
        require(_entryPointAddress != address(0), "Invalid Entrypoint");
        require(_handler != address(0), "Invalid Entrypoint");
+       __UUPSUpgradeable_init();
        owner = _owner;
        _entryPoint =  IEntryPoint(payable(_entryPointAddress));
        if (_handler != address(0)) internalSetFallbackHandler(_handler);
        setupModules(address(0), bytes(""));
    }

Also add storage gap for upgradeable contracts.

uint256[45] private __gap;

Low and Non-Critical Findings:

[L-01] Initializers can be frontrunnable

If the initializer is not executed in the same transaction as the constructor, a malicious user can front-run the initialize() call, forcing the contract to be redeployed.

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L166-L176

[L-02] Contract should adhere to two-step ownership process

Setting the owner within one function can be dangerous if the address of the owner in the parameter is not set properly. Consider using a two-step process whereby the owner has to acknowledge the change before changing the ownership.

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L109-L125

[L-03] Unused/Empty receive()/fallback() function

If the intention is for the Ether to be used, the function should call another function, otherwise it should revert (e.g. require(msg.sender == address(weth)). Having no access control on the function means that someone may send Ether to the contract, and have no way to get anything back out, which is a loss of funds

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L550

[L-04] OpenZeppelin's ECDSA is imported but not utilized

Use OpenZeppelin’s ECDSA contract rather than calling ecrecover() directly

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/SmartAccount.sol#L347

[L-05] Import exact functions instead of the whole contract itself

Example:

import {ReentrancyGuardUpgradeable} from "@openzeppelin/contracts-upgradeable/security/ReentrancyGuardUpgradeable.sol"; instead of

import "@openzeppelin/contracts-upgradeable/security/ReentrancyGuardUpgradeable.sol"; Applies to all contracts in Biconomy protocol.

SmartAccount.sol:

import "./libs/LibAddress.sol"; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol"; import "@openzeppelin/contracts-upgradeable/security/ReentrancyGuardUpgradeable.sol"; import "./BaseSmartAccount.sol"; import "./common/Singleton.sol"; import "./base/ModuleManager.sol"; import "./base/FallbackManager.sol"; import "./common/SignatureDecoder.sol"; import "./common/SecuredTokenTransfer.sol"; import "./interfaces/ISignatureValidator.sol"; import "./interfaces/IERC165.sol"; import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

[N-01] Non-library/interface files should use fixed compiler versions, not floating ones

eg. 0.8.10 instead of ^0.8.10

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/paymasters/BasePaymaster.sol#L2

[N-02] Avoid the use of sensitive terms in favour of neutral ones

Use allowlist rather than whitelist.

https://github.com/code-423n4/2023-01-biconomy/blob/53c8c3823175aeb26dee5529eeefa81240a406ba/scw-contracts/contracts/smart-contract-wallet/base/ModuleManager.sol#L28

[N-03] Testing coverage is not adequate enough

What is the overall line coverage percentage provided by your tests?: 41 Protocol should aim to achieve >95% testing coverage to make sure that all functions are in working order.