Chapter 15 Exercises: Smart Contract Security

Exercise 1: Identify the Vulnerability (Conceptual)

Review the following Solidity function and identify all vulnerabilities present. For each vulnerability, explain the attack vector and propose a fix.

contract TokenSale {
    mapping(address => uint256) public balances;
    uint256 public tokenPrice = 1 ether;
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function buyTokens(uint256 amount) external payable {
        require(msg.value == amount * tokenPrice, "Wrong ETH amount");
        balances[msg.sender] += amount;
    }

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        (bool success, ) = msg.sender.call{value: amount * tokenPrice}("");
        require(success, "Transfer failed");
        balances[msg.sender] = 0;
    }

    function setPrice(uint256 newPrice) external {
        tokenPrice = newPrice;
    }

    function emergencyWithdraw() external {
        (bool success, ) = owner.call{value: address(this).balance}("");
        require(success);
    }
}

Expected vulnerabilities to identify: 1. Reentrancy in withdraw() (state updated after external call) 2. Missing access control on setPrice() (anyone can change the price) 3. Missing access control on emergencyWithdraw() (anyone can drain the contract) 4. Integer overflow risk in amount * tokenPrice multiplication (though Solidity 0.8+ would revert, this can cause unexpected reverts for large amounts) 5. No events emitted for monitoring

Exercise 2: Write a Reentrancy Exploit (Coding)

