Penetration Test Report (Hacken): GosseDeFi hackenAudit

SMART CONTRACT CODE
REVIEW AND SECURITY
ANALYSIS REPORT
Customer: GooseDeFi
Date: February 21st, 2021
This document may contain confidential information about IT systems and the
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 a
decision of the Customer.
Document
Name Smart Contract Code Review and Security Analysis Report for GooseDeFi.
Approved by Andrew Matiukhin | CTO Hacken OU
Type Token, Governance, TimeLock, Defi
Platform Ethereum / Solidity
Methods Architecture Review, Functional Testing, Computer-Aided Verification, Manual
Review
Repository
Commit
Deployed
contract
Timeline 18 FEB 2021 – 21 FEB 2021
Changelog 21 FEB 2021 – INITIAL AUDIT
Table of contents
Introduction .......................................................................................................................... 4
Scope .................................................................................................................................... 4
Executive Summary ............................................................................................................... 5
Severity Definitions ............................................................................................................... 7
AS-IS overview ...................................................................................................................... 8
Conclusion .......................................................................................................................... 24
Disclaimers .......................................................................................................................... 25
Introduction
Hacken OÜ (Consultant) was contracted by GooseDeFi (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 February 18th, 2021 – February 21st, 2021.
Scope
The scope of the project is smart contracts in the repository:
Contract deployment address:
Repository
File:
EggToken.sol 0xF952Fc3ca7325Cc27D15885d37117676d25BfdA6
MasterChef.sol 0xe70E9185F5ea7Ba3C5d63705784D8563017f2E57
Timelock.sol 0x2Ef488DE034567e9B8D312928fD52812A242aB3A
We have scanned this smart contract for commonly known and more specific
vulnerabilities. Here are some of the commonly known vulnerabilities that are
considered:
Category Check Item
Code review ▪ Reentrancy
▪ Ownership Takeover
▪ Timestamp Dependence
▪ Gas Limit and Loops
▪ DoS with (Unexpected) Throw
▪ DoS with Block Gas Limit
▪ Transaction-Ordering Dependence
▪ Style guide violation
▪ Costly Loop
▪ ERC20 API violation
▪ Unchecked external call
▪ Unchecked math
▪ Unsafe type inference
▪ Implicit visibility level
▪ Deployment Consistency
▪ Repository Consistency
▪ Data Consistency
Functional review ▪ Business Logics Review
▪ Functionality Checks
▪ Access Control & Authorization
▪ Escrow manipulation
▪ Token Supply manipulation
▪ Assets integrity
▪ User Balances manipulation
▪ Kill-Switch Mechanism
▪ Operation Trails & Event Generation
Executive Summary
According to the assessment, the Customer's smart contracts are well-secured.
Insecure Poor secured Secured Well-secured
You are
Our team performed an anahlyesries of code functionality, manual audit, and
automated checks with Mythril and Slither. All issues found during automated
analysis were manually reviewed, and important vulnerabilities are presented in
the Audit overview section. A general overview is presented in AS-IS section, and
all found issues can be found in the Audit overview section.
Security engineers found 2 medium, 1 informational issue during the audit.
Notice: the audit scope is limited and not include all files in the repository.
Though, reviewed contracts are secure, we may not guarantee secureness of
contracts that are not in the scope.
Graph 1. The distribution of vulnerabilities after the first review.
Informational
25%
Medium
75%
Medium Informational
Severity Definitions
Risk Level Description
Critical vulnerabilities are usually straightforward to exploit and can
Critical
lead to assets loss or data manipulations.
High-level vulnerabilities are difficult to exploit; however, they also
High have a significant impact on smart contract execution, e.g., public
access to crucial functions
Medium-level vulnerabilities are important to fix; however, they
Medium
can't lead to assets loss or data manipulations.
Low-level vulnerabilities are mostly related to outdated, unused,
Low etc. code snippets that can't have a significant impact on
execution
Lowest / Code Lowest-level vulnerabilities, code style violations, and info
Style / Best statements can't affect smart contract execution and can be
Practice ignored.
AS-IS overview
Timelock.sol
Description
Timelock queues and executes transactions.
Imports
Timelock has following imports:
• SafeMath.sol – from the OpenZeppelin.
Inheritance
Timelock does not inherit anything.
Usages
Timelock contract has following usages:
• SafeMath for uint.
Structs
Timelock contract has no data structures.
Enums
Timelock contract has no enums.
Events
Timelock contract has following events:
• event NewAdmin(address indexed newAdmin);
• event NewPendingAdmin(address indexed newPendingAdmin);
• event NewDelay(uint indexed newDelay);
• event CancelTransaction(bytes32 indexed txHash, address indexed target,
uint value, string signature, bytes data, uint eta);
• event ExecuteTransaction(bytes32 indexed txHash, address indexed
target, uint value, string signature, bytes data, uint eta);
• event QueueTransaction(bytes32 indexed txHash, address indexed
target, uint value, string signature, bytes data, uint eta);
Modifiers
Timelock has no modifiers.
Fields
Timelock contract has following fields and constants:
• uint public constant GRACE_PERIOD = 14 days;
• uint public constant MINIMUM_DELAY = 6 hours;
• uint public constant MAXIMUM_DELAY = 30 days;
• address public admin – an admin address.
• address public pendingAdmin – a pending admin.
• uint public delay – delay between a transaction queueing and execution.
• mapping (bytes32 => bool) public queuedTransactions – queued
transactions.
Functions
Timelock has following public functions:
• constructor
Description
Inits the contract and sets default parameters.
Visibility
public
Input parameters
o address admin_ - admin address.
o uint delay_ - delay between a transaction queuing and execution.
Constraints
o A `delay_` value should be between DELAY and MAXIMUM_DELAY.
Events emit
None
Output
None
• receive
Description
Allows ETH transfers.
• setDelay
Description
Sets a delay.
Visibility
public
Input parameters
o uint delay_ - delay between a transaction queuing and execution.
Constraints
o A message sender should be the contract itself.
o A `delay_` value should be between DELAY and MAXIMUM_DELAY.
Events emit
Emits the `NewDelay` event.
Output
None
• acceptAdmin
Description
Accept the admin permissions.
Visibility
public
Input parameters
None
Constraints
o A message sender should be a pending admin.
Events emit
Emits the `NewAdmin` event.
Output
None
• setPendingAdmin
Description
Accept the admin permissions.
Visibility
public
Input parameters
o address pendingAdmin_ - a pending admin address.
Constraints
o A message sender should be the contract itself.
Events emit
Emits the `NewPendingAdmin` event.
Output
None
• queueTransaction
Description
Add a new transaction to the queue.
Visibility
public
Input parameters
o address target – a tx target.
o uint value – a tx value.
o string memory signature – a method signature.
o bytes memory data – a tx data.
o uint eta – a minimum delay between a tx queuing and execution.
Constraints
o A message sender should be admin.
o `eta` should be more than current time pl