Recently, a number of deflationary tokens such as FETA and BEVO have suffered flashloan exploits. We noticed that our analysis contradicted a number of previously published reports.

According to these published analyses, one might get the impression that SafeMoon-type deflationary tokens are inherently vulnerable. Allegedly, if DEX Pair is not added to excludeFromReward(), an attacker can extract money from it. Such news would be quite disturbing given the popularity of SafeMoon clones.

In this post, we will show the real vulnerability conditions and bugged code.

Attack Flow

Exploit Transaction | Exploiter | Exploit Contract | Victim Pair | Token Contract

The attacker:

SafeMoon and DEX Pair Basics

SafeMoon

DEX Pair

Analysis

At first glance, the attack scenario seems clear:

From this superficial analysis, it turns out that the deflationary nature of the token and the forgetfulness of its deployer are to blame. It is necessary to add DEX Pair to excludedFromReward. If suddenly somewhere else there are such pairs of other deflationary tokens (which is very likely), then an attacker can also extract funds from them, bringing down the token price.

However, in reality, it is not possible to use the above approach. It is impossible to extract more from a Pair than was burned in shares. For example, if deliver() is applied to half of the total supply of tokens, then the Rate will drop two times, and the balance of the Pair will only double, which means that the skim() call will give only half of this. This is not a larger share than what was initially burned.

Let's look at an example:

Investigation

Now let’s take a closer look at the attack with figures:

It’s obvious now that in our case the Rate declines much faster than expected. Why does this happen?

Vulnerability

Despite the fact that rTotal was initially 66700 according to the FETA token’s logic, in reality there were 73300 reflections circulating. With extra reflections at the attacker’s disposal, they can practically burn “all” the supply but still keep a lot. Or burn 99% of rTotal and get x100 to 6600 (10%) unaccounted “shadow” reflections. That is exactly what happened.

rTotal state field is updated each time reflections are burned, for example in the function deliver() we get:

  function deliver(uint256 tAmount) public {
        address sender = _msgSender();
        require(!_isExcluded[sender], "Excluded addresses cannot call this function");
        (uint256 rAmount,,,,,,) = _getValues(tAmount);
        _rOwned[sender] = _rOwned[sender].sub(rAmount);
        _rTotal = _rTotal.sub(rAmount);
        _tFeeTotal = _tFeeTotal.add(tAmount);
    }

In the standard SafeMoon clone is the function _reflectFee(). It adjusts rTotal according to the amount that was burnt by transfer().

However, in our modified FETA token code the authors have split the fee into rFee, rBurn, rCharity and forgot to adjust rTotal with rCharity. Below is the code with our comments:

    function _transferBothExcluded(address sender, address recipient, uint256 tAmount) private {
        uint256 currentRate =  _getRate();
        (uint256 rAmount, uint256 rTransferAmount, uint256 rFee, uint256 tTransferAmount, 
            uint256 tFee, uint256 tBurn, uint256 tCharity) = _getValues(tAmount);
        uint256 rBurn =  tBurn.mul(currentRate);
        uint256 rCharity = tCharity.mul(currentRate);
        // sub 100% of rAmount from sender, add 91% to receiver
        _bothTransferContent(sender, recipient, tAmount, rAmount, tTransferAmount, rTransferAmount);    
        // add 3% to _rOwned[charity]
        _sendToCharity(tCharity, sender); 
        // sub 9% of rAmount from rTotal
        _reflectFee(rFee, rBurn, rCharity, tFee, tBurn, tCharity);
        emit Transfer(sender, recipient, tTransferAmount);
    }

In _sendToCharity(), 3% of transferred reflections (rAmount) are added to the charity account (_rOwned[charity]), but _reflectFee() still “burns” 9% (all three fees):

_rTotal = _rTotal.sub(rFee).sub(rBurn).sub(rCharity);

Via this bug, ~10% of extra reflections appeared in the system which were not accounted for by rTotal. This is what finally led to the exploit execution.

Conclusion

In order to find similar contracts in time, draw conclusions, and make recommendations for future projects, it is important to fully understand the causes and circumstances of this attack.

Adding a Pair to the excludedFromReward list closes the attack vector and should always be done.

However, as we have shown, the "standard" clones of the SafeMoon project are not affected by the attack. The specific bug in rTotal management was uncovered in FETA/BEVO code modification.

At CertiK we strongly recommend that all projects undergo a thorough code audit, even if the code is mostly forked from an audited project and changes appear (on the surface) to be minimal.

Read more: https://www.certik.com/resources/blog/54xxSWllEyCCKBgMKh32AW-how-safe-is-safemoon-analyzing-the-feta-and-bevo-exploits