Vulnerability Findings

SEC-01:      Unchecked tokens transfer (unchecked-transfer)

Finding:

DividendDistributor.distributeDividend(address) (ETS.sol:354-365) ignores return value by ETH.transfer(shareholder,amount) (ETS.sol#360)

Recommendation:

Use `SafeERC20`, or ensure that the transfer/transferFrom return value is checked.

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unchecked-transfer

Exploit Scenario:

there’s a potential risk associated with the ETH.transfer(shareholder, amount) line. This line transfers Ether without checking for the success of the transfer operation. If the transfer fails, the contract will continue executing, potentially leading to unexpected behavior.

Alleviation:

EthShares team has Acknowledge this issue.

SEC-02:      Centralization Risk

Finding:

109: abstract contract Auth {

135:     function authorize(address adr) public onlyOwner {

142:     function unauthorize(address adr) public onlyOwner {

163:     function transferOwnership(address payable adr) public onlyOwner {

398: contract ETS is IBEP20, Auth {

468:     ) Auth(msg.sender) {

“`

Scenario:

Centralized risk refers to the potential security risks that arise when a smart contract is controlled by a central entity or a single point of failure. If the contract is controlled by a central authority, then the contract may be vulnerable to attacks that target the centralized entity.
Centralized risk that can lead to rug pulls typically arises from the centralization of control or ownership of a project’s assets, particularly in decentralize d finance (DeFi) projects built on blockchain platforms like Ethereum.

Contract Auth (File: ETS.sol)

In the Auth (File: ETS.sol) contract, Owner can call functions authorize, unauthorize, transferOwnership  We’ve found that some functions work in an anti-whale manner and allow the owner to pause trading. Assigning a backlist address and also another function we recommend that for transparency use Timelock to increase the delay for users. Function calls are visible before they are fully executed. Additionally, the implementation of a multi-signature feature adds another layer of security to safeguard the owner’s account.

Contract ETS (File: ETS.sol)

In the ETC (File: ETS.sol) contract can external call, for authorized role can call functions setTradingEnabled, triggerZeusBuyback, clearBuybackMultiplier, setAutoBuybackSettings, setBuybackMultiplierSettings, launch, setTxLimit, setIsDividendExempt, setIsFeeExempt, setIsTxLimitExempt, setFees, setFeeReceivers, setSwapBackSettings, setTargetLiquidity, setDistributionCriteria, setDistributorSettings  We’ve found that some functions work in an anti-whale manner and allow the owner to pause trading. Assigning a backlist address and also another function we recommend that for transparency use Timelock to increase the delay for users. Function calls are visible before they are fully executed. Additionally, the implementation of a multi-signature feature adds another layer of security to safeguard the owner’s account.

Recommendation:

In terms of timeframes, there are three categories: short-term, long-term, and permanent.

For short-term solutions, a combination of timelock and multi-signature (2/3 or 3/5) can be used to mitigate risk by delaying sensitive operations and avoiding a single point of failure in key management. This includes implementing a timelock with a reasonable latency, such as 48 hours, for privileged operations; assigning privileged roles to multi-signature wallets to prevent private key compromise; and sharing the timelock contract and multi-signer addresses with the public via a medium/blog link.

For long-term solutions, a combination of timelock and DAO can be used to apply decentralization and transparency to the system. This includes implementing a timelock with a reasonable latency, such as 48 hours, for privileged operations; introducing a DAO/governance/voting module to increase transparency and user involvement; and sharing the timelock contract, multi-signer addresses, and DAO information with the public via a medium/blog link.

Finally, permanent solutions should be implemented to ensure the ongoing security and protection of the system.

Alleviation:

EthShares team has Acknowledge this issue.

SEC-03:      Avoid using block timestamp

Finding:

314:             block.timestamp

350:         return shareholderClaims[shareholder] + minPeriod < block.timestamp

361:             shareholderClaims[shareholder] = block.timestamp;

583:         if (launchedAtTimestamp + 1 days > block.timestamp) {

585:         } else if (buybackMultiplierTriggeredAt.add(buybackMultiplierLength) > block.timestamp) {

586:             uint256 remainingTime = buybackMultiplierTriggeredAt.add(buybackMultiplierLength).sub(block.timestamp);

624:             block.timestamp

647:                 block.timestamp

664:             buybackMultiplierTriggeredAt = block.timestamp;

689:             block.timestamp

716:         launchedAtTimestamp = block.timestamp;

Recommendation:

Using block timestamp in smart contracts can lead to security vulnerabilities and should be avoided.

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#block-timestamp

Exploit Scenario:

–

Alleviation:

EthShares team has Acknowledge this issue.

SEC-04:      Empty Function Body – Consider commenting why

Finding:

493:     receive() external payable { }

550:         if(!isDividendExempt[sender]){ try distributor.setShare(sender, _balances[sender]) {} catch {} }

550:         if(!isDividendExempt[sender]){ try distributor.setShare(sender, _balances[sender]) {} catch {} }

551:         if(!isDividendExempt[recipient]){ try distributor.setShare(recipient, _balances[recipient]) {} catch {} }

551:         if(!isDividendExempt[recipient]){ try distributor.setShare(recipient, _balances[recipient]) {} catch {} }

553:         try distributor.process(distributorGas) {} catch {}

553:         try distributor.process(distributorGas) {} catch {}

635:         try distributor.deposit{value: amountBNBReflection}() {} catch {}

635:         try distributor.deposit{value: amountBNBReflection}() {} catch {}

Recommendation:

While this line of code might work correctly in most cases, it is considered potentially unsafe because it assumes the ERC20 token contract implements the transfer function correctly and consistently with the ERC20 standard.

A safer way to interact with ERC20 tokens is to use a widely-adopted and audited library, such as OpenZeppelin’s ERC20 library. This helps you avoid potential issues with non-standard or malicious token implementations.

Alleviation:

EthShares team has Acknowledge this issue.

SEC-05:      Multiple calls in a loop (calls-loop)

Finding:

354:     function distributeDividend(address shareholder) internal {

if(shares[shareholder].amount == 0){ return; }

uint256 amount = getUnpaidEarnings(shareholder);

if(amount > 0){

totalDistributed = totalDistributed.add(amount);

ETH.transfer(shareholder, amount);

shareholderClaims[shareholder] = block.timestamp;

shares[shareholder].totalRealised = shares[shareholder].totalRealised.add(amount);

shares[shareholder].totalExcluded = getCumulativeDividends(shares[shareholder].amount);

}

365:    }

Recommendation:

distributeDividend(address shareholder) function, which involves making an external call using ETH.transfer(shareholder, amount). Although the provided code snippet does not contain a loop, the warning suggests that you should favor the “pull over push” strategy for external calls, which can help reduce the risk of reentrancy attacks and make your contract more gas-efficient in certain situations.

Favor [pull over push](https://github.com/ethereum/wiki/wiki/Safety#favor-pull-over-push-for-external-calls) strategy for external calls.

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation/#calls-inside-a-loop

Exploit Scenario:

–

Alleviation:

EthShares team has Acknowledge this issue.

SEC-06:      unlocked-compiler-version

Finding:

2: pragma solidity ^0.8.0;

Recommendation:

Unlocked pragma disables all source code analysis, making it vulnerable to attacks

Exploit Scenario:

–

Alleviation:

EthShares team has Acknowledge this issue.

SEC-07:      inconsistent-comments-and-code

Finding:

538:         //

Recommendation:

Inconsistent comments and code can lead to confusion and misunderstandings when maintaining and auditing a smart contract. It’s crucial to keep comments up-to-date and in sync with the actual code implementation

Exploit Scenario:

–

Alleviation:

EthShares team has Acknowledge this issue.