Blockchain is on boom now-a-days, everybody hoping to relocate their services using this outstanding technology. various fintech start-ups are using blockchain architecture to provide an innovative solution of any complex real time problem. In my past blog composed on subject “Thinking blockchain secure could be a dangerous mindset”, I’ve given a few instances of how the most perfect innovation on the planet can have flaws or imperfections, taking ahead to the previous article my write-up covers the top blockchain vulnerabilities. In this article, I’m going to focus on Solidity that is an object-oriented programming language for writing smart contracts. It is used for implementing smart contracts on various blockchain platforms.
In its early stage of development, Solidity has been adopted and is used to compile the byte-code in many Ethereum smart contracts we see today. With this post, I would like to provide detail of the past mistakes that have been made by Solidity developers in an effort to prevent future development from repeating history.
Here’re few previous hacks:
1. Overflows & Underflow: In simple language, an overflow is when a number gets incremented above its maximum value. Likewise, Underflow occurs when units decremented past their limit. Solidity can handle up to 256-bit numbers (up to 2²⁵⁶-1), so incrementing by 1 would result into 0.
Let’s understand it with a real time example, most of us know about the ‘odometer’ of a car but many of us don’t know about its mechanism. Below is a normal Odometer, which calculates the distance of your vehicle has traveled. Odometer has a limit of counting which is from 000000 – 999999. when you cross the limit of 999999 km then your odometer will revert back to 000000.
Real-World Examples: PoWHC and Batch Transfer Overflow (CVE-2018–10299), A 4chan group has built a ponzi scheme on Ethereum, written in Solidity. They called it the Proof of Weak Hands Coin (PoWHC). Unfortunately, it seems that the author(s) of the contract hadn’t seen over/under flows before and consequently, 866 ether was liberated from its contract.
2. Visibility & delegatecall: Public call functions can be considered under the visibility; the visibility determines whether a function can be called externally by
users, by other derived contracts, only internally or only externally. In solidity, Functions have to be specified as being external, public, internal, private. functions default to public allowing users to call them externally. Using such visibility specifiers incorrectly can lead a smart contract to be vulnerable by many flaws.
Referring to the solidity document, Delegatecall is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and msg.sender and msg.value do not change their values.
It specifies that, a contract can dynamically load code from a different address at run-time. Storage, current address and balance still refer to the calling contract, only the code is taken from the called address.
Real world example: Most of us have heard about the Parity hack that involved the combination of both attacks specified above.
3. Reentrancy attacks: It’s a feature in Ethereum smart contract which allow it to call and use the code of other external contracts, the operation of calling external contract, or sending ether to a contract require an external call to be submitted. while sending the ether, these external calls can be hijacked by attacker and thy can force the contract to execute the further code though a fallback function. It can help the attacker to re-enter the contract.
Real world example: This is how the DAO hack was executed in 2016.
4. External Contract Referencing: Re-usability of code & ability to interact with contracts already deployed on the network is one of the benefits with Ethereum. As a result, many contracts reference external contracts and in general operation use external message calls to interact with these contracts. These external message calls make the malicious actors to perform some attacks.
In solidity, any address can be utilized as a contract inadvertent of the code at the address represents the contract type being cast. This can be dangerous, especially when the writer of the code is hiding something malicious into it.
Real world example: Several recent honey pots have been released on the main net. The user of Smart contract doesn’t know about the accuracy of code or whether it is containing any malicious file or piece of code.
5. Denial of service: Every reader would be familiar with DOS attack, consists of attacks where users can leave the contract inoperable for a small period of time, or in some cases, permanently.
Real world example: There was a ponzi scheme called GovernMental, that accumulated quite a large amount of ether. Unfortunately, it was susceptible to the DOS attack.
These are few blockchain vulnerabilities while, there are many other ways to breach Solidity. Next part would cover other blockchain vulnerabilities.
