EthereumCommonwealth / Auditing

Ethereum Commonwealth Security Department conducted over 400 security audits since 2018. Not even a single contract that we audited was hacked. You can access our audit reports in the ISSUES of this repo. We are accepting new audit requests.
https://audits.callisto.network/
GNU General Public License v3.0
132 stars 34 forks source link

KINGS GLOBAL #279

Closed carlossampol closed 5 years ago

carlossampol commented 5 years ago

Audit request

KINGS GLOBAL is an Erc20 token use for Charity, Welfare, Shopping, Social, Media gallery for payment and royalty reward within the community and entire crypto space.

Source code

https://etherscan.io/address/0xfda1f5278b9aa923b5e581565d599810c78c71f5#contracts

Disclosure policy

Kingsglobaltoken2019@gmail.com

Platform

Ethereum

Number of lines:

81

MrCrambo commented 5 years ago

Auditing time 1 day

yuriy77k commented 5 years ago

@MrCrambo assigned

danbogd commented 5 years ago

Auditing time 2 days.

ghost commented 5 years ago

Estimated time 2 days

yuriy77k commented 5 years ago

@danbogd @codeblcks assigned

danbogd commented 5 years ago

My report is finished.

yuriy77k commented 5 years ago

@codeblcks did you finish audit?

yuriy77k commented 5 years ago

@codeblcks removed from this audit. Another auditor can take this contract for audit.

gorbunovperm commented 5 years ago

Estimated auditing time is 1 day.

gorbunovperm commented 5 years ago

My report is finished.

yuriy77k commented 5 years ago

@gorbunovperm assigned

yuriy77k commented 5 years ago

KINGS GLOBAL Security Audit Report

1. Summary

KINGS GLOBAL smart contract security audit report performed by Callisto Security Audit Department

KINGS GLOBAL is an Erc20 token use for Charity, Welfare, Shopping, Social, Media gallery for payment and royalty reward within the community and entire crypto space.

2. In scope

https://etherscan.io/address/0xfda1f5278b9aa923b5e581565d599810c78c71f5#contracts

3. Findings

In total, 5 issues were reported including:

No critical security issues were found.

3.1. ERC20 Compliance: false instead of throw

Severity: medium

Description

From ERC-20 specification:

The function SHOULD throw if the _from account balance does not have enough tokens to spend.

But in this implementation it just returns false. This can lead to serious consequences. Because checking the return value of this function is rare.

Code snippet


function transfer(address _to, uint256 _value) returns (bool success) {

        if (balances[msg.sender] >= _value && _value > 0) {
            balances[msg.sender] -= _value;
            balances[_to] += _value;
            Transfer(msg.sender, _to, _value);
            return true;
        } else { return false; }
    }

    function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {

        if (balances[_from] >= _value && allowed[_from][msg.sender] >= _value && _value > 0) {
            balances[_to] += _value;
            balances[_from] -= _value;
            allowed[_from][msg.sender] -= _value;
            Transfer(_from, _to, _value);
            return true;
        } else { return false; }
    }

3.2. ERC20 Compliance — zero-value transfers rejecting

Severity: low

Description

EIP20 says that: Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

But in this contract, function transfer has a condition:

_value > 0

Code snippet


function transfer(address _to, uint256 _value) returns (bool success) {

        if (balances[msg.sender] >= _value && _value > 0) {
            balances[msg.sender] -= _value;
            balances[_to] += _value;
            Transfer(msg.sender, _to, _value);
            return true;
        } else { return false; }
    }

    function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {

        if (balances[_from] >= _value && allowed[_from][msg.sender] >= _value && _value > 0) {
            balances[_to] += _value;
            balances[_from] -= _value;
            allowed[_from][msg.sender] -= _value;
            Transfer(_from, _to, _value);
            return true;
        } else { return false; }
    }

3.3. Known vulnerabilities of ERC-20 token

Severity: low

Description

  1. It is possible to double withdrawal attack. More details here.

  2. Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here.

Recommendation

Add into a function transfer(address _to, ... ) following code:

require( _to != address(this) );

3.4. Checking input addresses

Severity: low

Description

Incoming addresses should be checked for an empty value(0x0 address) to avoid loss of funds or blocking some functionality.

Code snippet

3.5. ERC20 Compliance: event missing

Severity: low

Description

According to ERC20 standard, when initializing a token contract if any token value is set to any given address a Transfer event should be emitted. An event isn't emitted when assigning the initial supply to the msg.sender.

Code snippet

4. Conclusion

The audited smart contract must not be deployed. Reported issues must be fixed prior to the usage of this contract.

5. Revealing audit reports

https://gist.github.com/yuriy77k/8eb8f92679114ba92de78a1af5444de8

https://gist.github.com/yuriy77k/780e1e15da219c1414a72e04ec9d2d82

https://gist.github.com/yuriy77k/2399fc5377d29ab1cd59f1fe531b6c0e