As a result of the analysis of the past contract hacks, and in particular the recent $12,400,000 hack of VultSX, it became obvious that the activity of security auditors does not sufficiently reduce the damage from the security vulnerabilities of smart-contracts.
As security auditors, we must not only check the code of contracts, but also make sure that the developer of the contract adheres to the best known security practices and the developer of the contract is aware of all the known risks associated with the use of the audited contract.
2. Types of contracts
There are two main types of smart-contracts aimed by hackers:
Contracts that store funds (on-chain exchanges, wallets, ICO contracts, yield farming contracts, gambling DAPPs).
Contracts that govern the logic of funds (mostly token contracts and NFTs)
A hacker can simply "withdraw" the funds from a storage contract in order to get profit. A hacker should somehow manipulate the logic of a fund-governing contract in order to get profit (i.e. transfer tokens on behalf of some user or mint new tokens to sell them on exchange).
Special attention needs to be paid to storage contracts as these are at a greater risk category. It would be helpful if the funds in a storage contract were insured.
[x] The contract should be open-source. The more people are free to view the contract code, the better.
[x] The contract should pass a bug bounty. It is strongly recommended that the contract undergoes a bug bounty after the completion of the security audit if there were no medium or higher severity issues discovered.
[x] Public testing. The contract must be deployed at testnet first. Users must be allowed to interact with the test version of the contract for a period of at least two weeks.
[x] Automated anomaly detection systems. This is especially relevant for contracts that are intended to hold funds. A simple anomaly detection algorithm must be implemented to detect behavior that is atypical compared to normal for this contract. For instance the contract must halt deposits in case a large amount is being withdrawn in short period of time until the owner or the community of the contract approves further operationing.
[x] [Owned contracts only] Multisig owner account. The owner account is at risk of private keys being stolen. It is recommended that steps be taken to prevent any harm that such an accident may cause.
Platform-specific issues (Ethereum-based)
[x] Stnadard ERC20-related issues. It is known that every contract can potentially receive unintended ERC20-token deposit without the ability to reject it even if the contract is not intended to receive or hold tokens. As the result it is recommended to implement a function that will allow to extract any arbitrary number of tokens from the contract.
[x] Crosschain address collisions. Ethereum address is valid for multiple chains: ETH, ETC, CLO etc. It is possible that a transaction can be sent to the address of your contract at another chain (as a result of user mistake or some software fault). It is recommended that you deploy a "mock contract" that would allow you to withdraw any tokens from that address or prevent any funds deposits. Note that you can reject transactions of native token deposited but you can not reject the deposits of ERC20 tokens. You can use this source code as a mock contract: extractor contract source code. The address of a new contract deployed using CREATE (0xf0) opcode is assigned following this scheme keccak256(rlp([sender, nonce])). Therefore you need to use the same address that was originally used at the main chain to deploy the mock contract at a transaction with the nonce that matches that on the original chain. Example: If you have deployed your main contract with address 0x010101 at your 2021th transaction then you need to increase your nonce of 0x010101 address to 2020 at the chain where your mock contract will be deployed. Then you can deploy your mock contract with your 2021th transaction and it will receive the same address as your mainnet contract.
Platform-specific issues (EOS)
[x] on_notify implementation.on_notify event handlers can be triggered by any arbitrary contract to forward a carbon copy of a transaction to the recipient. Make sure to check the origin of the on_notify event.
4. Security Audit Report template extension
Conclusion must be moved from paragraph 4 to paragraph 5 ("4. Conclusion" -> "5. Conclusion").
Paragraph 4 must now be "4. Security practices".
Paragraph "4. Security practices" must contain the following checklist relevant for the auditable contract. If one of the points relevant for the contract is checked then it can be left without explanation. Otherwise if one of the points relevant for the audited contract is NOT fulfilled then the explanation of this point from paragraph 3. Security practices to follow (described above) must be included:
[x] [relevant for any contract / checked if the contract is open-sourced] Open-source contact.
[x] [relevant for any contract / always checked as the bug bounty recommendation can be fulfilled AFTER the completion of this audit] The contract should pass a bug bounty.
[x] [relevant for any contract / checked if the developer announced the public testing of the contract and the contract has a working deployment at public testnet] Public testing.
[x] [relevant for contracts that are intended to operate with funds OR hold funds / checked if the automated anomaly detection system is implemented in the contract] Automated anomaly detection systems.
[x] [relevant for owned contracts / checked if the contract is deployed and the owner address is a multisig] Multisig owner account.
[x] [relevant for EVM contracts that are not intended to hold ERC20, ERC777, ERC721, ERC 677 tokens / checked if the contract implements ERC20-rescue function] Stnadard ERC20-related issues.
[x] [relevant for EVM contracts intended to be deployed on Ehereum-based chains supporting hex-addresses / checked if the contract is deployed and the mock contracts are deployed on major alternative chains] Crosschain address collisions.
[x] [relevant for EOS contracts only / checked if on_notify event handlers implement the required checks] on_notify implementation.
1. Preamble
As a result of the analysis of the past contract hacks, and in particular the recent $12,400,000 hack of VultSX, it became obvious that the activity of security auditors does not sufficiently reduce the damage from the security vulnerabilities of smart-contracts.
As security auditors, we must not only check the code of contracts, but also make sure that the developer of the contract adheres to the best known security practices and the developer of the contract is aware of all the known risks associated with the use of the audited contract.
2. Types of contracts
There are two main types of smart-contracts aimed by hackers:
A hacker can simply "withdraw" the funds from a storage contract in order to get profit. A hacker should somehow manipulate the logic of a fund-governing contract in order to get profit (i.e. transfer tokens on behalf of some user or mint new tokens to sell them on exchange).
Special attention needs to be paid to storage contracts as these are at a greater risk category. It would be helpful if the funds in a storage contract were insured.
3. Security practices to follow
Read DAPP security standards for reference.
Platform-specific issues (Ethereum-based)
CREATE (0xf0)opcode is assigned following this schemekeccak256(rlp([sender, nonce])). Therefore you need to use the same address that was originally used at the main chain to deploy the mock contract at a transaction with thenoncethat matches that on the original chain. Example: If you have deployed your main contract with address 0x010101 at your 2021th transaction then you need to increase your nonce of 0x010101 address to 2020 at the chain where your mock contract will be deployed. Then you can deploy your mock contract with your 2021th transaction and it will receive the same address as your mainnet contract.Platform-specific issues (EOS)
on_notifyevent handlers can be triggered by any arbitrary contract to forward a carbon copy of a transaction to the recipient. Make sure to check the origin of theon_notifyevent.4. Security Audit Report template extension
Conclusion must be moved from paragraph 4 to paragraph 5 ("4. Conclusion" -> "5. Conclusion").
Paragraph 4 must now be "4. Security practices".
Paragraph "4. Security practices" must contain the following checklist relevant for the auditable contract. If one of the points relevant for the contract is checked then it can be left without explanation. Otherwise if one of the points relevant for the audited contract is NOT fulfilled then the explanation of this point from paragraph 3. Security practices to follow (described above) must be included:
owneraddress is a multisig] Multisig owner account.See a new ETH_audit_report_example.md.