Solidity Security

Exercises pertaining to various smart contract vulnerabilities.

Rentrancy Attacks: HoneyPot

Reentrancy Attack on a Smart Contract. The goal of this exercise is to get practical skills in writing simple smart contracts in Solidity, publishing and testing contracts in the Remix IDE.

Got the contract to compile at version 0.4.26+commit.4563c3fc.

HoneyPot get() function sends ether to the address that called it only if this contract has any ether as balance. When HoneyPot sends ether to the HoneyPotCollect contract the fallback function is triggered. If the HoneyPot balance is more than the value that it was sent to, the fallback function calls get() function once again and the cycle repeats. Recall that within the get() function the code that sets the balance to zero comes only after sending the transaction. This tricks the HoneyPot contract into sending money to the HoneyPotCollect address repeatedly until HoneyPot is depleted of almost all its ether, resulting with an address with at least 100+ ethers.

NOTE: Unfortunately, due to Remix's robust security measures, this contract will not deploy for any value over 0, thus the reentrancy exercise was not successfully.

Short Address Attacks

In this Exercise we are going to be learning what is ERC20 short attack and how to protect smart contracts from it. This kind of attack was discovered by Golem Project experts. In April of 2017 they discovered a security bug affecting some exchanges. When certain exchanges processed transactions of ERC20 tokens, input validation was not being performed on account address length. The result was malformed input data being provided to the contract’s transfer function, and a subsequent underflow condition that manipulated the amount being sent. The impact was that an attacker could potentially rob an exchange account of tokens.

This exercise is based on:

• Original Golem team article “How to Find $10M Just by Reading the Blockchain”
• Eric Rafaloff`s article “Analyzing the ERC20 Short Address Attack”

Connect to Ethereum Client (Ganache)

1. Compile the code in Remix IDE.

2. Now start Ganache-CLI. We will use local Ethereum blockchain to make the transaction with the contract and analyse the input data.

$ ganache-cli

3. Now connect Remix with Ganache-CLI. First remove the “https” from the beginning of the remix address if it's needed and replace it with "http". Then open [Run] tab and click on [Web3 Provider].

4. Confirm your wish to connect to the Ethereum node. Set the Web3 Provider Endpoint. And click [OK].

Write the Vulnerable Smart Contract

1. Create the contract.

2. Send amount of 2 coins to some of the addresses generate by Ganache-CLI for example the second one).

3. Ethereum’s Contract ABI (application binary interface) allows clients to call a contract’s function. If somebody wanted to send coins to another address, he would create a transaction with input data that would look like this. Open the details of transaction and look at input.

4. Analyze the input data:

• 0x90b98a11 is the method ID (4 bytes), which is the Keccak (SHA-3) hash of the method signature. 4 bytes.
• 000000000000000000000000082c21ea8121243b8a821b67066c9997b207a712 is the “to” address. 32 bytes, with the destination address (20 bytes) filled with leading zeros.
• 0000000000000000000000000000000000000000000000000000000000000002 is the “amount” unsigned integer. Padded to 32 bytes.

How Does an ERC20 Short Attack Work?

Now the tricky place is how the Ethereum virtual machine handle this input data. The described scenario concerns only separated cases and we can`t demonstrated it with Remix and Ganache, but the process is described below. What would happen if the client were to send the address without last digits? The client could choose not to pad the address properly so that the address is less than 32 bytes. The total input data length would be less than what is expected, causing a condition where a data underflow may occur. Let us suppose that we want to send some coins again to the same address. However, this time we decide to drop the last two digits of the address which is “12”.

We end up with the following input data:

• 0x90b98a11
• 000000000000000000000000082c21ea8121243b8a821b67066c9997b207a700
• 00000000000000000000000000000000000000000000000000000000000002^^ note the missing byte

How does Solidity/EVM handle underflows?

The contract event generated by transaction tells the answer:

Event name: Transfer

Return values:

• _from : 0x66c962085de823261a102d217557c2f0738b2a9a
• _to : 0x82c21ea8121243b8a821b67066c9997b207a700
• _value : 512

The missing byte has been replaced with 00. This effectively performed a bit shift operation of 8 bits to the left. As a result, the address had 00 added to the end (taken from the zeros at the beginning of the proceeding word), and the number of coins transferred became 512 (2<<8 = 512).

Necessary List of Conditions

For this type of attack, the required conditions are:

• Ethereum address ends with a 0.
• Exchange wallet must have at least 256,000 tokens.
• The attacker can send 1,000 tokens to this exchange wallet, crediting his account internally (off-chain) with 1,000.
• Then he can request a withdrawal of 1,000 tokens using generated address. He must leave off the last "0" byte.

Mitigation

A quick fix could be checking whether the msg.data has the correct length this function is expecting. This is the original post: Reddit. This method can be implemented by adding a new modifier onlyPayloadSize which will prevent the short address attack.

Module

MI3: Module 5: E1/E2