This repository contains examples of common Ethereum smart contract vulnerabilities, including code from real smart contracts. Use Not So Smart Contracts to learn about EVM and Solidity vulnerabilities, as a reference when performing security reviews, and as a benchmark for security and analysis tools.
In addition, we have also included analysis of several honeypots.
Each Not So Smart Contract includes a standard set of information:
- Description of the unique vulnerability type
- Attack scenarios to exploit the vulnerability
- Recommendations to eliminate or mitigate the vulnerability
- Real-world contracts that exhibit the flaw
- References to third-party resources with more information
| Not So Smart Contract | Description |
|---|---|
| Bad randomness | Contract attempts to get on-chain randomness, which can be manipulated by users |
| Denial of Service | Attacker stalls contract execution by failing in strategic way |
| Forced Ether Reception | Contracts can be forced to receive Ether |
| Incorrect Interface | Implementation uses different function signatures than interface |
| Integer Overflow | Arithmetic in Solidity (or EVM) is not safe by default |
| Race Condition | Transactions can be frontrun on the blockchain |
| Reentrancy | Calling external contracts gives them control over execution |
| Unchecked External Call | Some Solidity operations silently fail |
| Unprotected Function | Failure to use function modifier allows attacker to manipulate contract |
| Variable Shadowing | Local variable name is identical to one in outer scope |
| Wrong Constructor Name | Anyone can become owner of contract due to missing constructor |
The Ethereum community has discovered a variety of honeypot smart contracts operating on the mainnet blockchain - something that we have been investigating for quite some time. They’re designed to entice security researchers and developers to deposit Ethereum into the contract to obtain a chance to exploit ‘easy vulnerabilities’ in Solidity. However, once payment is deposited, the contracts will deploy subtle traps and quirks to lock out the user from successfully claiming the “prize.”
The traps vary in sophistication. Our blockchain security research has turned up six fundamental archetypes that construct most of these honeypots. Many seem to be moderately successful - trapping around 0.1 ether and containing approximately 5 transactions on average. Yet for every successful trap, a large minority of contracts had no interaction at all. These ‘failed honeypots’ most likely served the original developers as a testing environment. The existence of these contracts must be taken into account by academic researchers quantifying the effectiveness of tools and analysis methods for the Ethereum blockchain, given the potential to skew research results.
Versions of the most recent compilers will emit warnings of most of these traps during compilation. However, some of the contracts rely on logic gaps in the solc compiler and the Solidity language itself.
| Honeypot Archetype | Description |
|---|---|
| GiftBox | Etherscan doesn't show you everything! |
| King of the Hill | Variable shadowing of the owner ensures it is never reassigned. |
| Lottery | Unitialized structs default to acting like storage pointers. |
| Multiplicator | Abuses global variable semantics of this.balance. |
| PrivateBank | External constructor of a Log contract does not mirror code included in the contract. |
| VarLoop | Implicit conversion of var type variable into uint8 causes payment loop to short-circuit. |
These examples are developed and maintained by Trail of Bits. Contributions are encouraged and are covered under our bounty program.
If you have questions, problems, or just want to learn more, then join the #ethereum channel on the Empire Hacking Slack or contact us directly.