Smart contracts are autonomous programs which are stored within and run on the blockchain. Users may interact with contracts by sending digital assets to addresses, which will cause instructions in the contract to be executed when the transaction is included in the next block of the blockchain. These instructions are executed by miners when adding a new block to the blockchain. They enable new kinds of distributed, trusted transactions to take place autonomously.

Smart contracts are executed by block miners and blockchain nodes within a restricted execution environment known as a virtual machine.  The virtual machine is limited to operations which involve blockchain addresses, mathematics, and metadata about the blockchain itself.  While the set of instructions is limited, smart contracts are still extremely capable programs capable of performing autonomous management of the digital assets tracked by the blockchain. For example, many distributed autonomous organizations, or DAOs, are formed using smart contracts which allow users to gain membership into the DAO, participate in investment vehicles, and even participate in shareholder votes on proposals.

Smart contracts form the core functionality of Decentralized Finance (DeFi) and Decentralized Autonomous Organizations (DAOs) through the execution of programs stored within the blockchain itself.  These programs are immutable, public, and autonomous.

Components Tested

• Contract asset handling and calculation
• Vulnerability to denial of service / lockout
• Access control
• Ability to update/replace contract
• Common smart contract vulnerabilities classes (e.g., reentrancy, integer under/overflow)
• Transaction order dependency

Common Vulnerabilities

The smart contract attack surface varies depending on the functionality present within each contract. The following is a non-exhaustive list of common smart contract vulnerabilities:

Insufficient or Improper Access Controls

Smart contracts may have access controls which limit certain functionality to specific trusted addresses. In some cases, this functionality may perform tasks such as destroying the contract, transferring or distributing digital assets, or updating the contract. If the contract is not properly limiting access to these functions, attackers may be able to take advantage of this to disable or steal assets under the management of the contract.[1]

Unchecked Return Values for Low Level Calls

Certain calls in the Solidity smart contract programming language return “false” instead of throwing exceptions when unhandled errors occur. If these function calls are not checked for errors before continuing execution, the contract may allow an attacker to create an exploitable logic condition.

Time Manipulation

Smart contracts may access the time of a generated block as a part of the metadata available to the smart contract virtual machine. Because blockchain miners in public blockchains have ultimate control over the inclusion of transactions within blocks, it is possible for a malicious miner to control this value. As a result, the transaction timestamp should not be used as a part of a sensitive operation or sequence of operations within smart contracts.

Short Address Attack

Improperly validated data entering a smart contract function via another mechanism (e.g., a web application) may contain blockchain addresses which are not of the standard length. When this data is interpreted by the virtual machine executing a contract, the data passed to functions will be padded, resulting in unexpected inputs to functions. In practice, this vulnerability is used to exploit smart contract transaction functions by abusing the padding performed by the virtual machine to send more tokens than intended.

Improper Balance Management when Interacting with Deflationary Tokens

Deflationary tokens charge a fee when tokens are transferred. If a contract is unaware of this fee when performing swaps or flash loans, the contract balance may be calculated incorrectly resulting in profit opportunities for attackers.

Reentrancy

Reentrancy attacks occur when a contract can be forced to re-enter a function it is already currently attempting to execute. If a contract performs such an operation, the first call to the function must wait for the second call to finish before proceeding while the second call to the function is executed. If a function is re-entered, the values of any variables outside of the function – the state of the contract – is still based upon the values set by the first call. This vulnerability was used to hack “The DAO” in 2016[2].

[1] https://www.parity.io/blog/a-postmortem-on-the-parity-multi-sig-library-self-destruct/

[2] https://medium.com/@zhongqiangc/smart-contract-reentrancy-thedao-f2da1d25180c