Vulnerabilities in Smart Contracts

Smart Contracts are a very new technology, and there are several common vulnerabilities that make them easy to hack. As soon as mass adoption starts rolling out, this will mean disaster! It will lead to a few big hacks and everyone will be afraid to use Smart Contracts, leading them to be scrapped altogether.

So, we must educate the public on how vulnerable they really are at the moment and build a secure method of testing and creating Smart Contracts & the Audit of Smart Contracts is a must, before the technology is undercut by its own flaws. Audit of Smart Contract is

learn : what is a smart contract audit

Smart contracts have numerous reasons for security issues

• Plenty of smart contracts have issues with financial assets
• Once smart contracts are published with an error it’s not changeable due to the immutable nature of blockchain technology
• Transaction of defective smart contract in blockchain state cannot be rolled back

List of a common security issues

Unknow code indirect execution: Smart contracts have fallback functionality that increases the possibility of indirect execution. Here is some reason this function can be called.

1. Using ABI to call another contract function. If the signature string passed for encoding but has a typo or a function doesn’t have that signature in this process the fallback function will be commanded
2. A fallback function called out when a transaction deposit to another contract
3. Using API to call another contract function, Declaring the interface of the contract and the meanwhile developer made some mistakes ( For example, combining the types of the parameter)

Miscalculation of the output token amount: Money depicted in Token or Eth value is common these days a lot of new Defi smart contracts are facing this issue. Such common errors are

1. When dialing with such a token there is a high chance of incorrect handling.
2. The major reason for accuracy loss during fees calculation is the incorrect order of operation.

Interface issues: Rubixi smart contract is a good example, Rubixi was a Ponzi game, that had the feature that the owner could transfer his to himself in the financial pyramid. Basically, the constructor of the contract is the owner. The same logic is used in Rubixi smart contract. In the version of solidity 0.4.22 constructors were recognized and defined with the same name as the contract name.

Order Execution Dependency: Variables value of the smart contract determines its state. Which can be changed by running the function. Transaction of ETH or ERC-20 token transfer is the same translation as calling the function of the contract. After the compilation of new block creation, those transactions can be finalized by the network.

Time Component: Most of the logic smart contracts are dependent on time. The context transaction is the only available time for the smart contract. When you send a transaction, you basically ask the network to add it to the next block. The timestamp of a transaction, in turn, is equal to the label of the block in which it is included. Thus, consistency with the state of a smart contract is achieved.

Use blockhash function: The blockhash function is a very convenient tool that allows you to check on which block your contract will be included in the blockchain. Its most obvious application is to set a certain time after which an event occurs. For example, you can determine that you can withdraw money from your contract only after a certain number of blocks have passed since its activation.

Wrong-handled exceptions: One of the most common issues that developers face while coding in Solidity is handling exceptions. An exception can be thrown at any time, and they are triggered by a variety of different situations. However, the way these exceptions are handled is not always the same.

Exception handling is based on interactions between contracts. Thus, contracts are vulnerable to attack from malicious users, if these exceptions are not handled properly, transactions will be rolled back.

Re-entrancy attacks: these exploits take advantage of the fact that when a transaction executes a function on another contract, it does not wait for the execution to complete before returning control back to its own codebase. This allows for some interesting attack vectors where transactions can be sent from one contract to another repeatedly until there’s no balance left in either account (known as an “infinite loop”).

This was exploited by MEW wallet users when they tried withdrawing ether from their accounts into new ones via MyEtherWallet’s interface — they had mistakenly entered their private key as a value instead of an address, which meant that all transactions were being executed twice instead of once each time someone made one (because they thought they could withdraw twice as much).

Incorrect work with ERC20 token: Well, we’ve all been there. You’re excited about a new project, you’re in love with the idea, and you’re ready to bring it to life. And then you start to get going, and you realize that your last project looks a lot like this one. And you think “If I just change this thing here and this thing there, it’ll be totally different!”

Well… not quite.

The ERC20 token is well-known, but it’s also overused in modern protocols. In most cases, it’s completely applicable, and its functionality is enough for correct financial operations. But still, there are cases where a custom implementation of the ERC20 standard might make sense.

That creates a risk: a place for discrepancies between your custom token implementation and the actual ERC20 standard — things like a missing return value in the transfer() function. It’s easy to miss these tiny changes during testing — but in production, they can lead to things like stuck funds and blocked contracts.

Conclusion

Overall, smart contracts open the door for disruptive possibilities. But to reach that potential, a cautious approach must be taken as one incorrect line of code could lead to a serious setback. The number and severity of issues discovered in Ethereum smart contracts have increased the amount of attention and knowledge required from both developers and auditors. That being said, the ability to store information in blockchain-based storage for public, decentralized applications opens up the doors for countless use cases that were previously not possible.