Penetration Test Report (Hacken): Statera SC Audit Report

SMART CONTRACT CODE
REVIEW AND SECURITY
ANALYSIS REPORT
Customer: Statera
Date: June 18, 2020
Platform: Ethereum
Language: Solidity
2
This document may contain confidential information about IT
systems and intellectual property of the customer as well
as information about potential vulnerabilities and methods
of their exploitation.
The report containing confidential information can be used
internally by the customer or it can be disclosed publicly
after all vulnerabilities fixed - upon decision of customer.
Document
Smart Contract Code Review and Security Analysis
Name
Report for Statera
Platform Ethereum / Solidity
Repository https://github.com/StateraProject/statera-token/tree/master/contracts
Commit 611d2b5c2675d824c233400f732d172d3cc14738
Branch master
Date 18.06.2020
3
Table of contents
Document ..................................................... 2
Table of contents ............................................. 3
Introduction ................................................. 4
Scope ........................................................ 4
Executive Summary ............................................. 5
Severity Definitions .......................................... 6
AS-IS overview ............................................... 6
Audit overview ............................................... 9
Conclusion .................................................. 11
Disclaimers ................................................. 12
4
Introduction
Hacken OÜ (Consultant) was contracted by Statera (Customer) to
conduct a Smart Contract Code Review and Security Analysis. This
report presents the findings of the security assessment of
Customer`s smart contract and its code review conducted between
June 17th, 2020 – June 18th, 2020.
Scope
The scope of the project are smart contracts within the
repository:
Repository –
https://github.com/StateraProject/statera-token/tree/master/contracts
Commit – 611d2b5c2675d824c233400f732d172d3cc14738
Branch - master
We have scanned this smart contract for commonly known and more
specific vulnerabilities. Here are some of the commonly known
vulnerabilities that are considered (the full list includes them
but is not limited to them):
• Reentrancy
• Timestamp Dependence
• Gas Limit and Loops
• DoS with (Unexpected) Throw
• DoS with Block Gas Limit
• Transaction-Ordering Dependence
• Style guide violation
• Transfer forwards all gas
• ERC20 API violation
• Compiler version not fixed
• Unchecked external call - Unchecked math
• Unsafe type inference
• Implicit visibility level
5
Executive Summary
According to the assessment, Customer`s smart contracts are
secured.
Insecure Poor secured Secured Well-secured
You are here
Our team performed analysis of code functionality, manual audit
and automated checks with Mythril and Slither. All issues found
during automated analysis were manually reviewed and applicable
vulnerabilities are presented in Audit overview section. General
overview is presented in AS-IS section and all found issues can
be found in Audit overview section.
We found 7 low and 3 best practice issues in smart contract code.
Graph 1. The distribution of vulnerabilities.
Best Practice
30%
Low
70%
Low Best Practice
6
Severity Definitions
Risk Level Description
Critical vulnerabilities are usually straightforward to
Critical
exploit and can lead to tokens lose etc.
High-level vulnerabilities are difficult to exploit;
however, they also have significant impact on smart
High
contract execution, e.g. public access to crucial
functions
Medium-level vulnerabilities are important to fix;
Medium
however, they can’t lead to tokens lose
Low-level vulnerabilities are mostly related to
Low outdated, unused etc. code snippets, that can’t have
significant impact on execution
Lowest / Code Lowest-level vulnerabilities, code style violations
Style / Best and info statements can’t affect smart contract
Practice execution and can be ignored.
AS-IS overview
IERC20 is the standard ERC20 interface.
SafeMath library is standard library for math operations that
prevents integer overflows and underflows.
ERC20Detailed is standard IERC20 implementation with extra token
parameters.
Contract Statera is ERC20Detailed.
Contract Statera defines following public parameters:
• private mapping (address => uint256) _balances
• private mapping (address => mapping (address => uint256))
_allowed
• string tokenName is set to "Statera"
7
• string tokenSymbol is set to "STA"
• uint8 tokenDecimals is set to 18
• uint256 _totalSupply is set to[PII_REDACTED][PII_REDACTED]0000000
• uint256 basePercent is set to 100
Contract Statera has 14 functions:
• constructor – calls ERC20Detailed constructor and issues
total supply to caller
• totalSupply – public view function that returns token total
supply
• balanceOf – public view function that returns the balance of
the account
• allowance – public view function that returns the allowance
of the spender account for specified address
• cut – public view function that returns the commission to be
burned for the value
• transfer – public function that transfers tokens from caller
to receiver
• approve – public function that approves transfer of token
for specified spender
• transferFrom – public function that transfers from address
to specified receiver by approved caller
8
• upAllowance – public function that increases allowance for
specified account
• downAllowance – public function that transfers from address
to specified receiver by approved caller
• _issue – internal function that mints tokens to account
• destroy – external function that burns tokens
• _destroy – internal function that burns tokens
• destroyFrom – external function that burns tokens from
specified address
9
Audit overview
Critical
No critical issues were found.
High
No high issues were found.
Medium
No medium issues were found.
Low
1. No visibility specified for tokenName, tokenSymbol,
tokenDecimals and _totalSupply, thus, all of these parameters
will be public. However, parameters starting with
underscore(_totalSupply) should be private.
2. No solidity version is specified in the pragma. It’s
recommended lock the pragma with latest stable version of
the solidity.
3. Constructor is payable, however, if deployer send any Ether
to the contract – it’ll be forever locked. It’s recommended
to remove payable from constructor.
4. When 0[PII_REDACTED]00000001 token is transferred – it’s not
being transferred but being burned – receiver gets 0.
5. Poor naming for following functions:
a. upAllowance – should be increaseAllowance
b. downAllowance – should be decreaseAllowance
10
c. _issue – should be _mint
d. destroy – should be burn
e. _destroy – should be _burn
f. destroyFrom – should be burnFrom
g. _allowed – should be _allowances
The issue may lead to integration issues, for example, with
other smart contracts that expect upAllowance function to be
called increaseAllowance.
6. The code is not fully covered with documentation. The absence
of documentation may cause differences between
implementation and expected behavior of smart contracts.
Documentation should be presented for all smart contract’s
code.
7. Code is not covered with any unit tests. It increases the
risk of the unexpected flaws in the smart contracts. It is
recommended to have 100% code coverage with automated tests.
Lowest / Code style / Best Practice
8. Outdated version of SafeMath is used. assert is outdated and
not recommended to use within the code. It’s recommended to
update SafeMath to newer version.
9. It’s no needed to store in storage tokenName, tokenSymbol
and tokenDecimals that are used only once in code – in
constructor.
11
10. Following checks can be omitted:
a. Line 36
b. Line 61
c. Line 107
Conclusion
Smart contracts within the scope was manually reviewed and
analyzed with static analysis tools. For the contract high level
description of functionality was presented in As-is overview
section of the report.
Audit report contains all found security vulnerabilities and other
issues in the