This was the first holistic survey of Ethereum security. Researchers identified 44 vulnerabilities, 26 attacks and 47 proposed defense mechanisms. Key takeaways: the application layer is especially vulnerable given the size of losses taken; smart contract developers need better, more secure languages and tools; existing studies on DApps ignore the frontend, and interactions between the backend and front.
- Chen, Huashan and Pendleton, Marcus and Njilla, Laurent and Xu, Shouhuai. 2020. A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses. In ACM Computing Surveys 53, 3, Article 67, DOI: https://doi.org/10.1145/3391195
Core Research Question
- What are the vulnerabilities across the different layers of Ethereum, the attacks exploiting them, and possible defense mechanisms?
- Ethereum has a 4-layer architecture. On top is the application layer, comprising users accounts, smart contracts, and the EVM (the Ethereum Virtual Machine). Directly below is the data layer, which stores the state of the blockchain (mined transactions, blocks, and events). Next, the consensus layer defines what the current state should be. At the bottom of the stack is the network layer, comprising the P2P protocol that nodes abide by when communicating with one another.
- An external environment, in turn, interfaces and supports different parts of each layer. Environment-related components include internet infrastructure (e.g., supports the network layer), a database (e.g., supports the data layer), cryptography libraries (e.g., supports the consensus layer), and UIs (e.g., supports the application layer).
- The paper presents a survey identifying: a) 44 vulnerabilities split across the 4 layers of the Ethereum architecture and its supporting environment; b) how these vulnerabilities can lead to 26 different attacks; and c) 47 defense mechanisms that could be used to prevent these attacks from happening.
- A catalog of 44 vulnerability types and their root causes—see Fig. 1. Vulnerability types are organized in terms where they occur, their causes, and their status. The latter signals whether a vulnerability type is eliminated, i.e., it no longer applies (shown with a filled square in the figure), whether it can be eliminated by a best practice (half filled square), or is yet to be eliminated (unfilled square). Following the survey, most vulnerabilities were found in the application layer (26), generally associated with issues in smart contract programing, including the underlying programming language and toolchain; the consensus, network, and environment layers had less known vulnerability types, but similarly distributed (between 5 and 6); the outlier was the data layer, where only 2 vulnerability types were identified—all with “eliminated” status.
- A catalog of 26 attacks exploiting the different vulnerabilities types—see Fig. 2.
- Identification of 47 proposed defense mechanisms, categorized into proactive (attempts to prevent an attack prior to contract deployment) and reactive (deals with the attack after a contract deployment). Since most of the identified vulnerability types concern the application layer, specifically smart contracts, most of the proactive defense mechanisms are geared towards smart contract development. This includes making use of guiding principles (such as those in Fig. 3), smart contract languages with better security guarantees (e.g., Vyper), different automated tools to aid vulnerability identification in the code (e.g., Mythril), and making use of formal verification (e.g., using the K framework). Examples of reactive approaches include pausing a contract once an attack is identified, as well as making use of proxy contracts, which facilitates upgrades (and hence bug fixing).
Figure 1. Vulnerability types and root causes
Figure 2. Attacks exploiting different vulnerabilities types and the consequences
of such attacks
Figure 3. Guiding principles and best practices for writing secure smart contracts
Discussion & Key Takeaways
- Application layer attacks caused the largest financial losses thus far; hence, special attention should be granted to that layer.
- Ethereum developers need better languages to develop smart contracts, with better security guarantees.
- Ethereum developers need more secure tools to write smart contracts.
- Existing studies largely focus on securing smart contracts (a DApp’s backend), ignoring the DApp’s frontend and interactions between the backend and frontend.
- Provide practitioners (e.g., auditors and smart contract developers) with a holistic overview of the security issues in Ethereum, their root causes, and potential defenses.
- Point to specific tooling needs, such as better programming languages with enhanced security guarantees.