PART 1 : INTRODUCTION TO REENTRANCY

Blockchain technology and smart contracts have revolutionised various industries by enabling decentralised and automated processes. However, these innovations come with their own set of vulnerabilities. One critical vulnerability is reentrancy, which can lead to significant security breaches if not adequately addressed. In this blog, we will delve into reentrancy, how it works, and how to prevent it.

REENTRANCY

Reentrancy is a vulnerability in smart contracts that allows attackers to repeatedly call a function before the previous function call is completed. This can result in unexpected behaviour and potential exploitation.

BANK WITHDRAWAL ANALOGY

Imagine you have a bank account with ₹1000. You go to the bank’s ATM to withdraw ₹750. Usually, the process works like this:

  1. You Initiate the Withdrawal:
    • You request to withdraw ₹750 from your account.
  2. The ATM Checks Your Balance:
    • The ATM sees you have ₹1000 and verifies you can withdraw ₹750.
  3. The ATM Dispenses the Money:
    • The ATM gives you ₹750.
  4. The ATM Updates Your Balance:
    • The ATM updates your balance to ₹250

In a secure system, these steps happen sequentially, ensuring that your balance reflects the transaction after you withdraw money.

REENTRANCY SCENARIO

Let’s imagine a scenario where the ATM has a flaw similar to a reentrancy vulnerability in a smart contract.

  1. You Initiate the Withdrawal:
    • You request to withdraw ₹750 from your account.
  2. The ATM Checks Your Balance:
    • The ATM sees you have ₹1000 and verifies you can withdraw ₹750.
  3. The ATM Dispenses the Money:
    • The ATM dispenses the ₹750 but hasn’t updated your balance yet.
  4. Before the Balance is Updated:
    • You quickly insert another card into the ATM and request another ₹750 withdrawal before the ATM updates your balance.
    • The ATM again checks your balance (which still shows ₹1000) and dispenses another ₹750.

Because the ATM didn’t update your balance before allowing the second transaction, it gives you another ₹750. You’ve withdrawn a total of ₹1500, but the ATM hasn’t yet reduced your balance, so it still shows ₹250 remaining.

GENERALISED PROCESS OF REENTRANCY
  1. Initial Call: The vulnerable contract initiates a call to an external contract, transferring control to it.
  2. Fallback Function: The external contract has a fallback function (or a similar mechanism) that gets triggered upon receiving the call.
  3. Reentrant Call: Before the initial function call in the vulnerable contract completes, the external contract makes a recursive call back into the original contract.
  4. Manipulation: The recursive call exploits the fact that the original contract has not yet updated its state, allowing the attacker to perform operations (e.g., multiple withdrawals) that should not be possible.

CASE STUDY – SPANKCHAIN REENTRANCY ATTACK

SpankChain is a blockchain-based platform designed specifically for the adult entertainment industry. It aims to solve various issues related to payment processing, censorship, and privacy that are prevalent in the adult industry.

OVERVIEW OF THE ATTACK

The attack utilised a reentrant call to the “LCOpenTimeout” function which was present in “LedgerChannel.sol” to drain funds from the contract. Here’s a detailed step-by-step explanation of how the attack was executed:

KEY FUNCTIONS INVOLVED
1. LCOpenTimeout( );

This function allows a user to exit a channel if the hub (partyI) does not join within a specified timeout period. If the timeout expires, users can call “LCOpenTimeout” to reclaim their deposited ETH and ERC20 tokens.

function LCOpenTimeout(bytes32 _lcID) public {
    require(msg.sender == Channels[_lcID].partyAddresses[0], "Sender not part of party");
    require(Channels[_lcID].isOpen == false, "Channel is joined");
    require(now > Channels[_lcID].LCopenTimeout, "Timeout not expired");
    if (Channels[_lcID].initialDeposit[0] != 0) {
        Channels[_lcID].partyAddresses[0].transfer(Channels[_lcID].ethBalances[0]);
    }
    if (Channels[_lcID].initialDeposit[1] != 0) {
        require(Channels[_lcID].token.transfer(Channels[_lcID].partyAddresses[0], Channels[_lcID].erc20Balances[0]), "CreateChannel: token transfer failure");
    }
    emit DidLCClose(_lcID, 0, Channels[_lcID].ethBalances[0], Channels[_lcID].erc20Balances[0], 0, 0);
    delete Channels[_lcID];
}
2. createChannel( );

This function initialises a channel with specified parameters, including initial balances in ETH and ERC20 tokens, and sets a timeout period.