Given the VulnerableVault contract from the chapter text, write a complete attacker contract that exploits the reentrancy vulnerability. Your attacker contract should:

  1. Accept an initial deposit amount in its constructor.
  2. Have an attack() function that deposits into the vault and then triggers the exploit.
  3. Have a receive() function that re-enters the vault's withdraw().
  4. Include a mechanism to stop the recursion (checking the vault's balance).
  5. Have a collectProfit() function for the attacker to withdraw stolen funds.

Test your understanding by tracing through the execution: how many times does withdraw() execute if the vault has 10 ETH and the attacker deposits 1 ETH?

Exercise 3: Flash Loan Attack Analysis (Analytical)

The Beanstalk exploit is described in Section 15.2.3. Answer the following questions:

  1. Why did the attacker need a flash loan rather than simply buying governance tokens on the open market?
  2. What specific property of the governance system made it vulnerable to a flash loan attack?
  3. If Beanstalk had implemented snapshot-based voting (balances recorded at a past block), would this attack have been possible? Why or why not?
  4. If Beanstalk had implemented a 48-hour timelock on proposal execution, would this attack have been possible? Why or why not?
  5. Design a governance system that is resistant to flash loan attacks. Specify at least three mechanisms.

Exercise 4: Oracle Manipulation Scenario (Analytical)

A DeFi lending protocol uses Uniswap V2 spot prices as its price oracle. The protocol allows users to deposit Token X as collateral and borrow USDC against it. The collateralization ratio is 150% (users can borrow up to 66.7% of their collateral value).

An attacker has identified that the Uniswap pool for Token X / USDC has relatively low liquidity ($2 million total).

  1. Design a flash loan attack that exploits this oracle. Describe each step of the attack transaction.
  2. Calculate the approximate profit if the attacker can temporarily double the price of Token X using a $5 million flash loan.
  3. What would happen if the protocol used a Chainlink price feed instead of Uniswap spot price?
  4. What would happen if the protocol used a 30-minute TWAP from Uniswap V3?
  5. What is the maximum amount the attacker could steal, and what limits it?

Exercise 5: MEV Sandwich Attack (Analytical)

A user submits a transaction to swap 100 ETH for USDC on Uniswap V2 with a 1% slippage tolerance. The current price is 2,000 USDC/ETH.

  1. Explain how a searcher constructs a sandwich attack around this transaction.
  2. What is the maximum profit the searcher can extract, given the 1% slippage tolerance?
  3. How does reducing the slippage tolerance affect the sandwich attack profitability? What is the tradeoff for the user?
  4. If the user submits the transaction through Flashbots Protect instead of the public mempool, can the sandwich attack still occur? Why or why not?
  5. If the user uses CoW Protocol (batch auction) instead of Uniswap, can the sandwich attack still occur? Why or why not?

Exercise 6: Audit Report Writing (Practical)

Review the following contract and write a professional audit finding for the most critical vulnerability. Your finding should include: - Title - Severity (Critical / High / Medium / Low / Informational) - Description - Impact - Proof of concept (describe the attack steps) - Recommendation

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract SimpleLending {
    IERC20 public token;
    mapping(address => uint256) public deposits;
    mapping(address => uint256) public borrows;

    uint256 public totalDeposits;
    uint256 public totalBorrows;

    constructor(address _token) {
        token = IERC20(_token);
    }

    function deposit(uint256 amount) external {
        token.transferFrom(msg.sender, address(this), amount);
        deposits[msg.sender] += amount;
        totalDeposits += amount;
    }

    function borrow(uint256 amount) external {
        require(deposits[msg.sender] >= amount * 2, "Insufficient collateral");
        borrows[msg.sender] += amount;
        totalBorrows += amount;
        token.transfer(msg.sender, amount);
    }

    function repay(uint256 amount) external {
        token.transferFrom(msg.sender, address(this), amount);
        borrows[msg.sender] -= amount;
        totalBorrows -= amount;
    }

    function withdraw(uint256 amount) external {
        require(deposits[msg.sender] >= amount, "Insufficient deposits");
        deposits[msg.sender] -= amount;
        totalDeposits -= amount;
        token.transfer(msg.sender, amount);
    }

    function liquidate(address borrower) external {
        require(deposits[borrower] < borrows[borrower] * 2, "Not liquidatable");
        uint256 seized = deposits[borrower];
        deposits[borrower] = 0;
        borrows[borrower] = 0;
        token.transfer(msg.sender, seized);
    }
}

Exercise 7: Slither Practice (Tool-Based)

Install Slither and run it on the ReentrancyVulnerable.sol contract from this chapter's code directory.

  1. What findings does Slither report?
  2. For each finding, classify it as a true positive (real vulnerability) or false positive (not actually exploitable).
  3. Run Slither on ReentrancyFixed.sol. Does it still report any findings? If so, are they valid concerns?
  4. Explore Slither's printers by running slither --print contract-summary on both files. What information does the contract summary provide that is useful for an audit?

Exercise 8: Design a Secure Vault (Coding)

Design and implement a secure ETH vault contract that incorporates all the security patterns discussed in this chapter. Your contract must:

  1. Allow users to deposit and withdraw ETH.
  2. Use the checks-effects-interactions pattern in all functions.
  3. Include a ReentrancyGuard.
  4. Implement role-based access control (owner and guardian roles).
  5. Include a pause mechanism for emergencies.
  6. Emit events for all state changes.
  7. Include a withdrawal delay (users must request a withdrawal, wait 24 hours, then claim it).
  8. Set a maximum single-withdrawal limit.
  9. Have comprehensive NatSpec documentation.

Write the contract in Solidity ^0.8.20 using OpenZeppelin libraries where appropriate.

Exercise 9: The DAO Hack Timeline (Research)

Research the DAO hack using primary sources (Ethereum Foundation blog posts, the original DAO smart contract code on Etherscan, block explorer data) and construct a detailed timeline:

  1. When was The DAO deployed?
  2. How much ETH was raised, and over what period?
  3. When did the first warnings about the vulnerability appear?
  4. When did the attack begin, and what was the first exploit transaction hash?
  5. What was the community response in the hours after the attack began?
  6. When was the soft fork proposed, and why was it abandoned?
  7. When was the hard fork executed, and at what block number?
  8. What happened to the attacker's funds?
  9. When did Ethereum Classic trading begin?
  10. What was the long-term impact on Ethereum governance?

Exercise 10: Comparative Exploit Analysis (Advanced)

Choose two major smart contract exploits from the following list and write a comparative analysis (500-800 words):

  • The DAO (2016)
  • Parity Wallet (2017)
  • Cream Finance (2021)
  • Wormhole (2022)
  • Beanstalk (2022)
  • Euler Finance (2023)
  • Curve/Vyper (2023)

For each exploit, identify: - The vulnerability class - The root cause - The attack mechanism - The financial impact - Whether the funds were recovered - What defensive measures would have prevented it

Then compare the two exploits: what do they have in common, and what is fundamentally different about them? What does the comparison reveal about the evolution (or lack of evolution) of smart contract security?