Analysis2023-02-28

Warning: MetaTrust’s On-chain Monitoring Engine Discovers Contract Vulnerabilities: Zombier Smart Contract Exposes Critical Security Flaws

2 Minutes Read

Daniel Tan

Daniel Tan

Security Operation / Audit

Summary

On February 28, 2023, MetaTrust’s on-chain monitoring engine discovered a serious security vulnerability in the recently open-sourced Zombier smart contract on the Ethereum blockchain. The contract has a reentrancy attack vulnerability and several parameter verification vulnerabilities, among other issues. If the client continues to use this contract, it may face significant security risks. For details, please see the vulnerability cause analysis report.

Attention! Attention! Attention!

On February 28, 2023, MetaTrust’s on-chain monitoring engine discovered a serious security vulnerability in the recently open-sourced Zombier smart contract on the Ethereum blockchain. The contract has a reentrancy attack vulnerability and several parameter verification vulnerabilities, among other issues. If the client continues to use this contract, it may face significant security risks. For details, please see the vulnerability cause analysis report.

https://miro.medium.com/v2/resize:fit:1400/1*JZu_iW1C7UYW-sy554javw.png

The trial link is provided at the end of the article.

Contract Address

https://etherscan.io//address/0xd79f71e635f248ad362bb95e2d7a18c7f48728cc#code

1function mint(address master, uint256 TokenId, address target) external payable{
2 (bool success, ) = target.call{value: 0.000777 ether}(abi.encodeWithSignature("purchase(uint256)", 1));
3 if(success){
4 Tokenint(target).safeTransferFrom(address(this), master, TokenId);
5 }
6 }
1function mint(address master, uint256 TokenId, address target) external payable{
2 (bool success, ) = target.call{value: 0.000777 ether}(abi.encodeWithSignature("purchase(uint256)", 1));
3 if(success){
4 Tokenint(target).safeTransferFrom(address(this), master, TokenId);
5 }
6 }

Vulnerability Cause

The “mint” function of the contract allows the “target” address to be arbitrarily specified as a parameter, allowing attackers to re-enter the “mint” function. Attackers can also customize the “safeTransferFrom” function of the “target” contract to make calls to “safeTransferFrom” without fail.

The contract does not verify whether the amount of ETH sent by the user (msg. value) is equal to the amount forwarded to the “target” contract, nor does it handle the case where the user sends too much ETH.

The contract does not verify whether the “TokenId” passed to the “transferFrom” function is equal to the TokenId obtained from the “purchase” function.

Recommended Fixes

1.Initialize the “target” contract address only in the constructor or manage it through a whitelist.

2.Add a “nonReentrant” modifier to prevent re-entry attacks.

3.Add verification to ensure that the amount of ETH sent by the user and the amount forwarded to the “target” contract are consistent, or return any excess ETH to the user.

4.Add verification to ensure that the token obtained from the “purchase” function is consistent with the token passed to the “safeTransferFrom” function.

Potential Fund Loss

The excess ETH will remain in the contract if a user sends too much ETH when calling the “mint” function.

The smart contract does not currently hold any ETH. However, if the contract had any ETH, it could be drained by a re-entry attack from a hacker.


Try our product for FREE to scan the smart contracts you care about.

Twitterhttps://twitter.com/MetatrustLabs

Share this article