Reentrancy Attacks and The DAO Hack: A Deep Dive

Reentrancy attacks, famously exploited during The DAO hack, occur due to vulnerabilities in Solidity smart contract code. This article explores one of Ethereum's earliest and most notorious exploits—the attack on The DAO), a decentralized autonomous organization (DAO). The method used is now known as a reentrancy attack.

Prerequisites

Before diving in, familiarize yourself with:

• Blockchain fundamentals, especially Ethereum.
• The Ethereum Virtual Machine (EVM): A decentralized state machine running on Ethereum nodes.
• Smart contracts: Self-executing code written in Solidity and deployed on the EVM.
• Ethereum accounts: Entities with ETH balances that can send transactions. These include externally owned accounts (user-controlled) and contract accounts (deployed smart contracts).

No prior Solidity knowledge is required—the code examples are simplified.

👉 Follow this reentrancy attack tutorial for hands-on learning.

The DAO Hack: A Brief History

In 2016, The DAO, a community-controlled investment fund, raised $150 million worth of ETH (3.54 million ETH) by selling tokens. Investors deposited ETH to participate in its decentralized venture capital fund.

However, within months, a black-hat hacker drained The DAO’s funds using a reentrancy attack. The aftermath sparked debates:

1. Purists argued blockchain immutability must be preserved, even at great cost.
2. Interventionists advocated for a fork to reverse the theft.

Ultimately, Ethereum executed a hard fork, splitting into Ethereum (current chain) and Ethereum Classic (original chain).

What Is a Reentrancy Attack in Solidity?

Smart contracts interact via function calls. A reentrancy attack exploits fallback functions, which trigger when:

• ETH is sent to a contract without calldata (and no receive() function exists).
• The fallback contains malicious logic that re-calls the vulnerable function.

Attack Flow:

1. Hacker’s contract deposits ETH into The DAO.
2. It calls withdraw(), triggering ETH transfer to the hacker’s contract.
3. The transfer activates the hacker’s fallback function, which recursively calls withdraw() before the original call completes.
4. Since balances aren’t updated until after ETH is sent, the loop drains The DAO’s funds.

Code Example: The DAO Vulnerability

Vulnerable Contract (Dao.sol):

pragma solidity ^0.8.10;
contract Dao {
    mapping(address => uint256) public balances;

    function withdraw() public {
        require(balances[msg.sender] >= 1 ether);
        uint256 bal = balances[msg.sender];
        (bool sent, ) = msg.sender.call{value: bal}(""); // ETH sent before balance update
        require(sent);
        balances[msg.sender] = 0; // Balance updated too late!
    }
}

Attacker Contract (Hacker.sol):

contract Hacker {
    function attack() public payable {
        dao.deposit{value: 1 ether}();
        dao.withdraw(); // Starts reentrancy loop
    }

    fallback() external payable {
        if (address(dao).balance >= 1 ether) {
            dao.withdraw(); // Reenters withdraw()
        }
    }
}

Key Issue: The DAO updates balances after sending ETH, allowing recursive withdrawals.

Fixing Reentrancy Vulnerabilities

Solution 1: Update Balances First

function withdraw() public {
    uint256 bal = balances[msg.sender];
    balances[msg.sender] = 0; // Update before sending ETH
    (bool sent, ) = msg.sender.call{value: bal}("");
    require(sent);
}

Solution 2: Use a Mutex Lock

contract Dao {
    bool internal locked;

    modifier noReentrancy() {
        require(!locked, "No reentrancy");
        locked = true;
        _;
        locked = false;
    }

    function withdraw() public noReentrancy { ... }
}

FAQs

1. What made The DAO hack possible?

A flawed withdraw() function that sent ETH before updating balances, enabling recursive calls.

2. How did Ethereum respond to the hack?

A contentious hard fork created two chains: Ethereum (new) and Ethereum Classic (original).

3. Can reentrancy attacks still happen today?

Yes, but tools like OpenZeppelin’s ReentrancyGuard and audits reduce risks.

4. Why use a fallback function in the attack?

Fallbacks execute when ETH is received, providing a hook to re-enter the vulnerable contract.

5. Are all DAOs vulnerable to reentrancy?

Only those with unsecured state changes during external calls. Modern DAOs use safeguards like mutexes.

6. What’s the ethical debate around The DAO fork?

Purists vs. pragmatists: immutability vs. protecting user funds.

Conclusion

The DAO hack remains a pivotal lesson in smart contract security. By understanding reentrancy—and adopting preventive measures like checks-effects-interactions patterns or mutex locks—developers can build safer DeFi systems.

For deeper dives, explore The DAO’s original GitHub repo and its security patches.

👉 Discover more blockchain security tips to safeguard your projects.