Blockchain Security Training Smart Contract Exploit Analysis Questions and Answers 1 — Questions and Answers
Question 1: A smart contract function intended for distributing rewards iterates through a dynamically-sized array of recipient addresses, sending funds to each one. As the number of recipients grows, transactions calling this function begin to consistently fail. What is the MOST likely cause of this failure?
- A reentrancy vulnerability in the fund transfer logic.
- An integer underflow when calculating the remaining contract balance.
- The transaction's cumulative gas cost exceeds the block gas limit. (Correct answer)
- Incorrect access control allowing non-recipients to be added to the array.
Correct answer: The transaction's cumulative gas cost exceeds the block gas limit.
When a smart contract function iterates over an array that can grow indefinitely, the gas required to execute the loop increases with the array's size. Each iteration and each external call (like sending funds) consumes gas. Eventually, the total gas needed to complete all iterations can surpass the block gas limit, causing any transaction that calls the function to fail. This creates a Denial of Service (DoS) vulnerability, as the core functionality becomes unusable.
Question 2: An analyst is reviewing a Solidity contract that handles token withdrawals. The function first sends the requested token amount to the user and then updates the user's balance in a mapping. Which classic smart contract vulnerability is this pattern susceptible to?
- Integer Overflow
- Reentrancy (Correct answer)
- Front-running
- Timestamp Dependence
Correct answer: Reentrancy
This pattern is vulnerable to a reentrancy attack. If the recipient is a malicious contract, it can use its fallback function to call the withdrawal function again before the original call has finished and updated the balance. This allows the attacker to repeatedly withdraw funds until the contract is drained. The correct, secure pattern is 'Checks-Effects-Interactions', where the balance is updated *before* the external call to send the funds is made.
Question 3: A malicious user observes a large pending decentralized exchange (DEX) trade in the mempool that will significantly increase a token's price. The user quickly submits their own 'buy' transaction for the same token with a much higher gas fee, followed immediately by a 'sell' transaction. Which type of exploit is this user attempting?
- A flash loan attack
- An access control bypass
- A reentrancy attack
- A front-running attack (Correct answer)
Correct answer: A front-running attack
This scenario describes a front-running attack. Attackers monitor the mempool for pending transactions that will affect market prices. By submitting their own transaction with a higher gas fee, they incentivize miners to include their transaction in the block first. This allows them to profit from the price movement caused by the original, slower transaction.
Question 4: A smart contract written in a very old version of Solidity (pre-0.8.0) allows users to transfer tokens. A user with a balance of 10 tokens attempts to transfer 20 tokens. The contract code subtracts the transfer amount from the sender's balance without any safety checks. What is the likely outcome for the sender's balance after the transaction?
- The transaction will revert due to insufficient funds.
- The sender's balance will become a very large positive number. (Correct answer)
- The sender's balance will become -10.
- The sender's balance will be set to 0.
Correct answer: The sender's balance will become a very large positive number.
This is a classic integer underflow vulnerability. In Solidity versions before 0.8.0, arithmetic operations did not have built-in checks for overflow or underflow. When subtracting a larger number (20) from a smaller one (10) using unsigned integers, the value wraps around to the maximum possible value for that integer type, resulting in a very large positive balance for the sender.
Question 5: During a security audit, you discover a public `initialize` function in a proxy contract that sets the contract's owner. The contract has already been deployed and is in use. Which of the following represents the MOST critical and immediate threat?
- An attacker could cause the contract to run out of gas.
- An attacker could call the function to take ownership of the contract. (Correct answer)
- A user could accidentally lock their own funds by calling the function.
- The contract state could be corrupted by a reentrancy attack.
Correct answer: An attacker could call the function to take ownership of the contract.
This is a severe access control vulnerability. If a function that sets critical state variables like the owner is left public and without any checks to ensure it's only called once, anyone can call it at any time. An attacker can simply call this `initialize` function, set themselves as the new owner, and gain complete control over the contract's privileged functions, potentially draining all funds.
Question 6: Which of the following tools is primarily used for static analysis of Solidity smart contracts, allowing developers to detect vulnerabilities by examining the source code without actually executing it?
- Ganache
- Truffle
- Slither (Correct answer)
- Remix IDE
Correct answer: Slither
Slither is a widely used static analysis framework for Solidity. It analyzes the contract's source code to find a wide range of vulnerabilities, logic errors, and bad practices without needing to run the code on a blockchain. Ganache is a personal blockchain for development, Truffle is a development framework, and Remix is an IDE, which may integrate static analysis but is not the tool itself.
A smart contract function intended for distributing rewards iterates through a dynamically-sized array of recipient addresses, sending funds to each one.
As the number of recipients grows, transactions calling this function begin to consistently fail.
What is the MOST likely cause of this failure?