Threat Modeling Smart Contract Applications

INTRODUCTION 

Ethereum Smart Contracts and other complex blockchain programs are new, promising and highly experimental. Therefore, we should expect constant changes in the security landscape, as new bugs and security risks are discovered, and new best practices are developed [1]. 

This article is going to focus on threat modeling of smart contract applications. Threat modelling is a process by which threats, such as absence of appropriate safeguards, can be identified, enumerated, and mitigation can be prioritized accordingly. The purpose of threat model is to provide contract applications defenders with a systematic analysis of what controls or defenses need to be included, given the nature of the system, the probable attacker's profile, the most likely attack vectors, and the assets most desired by an attacker. 

Smart contract programming requires a different engineering mindset than we may be used to. The cost of failure can be high, and change can be difficult, making it in some ways more similar to hardware programming or financial services programming than web or mobile development. 

FORMAL VERIFICATION AND SMART CONTRACTS

At this point we should make clear that besides threat modeling, or as part of the threat modeling process, formal verification should also be mandatory. Formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics. In a few words is crucial for the code to do what is supposed to do [2].

A very good project example, as far as formal verification is concerned is the Cardano cryptocurrency technology. Cardano is developing a technology using a provably correct security model that it provides a guaranteed limit of adversarial power [3]. Also Cardano is using Haskell as a programming language, which is a language that facilitates formal verification.

SMART CONTRACT ASSETS

In order to continue analyzing the information from the Smart Contract ecosystem will define what are assets in the context of this Smart Contract Applications. 

Assets are:

• The Smart Contract function we require to protect. 
• The Smart Contract data we require to protect.

THREAT ACTORS

This section is going to focus on the threat actors of the smart contract applications. A threat actor or malicious actor is a person or entity responsible for an event or incident that impacts, the safety or security of smart contract applications. In the context if this article, the term is used to describe individuals and groups that perform malicious acts. 

More specifically we are going to reference the following actors:

• Nation State Actor with unlimited resources 
• Organized Crime Actor with significant resources 
• Insiders Actor with extensive knowledge of the system 
• Hacktivists Actor with ideology as a motive and limited resources
• Script Kiddies with limited knowledge of the technology and very few resources
• Others Actors, such as accidental attacks

Note: From a threat intelligence perspective, threat actors are often categorized as either unintentional or intentional and either external or internal. Also threat agents should be primarily based on access e.g. external or internal actors etc. The likelihood of the threat is closely related to the attacker motive e.g. Nation state attacker has high level of motivation and Script Kiddies low level of motivation and therefor low likelihood. 

SMART CONTRACT THREAT ACTORS

In this section we are going to discuss the threat actors that are related only to Smart Contract Applications. Each technology has its own peculiarities, and blockhain technologies have their own. 

The actors that are related to Smart Contracts are two types:

• Malicious Smart Contracts 
• Humans interacting with Smart Contracts through DApps or directly.

Smart contracts can call functions of other contracts and are even able create and deploy other contracts (e.g. issuing coins). There are several use-cases for this behavior. 

A few use cases of interacting with other contracts are described below:

• Use contracts as data stores
• Use other contracts as libraries

In the context of this article an Actor interacting with a Smart Contract outside the blockchain is en external Actor and an Actor interacting with a smart contract inside the blockchain is an internal Actor. 

COMMON SMART CONTRACT ATTACKS

The following is a list of known attacks which we should be aware of, and defend against when writing smart contracts [4]. 

• Reentrancy
• Reentrancy on a Single Function
• Cross-function Reentrancy
• Timestamp Dependence
• Integer Overflow and Underflow
• DoS with (Unexpected) revert
• DoS with Block Gas Limit
• Gas Limit DoS on the Network via Block Stuffing
• Insufficient gas griefing
• Forcibly Sending Ether to a Contract

We are not going to explain each attack here. For more information please see the link [4].

ATTACK TREES

This section is going to focus the attack trees of the contract applications. Attack Trees provide a formal, methodical way of describing the security of systems, based on varying attacks. A tree structure is used represent attacks against a system, with the goal as the root node and different ways of achieving that goal as leaf nodes. 

The attack attributes assist in associating risk with an attack. An Attack Tree can include special knowledge or equipment that is needed, the time required to complete a step, and the physical and legal risks assumed by the attacker. The values in the Attack Tree could also be operational or development expenses. An Attack Tree supports design and requirement decisions. If an attack costs the perpetrator more than the benefit, that attack will most likely not occur. However, if there are easy attacks that may result in benefit, then those need a defense.

Below we can see a typical client browser attack tree:

ABUSE CASE DIAGRAMS

The relationships between the work products of a security engineering process can be hard to understand, even for persons with a strong technical background but little knowledge of security engineering. Market forces are driving software practitioners who are not security specialists to develop software that requires security features. When these practitioners develop software solutions without appropriate security-specific processes and models, they sometimes fail to produce effective solutions. Same thing happens with Smart Contract development, that is why abuse case diagrams should be used to model the security requirements of Smart Contract applications.

We will define an abuse case as a specification of a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the system.

Below we can see a simple use case diagram:

Below we can see a simple abuse case diagram with an external actor:

In the diagram above an external bad actor is manipulating the login function externally. This is a typical client browser attack e.g. the DApp application has an stored XSS and the attacker install a fake login page or the DApp does not handle correctly users private key etc. 

Below we can see another  simple abuse case diagram with an external actor:

Again in the diagram above an external bad actor is manipulating the the approve function externally. This is a typical client browser attack e.g. the DApp application has CSRF and the attacker exploits the vulnerability through a phishing attack etc. 

Below we can see a simple abuse case diagram with an internal actor:

Again in the diagram above an internal bad actor, this time, is manipulating the the approve function internally. This is an attack conducted internally from a malicious contract e.g. running a Reentrancy attack using the callback function e.t.c.

LAST WORDS

Before releasing any Smart Contract system make sure the system is pen-tested and the code is reviewed and there is in place a formal verification of the contract.

For code reviews make sure to:

• Use a consistent code style
• Avoid leaving commented code
• Avoid unused code and unnecessary inheritance 
• Use a fixed version of the Solidity compiler 
• Analysis of GAS usage 

For pen-test make sure to:

• Run a normal Web App pen-test for the web component of the DApp
• Check how the DApp is interacting with the Smart Contract

Logical flow to follow would be:

TOOLS TO USE

Below there is a list of tools we can utilize to test our Smart Contract system:

• Mythril :- Mythril is a security analysis tool for EVM bytecode. It detects security vulnerabilities in smart contracts built for Ethereum, Hedera, Quorum, Vechain, Roostock, Tron and other EVM-compatible blockchains.
• Solhint :- Solhint is an open source project for linting Solidity code. This project provides both Security and Style Guide validations.

References: 

• consensys.github.io [1]
• en.wikipedia.org [2]
• why.cardano.org [3]
• consensys.github.io [4]
• medium.com [5]
• www.zupzup.org [6]
• docs.soliditylang.org [7]
• www.andrew.cmu.edu [8]
• arvanaghi.com [9]