function createChannel(
    bytes32 _lcID,
    address _partyI,
    uint256 _confirmTime,
    address _token,
    uint256[2] _balances // [eth, token]
) public payable {
    require(Channels[_lcID].partyAddresses[0] == address(0), "Channel has already been created.");
    require(_partyI != 0x0, "No partyI address provided to LC creation");
    require(_balances[0] >= 0 && _balances[1] >= 0, "Balances cannot be negative");
    Channels[_lcID].partyAddresses[0] = msg.sender;
    Channels[_lcID].partyAddresses[1] = _partyI;
    if (_balances[0] != 0) {
        require(msg.value == _balances[0], "Eth balance does not match sent value");
        Channels[_lcID].ethBalances[0] = msg.value;
    }
    if (_balances[1] != 0) {
        Channels[_lcID].token = HumanStandardToken(_token);
        require(Channels[_lcID].token.transferFrom(msg.sender, this, _balances[1]), "CreateChannel: token transfer failure");
        Channels[_lcID].erc20Balances[0] = _balances[1];
    }
    Channels[_lcID].sequence = 0;
    Channels[_lcID].confirmTime = _confirmTime;
    Channels[_lcID].LCopenTimeout = now + _confirmTime;
    Channels[_lcID].initialDeposit = _balances;
    emit DidLCOpen(_lcID, msg.sender, _partyI, _balances[0], _token, _balances[1], Channels[_lcID].LCopenTimeout);
}
ATTACK FLOW DIAGRAM
STEPS OF ATTACK
  1. Deploy the Malicious Contract:
    • The attacker deploys a malicious contract that mimics an ERC20 token. This contract contains attack, transfer, and withdraw functions.
  2. Initialize the Channel:
    • The attacker uses the “attack( )” function to open a channel with their malicious ERC20 contract, setting “confirmTime” to 0. This allows the attacker to call “LCOpenTimeout( )” immediately, without giving the hub a chance to join.
  3. Channel Creation:
    • The “LedgerChannel” contract creates a channel for the malicious contract, with “confirmTime” set to 0.
  4. Emit Channel Creation Log:
    • Once the channel is created, the “LedgerChannel” contract emits a log of the channel creation. This log serves as a trigger for the malicious contract.
  5. Trigger Reentrancy:
    • Upon receiving the log, the malicious contract triggers the “transfer( )” function, which calls the vulnerable “LCOpenTimeout()” function in the “LedgerChannel.sol” contract.
  6. Reentrancy Execution:
    • The “LCOpenTimeout( )” function checks three conditions for execution:
      • “msg.sender” must be one of the channel participants.
      • “Channels[_lcID].isOpen” must be false, indicating no hub has joined the channel.
      • The current time must be greater than “Channels[_lcID].LCopenTimeout”.
    • If all conditions are met, the function begins the insecure refund process.
  7. Perform Refund Calculation:
    • The function transfers ETH and ERC20 tokens to the attacker:
    • if(Channels[_lcID].initialDeposit[0] != 0) { Channels[_lcID].partyAddresses[0].transfer(Channels[_lcID].ethBalances[0]); }
    • if(Channels[_lcID].initialDeposit[1] != 0) { require(Channels[_lcID].token.transfer(Channels[_lcID].partyAddresses[0], Channels[_lcID].erc20Balances[0]), “CreateChannel: transfer failure”); }
  8. Send Refund:
    • The “LedgerChannel” contract sends ETH to the malicious contract. Before the channel is deleted, the contract re-calls the vulnerable “LCOpenTimeout( )” function.
  9. Loop until Maximum Reentries:
    • The malicious contract specifies a maximum number of reentries to prevent gas exhaustion. The process of refund calculation and re-calling “LCOpenTimeout( )” repeats until this limit is reached.
  10. Update Blockchain State:
    • The state of the blockchain is updated to reflect the successful transfer of funds and the deletion of the channel.
  11. Withdraw Drained Funds:
    • Finally, the attacker calls the “withdraw” function, transferring all the drained funds from the contract balance to a personal wallet.

CONCLUSION

Reentrancy is a potent and notorious vulnerability in smart contracts, with the potential to cause severe financial losses, as exemplified by the SpankChain reentrancy attack. This vulnerability highlights the critical importance of thorough security audits and robust coding practices in the development of smart contracts.

In conclusion, while blockchain technology and smart contracts offer transformative capabilities across various industries, they also introduce new security challenges. Addressing these challenges requires a proactive approach to security, ensuring that the innovative potential of blockchain is realized without compromising the safety and integrity of its applications.

Leave a Reply

Your email address will not be published. Required fields are marked *