Information security specialists HackControl explained how to secure systems and applications, and discussed the main vulnerabilities of smart contracts and blockchain projects.
Researchers noted the ineffectiveness of code scanners:
- Code scanners are able to detect only the most primitive programming errors and do not replace a full audit and refactoring.
- Nearly all automated online auditing systems for smart contracts are nothing more than regular-expression processors that search for template vulnerabilities from their own vulnerability database.
- Auditors who offer simply checking the code with a scanner usually omit that such work takes only 10% of the time, and 90% is spent on locating and verifying vulnerabilities, which is the greatest value of an audit.
Among the most common smart-contract vulnerabilities, researchers highlighted:
- Reentrancy. The contract is designed so that the same copy of its instructions in memory can be used simultaneously by several users or processes. A user may initiate multiple transactions and potentially exceed their account balance, harming the project.
- Timestamp Dependence. Miners may slightly adjust the block timestamp. The number of blocks and the average time to mine can be used to gauge timing, but this is not a reliable method, as the retrieval time is variable.
- Gas Limit and Loops. Each block has an upper bound on the amount of gas that can be spent for performing computations. If the spent gas exceeds the limit, the transaction will not go through. This opens up exploitation of several denial-of-service vectors. Also, improper handling of gas can lead to infinite loops.
HackControl also outlined common DoS and DDoS attacks:
- Transaction-Ordering Dependence. A miner can be an attacker:
“When you buy an item at the stated price, you expect to pay that price, but a fraudster may change it before the transaction completes. That fraudster could be a miner,” the specialists explained.
- Byte array vulnerability (byte array vulnerability). A byte array is very slow and costly, affecting performance. Such an array can be easily overwhelmed by DDoS by sending it a large number of requests.
- ERC API violation. ERC-20 is the standard API for token implementation. Exchanges and third parties may face difficulties integrating a token that does not conform to it.
- Unchecked external calls / unchecked math. One of the main dangers of calling external contracts is that they can hijack the control flow and alter data, as the Solidity language is prone to integer overflow and loss of precision. Overflow can lead to unintended consequences and potential loss of funds if used by a malicious account.
- Malicious libraries. Using unvetted/non-standard libraries is inherently unsafe. It’s also important to use open-source libraries.
- Unsafe type inference. Implicitly determining variable types leads to numerous coding errors. The resulting value often falls outside the bounds of the declared type.
“It’s very helpful if the compiler tells you about this; otherwise—it’s a big bang, a buffer overflow, and a denial of service,” the specialists noted.
- Implicit visibility level. Visibility levels in smart contracts are public by default. You must explicitly define the visibility of functions and interfaces to avoid confusion and unauthorized access.
HackControl recommended a thorough review, testing, and validation of the smart-contract code, regardless of its length or complexity. The audit should ideally occur after refactoring — the auditor should be the last to make changes.
For a practical demonstration of potential vulnerabilities, specialists examined the smart contract of the Yggdrasil project. It contained several flaws:
Issue 1. “Everyone forgets about the releaser”
If the recipient account marked as releaser is the true condition but does not have the IReleaser interface, it should always be cancelled, and its release will not complete.
“In another client’s case, a similar error led after the ICO to the realization that no one had audited the smart contract and that any ETH holder could mint a token together with the owner,” HackControl explained.
Issue 2. safeTransfer instead of Transfer
TokenSplitter: 451 should use safeTransfer from the SafeERC20 library.
“Things change, and the developer likely missed a deprecated function by accident. Essentially, the problem is solved by using another library,” HackControl noted.
All found errors have been fixed.
And not by smart contracts alone…
A smart-contract audit is important, but do not forget about other applications and IT systems, the experts say. They advise regular checks of:
- the main website and the user’s personal account;
- the online payment system;
- the API;
- the gateway for interacting with external vendors;
- the mobile application;
- the company’s internal network.
Audit of only the smart contract without full testing is less effective, because the entire project as a whole must be protected, not just a part of it, HackControl concluded.
Subscribe to ForkLog news on Telegram: ForkLog Feed — the full news feed, ForkLog — the latest news and polls.