Study of Ethereum Security Vulnerabilities
We divide the security vulnerabilities in Ethereum into two broad categories – Blockchain 1.0 and Blockchain 2.0 vulnerabilities.
Blockchain 1.0 vulnerabilities includes security vulnerabilities that are present in most blockchain based systems and that Ethereum shares with it’s predecessors like Bitcoin.
Blockchain 2.0 vulnerabilities include vulnerabilities introduced in the system because of the presence of smart contracts.
Our work is concerned with the Blockchain 2.0 (Smart Contract) Vulnerabilities. However, the Blockchain 1.0 vulnerabilities are introduced for completeness.
Blockchain 1.0 Vulnerabilities
51% Attack
In proof of work, the miners try finding the nonce value to solve the given cryptographic puzzle. However, if miner(s) get control of more than 51% of the compute power in the network then they essentially control what goes into the blockchain – compromising its integrity.
Double Spending
Double spending occurs when the attacker uses the same cryptocurrency more than once. This is done by leveraging race conditions, forks in the chain, or 51% attacks. A variant of this attack is the Finney attack. Such attacks have been shown on Bitcoin.
Selfish Mining In selfish mining, a malicious miner does not publish the block immediately after solving the proof of work puzzle. Instead, reveals it only to its pool members which then work on the next block, while the other network continues working for essentially nothing. This was first demonstrated on Bitcoin, and recently on Ethereum as well.
Eclipse Attack
In eclipse attacks, the victim’s incoming and outgoing connections are taken over by attacker (using a botnet or otherwise). This gives a filtered view of the blockchain to the victim. Several other attacks like selfish mining and double spending can be launched at the victim. Such attacks have been demonstrated on Bitcoin.
BGP Hijacking Attack
The border gateway protocol (BGP) is used for handling routing information over the internet. BGP hijacking is a common attack. However in the context of public blockchains, it can be used to create unwanted delays in the network and cause monetary losses to the miners. Such attacks have been demonstrated on Bitcoin.
Private key security
Private keys are used to control the addresses in Ethereum. It is a security problem in itself to store these keys securely. As blockchain is a decentralised system, there is no way to report a stolen private key and prevent its misuse.
Blockchain 2.0 Vulnerabilities
Re-entrancy
A re-entrancy condition is when a malicious party can call a vulnerable function of the contract again before the previous call is completed: once or multiple times. This type of function is especially problematic in case of payable functions, as a vulnerable contract might be emptied by calling the payable function repeatedly. The call() function is especially vulnerable as it triggers code execution without setting a gas limit.
To avoid re-entrancy bugs, it is recommended to use transfer() and send() as they limit the code execution to 2300 gas. Also, it is advised to always do the required work (i.e. change the balances, etc.) before the external call. The DAO Attack is the most famous re-entrancy attack which lead to a loss of US$50 Million and resulted in the chain being forked into two – Ethereum and Ethereum Classic. In the example shown below from, the vulnerability arises from the fact the the user balance is not set to 0 until the very end of the function, allowing a malicious user to withdraw funds again and again.
Transaction Order Dependence (Front Running)
The order in which the transactions are picked up by miners might not be the same as the order in which they arrive. This creates a problem for contracts that rely on the state of the storage variables. Gas sent is usually important as it plays an important role in determining which transactions are picked first. A malicious transaction might be picked first, causing the original transaction to fail. This kind of race-condition vulnerability is referred to as transaction order dependence.
Overflows and Underflows
Solidity can handle up to 256 bit numbers, and therefore increasing (or decreasing) a number over (or below) the maximum (or minimum) value can result in overflows (or underflows). It is recommended to use OpenZeppelin’s SafeMath library to mitigate such attacks.
Timestamp Dependence
A lot of applications have a requirement to implement a notion of time in their applications. The most common method of implementing this is using the block.timestamp either directly or indirectly. However, a malicious miner with a significant computational power can manipulate the timestamp to get an output in his/her favour.
Forcing Ether to a Contract
Usually, when you send ether to a contract, it’s fallback function is executed. However, if the transfer of ether happens as a result of a selfdestruct() call, then the fallback is not called. Therefore, a contract’s balance should never be used in an if condition as it can be manipulated by a malicious user.
In the example below from, we observe that the payable function always reverts, therefore ‘something bad’ should not happen. However, it is possible to force ether to a contract as shown before, invalidating the balance check.
Bad Randomness
Online games and lotteries are common dApp use cases. For these applications, a common choice for the seed of the random number generator is the hash or timestamp of some block that appears in the future. This is considered secure as the future is unpredictable. However, a malicious attacker can bias the seed in his favour. Such attacks on Bitcoin have already been demonstrated.
Short Address Attack
It is an input validation bug that was discovered by the Golem Team. This allows the attacker to abuse the transfer function. The EVM automatically pads zeroes if the length of the address is less than the required length. This makes certain addresses with trailing zeroes vulnerabilities if proper sanity check is not done.
Unprotected Ether Withdrawal
Due to missing or inadequate access control mechanisms, it might be the case that anyone is able to withdraw Ether from the contract which is highly undesirable.
Authorization through tx.origin
This can be interpreted as a type of a phishing attack. In solidity, tx.origin and msg.sender are separate. The account calling a contract is defined by msg.sender. tx.origin is the original sender of the transaction, which might lead to a string of other calls. However, if tx.origin is used for authorization, and the actual owner is conned to call a malicious contract which in turn calls the victim contract, then the authorization fails.
In the example given below, the owner is set to the contract creator. However, if the contract creator is conned into calling a malicious contract which in turn calls the sendTo function, the authorization passes and the attacker is able to siphon funds from the contract.
Unprotected selfdestruct
selfdestruct kills a contract on the blockchain and send the contract balance to the specified address. The opcode SELFDESTRUCT is one of the few operations that costs negative gas as it frees up space on the blockchain. This construct is important because contracts may need to be killed if they are no longer required or if some bug is discovered. However, if this construct is put without proper protection mechanisms in place then anyone can kill the contract.
Function and Variable Visibility
Solidity has four visibility specifiers for functions and variables. However, being declared public is the most tricky from a security standpoint. If an important function like a payable function or a constructor with a wrong name is declared as public, then it can cause great monetary losses. Variable visibility does not have such drastic consequences as public variables get a public getter function.
Denial of Service
A denial of service attack from a smart contract’s perspective happens when a smart contract becomes inaccessible to its users. Common reasons include failure of external calls or gas costly programming patterns.
Call to the Unknown
Ethereum Smart Contracts can make calls to other smart contracts. If the addresses of these smart contracts may be user provided then a malicious actor can utilize improper authentication to call a malicious contract. If the address is hard-coded, then it does not give the flexibility to update the contract to be called over time.
Another issue is a special method called delegatecall. This makes the dynamically loaded code run in the caller’s context. Therefore, if a delegatecall is made to a malicious contract, they can change storage values and potentially drain all funds from the contract.
Exception Handling
Like in any object oriented programming language, exceptions may arise due to many reasons. These must be properly handled at the programmer level. Also, lower level calls do not throw an exception. They simple return a false value which needs to be checked and the exception should be handled manually.
Vulnerabilities introduced by Ethereum updates
Early in 2019, it was discovered by Chain Security that Ethereum’s Constantinople update had an effect that might have made some smart contracts vulnerable to a re-entrancy bug. Such updates cannot be predicted by smart contract developers and the Ethereum Foundation ultimately delayed rolling out the update.
New Taxonomy for Ethereum Smart Contract Vulnerabilities
Existing Taxonomies and the need for a new Taxonomy
The first taxonomy for smart contract vulnerabilities was given by Atzei et. al. . They divided the vulnerabilities into three broad categories based on their source. This included Solidity, EVM and blockchain. The vulnerabilities discussed did not give a holistic picture as it did not even contain common vulnerabilities like access control, function visibility, and transaction order dependence. These vulnerabilities have been proven to be quite disastrous as shown in the infamous Parity bug. Also, it was felt that only one level of hierarchy was less for proper analysis. Dika in his Master’s Thesis addressed many of the shortcomings of the Atzei taxonomy. More vulnerability categories were added and an associated severity level was also given for each vulnerability. However, the single level hierarchy was carried forward from the previous work. Also, we noticed that some vulnerability classes do not pose an immediate security risk. For example, use of tx.origin was labelled as a vulnerability. However, just using tx.origin does not cause a security breach. The problem occurs when it is used for authorization. Similarly, blockhash may cause a security vulnerability if used as a source of randomness. However just using it in the code does not make a contract vulnerable.
Because of these issues in the existing work, we felt that there was a need for an improved taxonomy that was more hierarchical – for better analysis and understanding. Also, issues of improper vulnerability naming and incomplete vulnerability listing also needed refinement.
A New Taxonomy of Ethereum Smart Contract Vulnerabilities
Based on our extensive research and study of Ethereum smart contract vulnerabilities, we have come up with a new and unified vulnerability taxonomy as shown in Table 3.3.
With this new taxonomy, we try to overcome the problems in the existing literature. We try to cover almost all the security vulnerabilities that have been reported. Since, these are usually reported under different names, a security analyst would find that he/she is able to put any existing vulnerability he/she encounters under one of the many categories we have created. Also, unlike previous works, we have tried to eliminate any redundancies and/or incorrect categorizations. The taxonomy is hierarchical and therefore analysis using this taxonomy would give the security researcher better insights into the root security issues in smart contracts.
The severity level is colour coded with red being high, orange being medium and green being low. The severity level has been decided taking into consideration our research, the existing literature and the OWASP Risk Rating Methodology.
OWASP Risk Rating Methodology
We use the OWASP Risk Rating Methodology helps to determine the severity level of any vulnerability. The risk is defined as follows – 1
Risk = Impact x Likelihood
Using this equation, the severity level is determined by using the Table 3.2. In this work we only utilize the severity levels from Low to High.
This article has been published from the source link without modifications to the text. Only the headline has been changed.
[ad_2]
Source link
