# Introduction

At around 13:00 on January 10, the token project BRA ([https://bscscan.com/token/0x449fea37d339a11efe1b181e5d5462464bba3752](https://bscscan.com/token/0x449fea37d339a11efe1b181e5d5462464bba3752)) was attacked. The attacker exploited the tax-sharing loophole in the token transfer process and increased circulation 1.6 million BRA tokens out of thin air and sold them, with a total profit of about 310,000 US dollars.

# Background

- **Attack transaction**
[https://bscscan.com/tx/0x4e5b2efa90c62f2b62925ebd7c10c953dc73c710ef06695eac3f36fe0f6b9348](https://bscscan.com/tx/0x4e5b2efa90c62f2b62925ebd7c10c953dc73c710ef06695eac3f36fe0f6b9348)
- **Victim contract**
[https://bscscan.com/token/0x449fea37d339a11efe1b181e5d5462464bba3752](https://bscscan.com/token/0x449fea37d339a11efe1b181e5d5462464bba3752)
- **Victim liquidity pool BUSD-BRA**
[https://bscscan.com/address/0x8f4ba1832611f0c364de7114bbff92ba676adf0e](https://bscscan.com/address/0x8f4ba1832611f0c364de7114bbff92ba676adf0e)
- **Attack contract**
[https://bscscan.com/address/0x6066435edce9c2772f3f1184b33fc5f7826d03e7](https://bscscan.com/address/0x6066435edce9c2772f3f1184b33fc5f7826d03e7)
- **Attacker**
[https://bscscan.com/address/0x67a909f2953fb1138bea4b60894b51291d2d0795](https://bscscan.com/address/0x67a909f2953fb1138bea4b60894b51291d2d0795)

# Analysis

Take the attack transaction [https://bscscan.com/tx/0x4e5b2efa90c62f2b62925ebd7c10c953dc73c710ef06695eac3f36fe0f6b9348](https://bscscan.com/tx/0x4e5b2efa90c62f2b62925ebd7c10c953dc73c710ef06695eac3f36fe0f6b9348) as an example:

## Flash Loan — Get WBNB

The attacker first calls the attack contract (*`0x6066435edce9c2772f3f1184b33fc5f7826d03e7`*), and the attack contract calls the `flashLoan` function of DPPAdvanced(*0x0fe261aee0d1c4dfddee4102e82dd425999065f4*) to perform a flash loan from DPPAdvanced and borrow 1000WBNB

[https://miro.medium.com/v2/resize:fit:1400/0*w4FQ_XKvVM714H7v](https://miro.medium.com/v2/resize:fit:1400/0*w4FQ_XKvVM714H7v)

## Token Swap — BNB to BRA

The attacker starts the flash loan attack through DPPFlashLoanCall. The attack contract holds 1000BNB, first withdraws from the WBNB contract, and swap WBNB to BNB

[https://miro.medium.com/v2/resize:fit:1400/0*5b_dLd8uYh3wJuzt](https://miro.medium.com/v2/resize:fit:1400/0*5b_dLd8uYh3wJuzt)

The attack contract calls *swapExactETHforTokens* of pancakeswap to exchange 1000 BNB for BRA

[https://miro.medium.com/v2/resize:fit:1400/0*2RUs2DvoQo5H65uN](https://miro.medium.com/v2/resize:fit:1400/0*2RUs2DvoQo5H65uN)

1.Among them, the exchange path is WBNB=>BUSD=>BRA, which is *0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c*=>*0x55d398326f99059ff775485246999027b3197955*=>*0x449fea37d35639a11efe1b482*

2.In this process, the BUSD-BRA pool data before the transaction is:

44233 BUSD-99921 BRA.

The user exchanged 272015 BUSD for BRA through 1000BNB.

Normally, he should get 85915 BRA, but in fact, the attack contract only got 83337 BRA, because the BRA token will be taxed during the transfer process:

```solidity
function _transfer(address sender, address recipient, uint amount) internal {
        // sender=BUSD-BRA
        // recipient=attack contract
        // amount=85915 BRA
        require(sender != address(0), "BEP20: transfer from the zero address");

        bool recipientAllow = ConfigBRA(BRA).isAllow(recipient);
        // recipientAllow=0
        bool senderAllowSell = ConfigBRA(BRA).isAllowSell(sender);
        // senderAllowSell=0
        uint BuyPer = ConfigBRA(BRA).BuyPer();
        // BuyPer=300
        uint SellPer = ConfigBRA(BRA).SellPer();
        // SellPer=300
        address BuyTaxTo_ = address(0);
        address SellTaxTo_ = address(0);

        _balances[sender] = _balances[sender].sub(amount, "BEP20: transfer amount exceeds balance");
        // _balance[BUSD-BRA] = _balance[BUSD-BRA](99921)-85915=14006
        uint256 finalAmount = amount;
        uint256 taxAmount = 0;

        if(sender==uniswapV2Pair&&!recipientAllow){
            taxAmount = amount.div(10000).mul(BuyPer);
            // taxAmount=(85915/10000)*300=85915*3%=2577
            BuyTaxTo_ = ConfigBRA(BRA).BuyTaxTo();
            // BuyTaxTo_=BUSD-BRA
        }

        if(recipient==uniswapV2Pair&&!senderAllowSell){
            taxAmount = amount.div(10000).mul(SellPer);
            SellTaxTo_ = ConfigBRA(BRA).SellTaxTo();
        }

        finalAmount = finalAmount - taxAmount;

        if(BuyTaxTo_ != address(0)){
            _balances[BuyTaxTo_] = _balances[BuyTaxTo_].add(taxAmount);
            // _balance[BUSD-BRA] = _balance[BUSD-BRA](14006)+2577=16583
            emit Transfer(sender, BuyTaxTo_, taxAmount);
        }

        if(SellTaxTo_ != address(0)){
            _balances[SellTaxTo_] = _balances[SellTaxTo_].add(taxAmount);
            emit Transfer(sender, SellTaxTo_, taxAmount);
        }

        _balances[recipient] = _balances[recipient].add(finalAmount);
        // _balance[attack contract]=_balances[recipient](0)+83337

        if (recipient == address(0) ) {
            totalBurn = totalBurn.add(amount);
            _totalSupply = _totalSupply.sub(amount);
            emit Burn(sender, address(0), amount);
        }
        emit Transfer(sender, recipient, finalAmount);

    }
```

3.In this way, after the exchange is completed, the pool changes from 44233 BUSD-99921 BRA to 316249 BUSD-16583 BRA, and the attacker has 1,000 BNB in his hand, which becomes 272015 BUSD, and finally becomes 83337 BRA. Some state variables are as follows:

balance0=16583，balance1=316249，reserve0=16583，reserve1=316249

## **The core attack point — transfer to the liquidity pool**

The attack contract directly transfers the 83337 BRA it holds to the liquidity pool through transfer. Of course, this transfer process also needs to collect taxes, but after the tax is collected, the tax flow is also the liquidity pool, so in fact, 83337 BRA was transferred to the liquidity pool in full.

## **The core attack point — call skim to the liquidity pool itself, resulting in increased circulation**

The attack contract calls the `skim` function to carry out the core step of the attack. The `to` parameter input of the attacker in the *skim* function is the liquidity pool itself, so this *skim* is actually a transfer from the liquidity pool to the liquidity pool itself.

```solidity
function skim(address to) external lock {
        address _token0 = token0; // gas savings
        address _token1 = token1; // gas savings
        _safeTransfer(_token0, to, IERC20(_token0).balanceOf(address(this)).sub(reserve0));
        _safeTransfer(_token1, to, IERC20(_token1).balanceOf(address(this)).sub(reserve1));
}
```

1. Since in the skim function at this time, *IERC20(_token0).balanceOf (address(this)). sub(reserve0))* is not 0 (the reason is that the attacker transferred 83337 to the liquidity pool), therefore, the liquidity pool will call `safeTransfer` to the liquidity pool itself, but this behavior, from the perspective of BRA’s transfer process, is both buying and selling tokens. Therefore, the current transfer execution process is as follows:
    
    ```solidity
    function _transfer(address sender, address recipient, uint amount) internal {
            // sender=BUSD-BRA
            // recipient=BUSD-BRA
            // amount=83337 BRA
            require(sender != address(0), "BEP20: transfer from the zero address");
    
            bool recipientAllow = ConfigBRA(BRA).isAllow(recipient);
            // recipientAllow=0
            bool senderAllowSell = ConfigBRA(BRA).isAllowSell(sender);
            // senderAllowSell=0
            uint BuyPer = ConfigBRA(BRA).BuyPer();
            // BuyPer=300
            uint SellPer = ConfigBRA(BRA).SellPer();
            // SellPer=300
            address BuyTaxTo_ = address(0);
            address SellTaxTo_ = address(0);
    
            _balances[sender] = _balances[sender].sub(amount, "BEP20: transfer amount exceeds balance");
            // _balance[BUSD-BRA] = _balance[BUSD-BRA](99921)-83337=16583
            uint256 finalAmount = amount;
            uint256 taxAmount = 0;
    
            if(sender==uniswapV2Pair&&!recipientAllow){
                taxAmount = amount.div(10000).mul(BuyPer);
                // taxAmount=(83337/10000)*300=83337*3%=2500
                BuyTaxTo_ = ConfigBRA(BRA).BuyTaxTo();
                // BuyTaxTo_=BUSD-BRA
            }
    
            if(recipient==uniswapV2Pair&&!senderAllowSell){
                taxAmount = amount.div(10000).mul(SellPer);
                // taxAmount=(83337/10000)*300=83337*3%=2500
                SellTaxTo_ = ConfigBRA(BRA).SellTaxTo();
                // SellTaxTo_=BUSD-BRA
            }
    
            finalAmount = finalAmount - taxAmount;
            //finalAmount = 83337-2500=80837
    
            if(BuyTaxTo_ != address(0)){
                _balances[BuyTaxTo_] = _balances[BuyTaxTo_].add(taxAmount);
                // _balance[BUSD-BRA] = _balance[BUSD-BRA](16583)+2500=19083
                emit Transfer(sender, BuyTaxTo_, taxAmount);
            }
    
            if(SellTaxTo_ != address(0)){
                _balances[SellTaxTo_] = _balances[SellTaxTo_].add(taxAmount);
                // _balance[BUSD-BRA] = _balance[BUSD-BRA](19083)+2500=21583
                emit Transfer(sender, SellTaxTo_, taxAmount);
            }
    
            _balances[recipient] = _balances[recipient].add(finalAmount);
            // _balance[BUSD-BRA]=_balances[BUSD-BRA](21583)+80837=102421
    
            if (recipient == address(0) ) {
                totalBurn = totalBurn.add(amount);
                _totalSupply = _totalSupply.sub(amount);
                emit Burn(sender, address(0), amount);
            }
            emit Transfer(sender, recipient, finalAmount);
    
        }
    ```
    
2. This resulted in a result. Obviously, the liquidity pool originally had 16,583 BRA, and the 83,337 BRA that called skim were transferred to itself. The result should be 99,921, but it actually became 102,421, which is 2,500 BRA more than the actual number.
    - 2,500 BRA: because the BRAs can’t tell whether they are buying or selling, add 3% tax, which is 3% tax of 83337
    - At this time, the amount stored in reserve0 is still 16583, which is 83337 more than before the first skim, and now it is 102421–16583=85838 more, the difference is even bigger

## Sell tokens

1. In this way, the attacker continuously called skim(BUSD-BRA) for a total of 100 times,and finally made the extra number reach 1618221–16583=1601638 BRA. For the last skim, the attacker transferred 1.6 million BRA to the attacker contract itself, and sold them.
2. Although the status of the liquidity pool is normal at this time, which is 316249BUSD-16583BRA, 1.6 million BRAs were increased circulation out of thin air. The attacker sold these BRAs and made a profit of 313093 BUSDs, which were exchanged for 144 WBNBs, about 310,000 US dollars.

# What MetaTrust Could Do Now

MetaTrust provides a **Prover engine** based on **symbolic execution(metatrust.io)**, which can troubleshoot whether there are such problems in ERC20 tokens.

The Prover engine checks the state by using the property generator. If the state is found to be unbalanced, such a vulnerability will be reported.

# Conclusion

When designing tokens for tax collection, it is important to pay attention to the amount of tax payment to meet the design requirements. At the same time, the logic of sales tax and purchase tax must be opposite to each other to avoid secondary tax issuance

# Tips and Reminders for other attacker

After the attack, many attack imitators appeared, among which the attacker *0x5881d64e1caa924c3bc2ed8ce5d4961ec9b20d49* and its attack contract *0xc746560b1c96bfeac9041c2f5413d9883182774b* were the most frequent. Just five minutes after the first attack, it carried out 4 similar attacks, with a total profit of about 52BNB, 14433 US dollars.

Attack transaction collection method:

[https://dune.xyz/](https://dune.xyz/)

```sql
select * from bnb.traces where to="0x8f4ba1832611f0c364de7114bbff92ba676adf0e" and input like "%bc25cf77%" and block_number>24650000
```

---

1、You can reach out to us via Twitter([https://twitter.com/MetatrustLabs](https://twitter.com/MetatrustLabs)), or by submitting a request via [metarust.io](https://metatrust.io/).

2、Feel Free to email us at *social@metatrust.io* or message us via Twitter.

3、Share your thoughts in the comments section below. Find out more about Web3 security and get free trial access to our tools via [metarust.io](https://metatrust.io/).

This blog post analyzes the BRA flash loan attack, which involved a series of transactions on the Binance Smart Chain. The attacker used a flash loan to borrow 1000 WBNB, which was then used to purchase and sell BRA tokens, resulting in an increase in circulation and a profit of approximately $310,000. The post also suggests using MetaTrust's Prover engine to troubleshoot ERC20 tokens for vulnerabilities and provides tips for preventing similar attacks.

Security Analysis of BRA Flash loan attack

# Background

On December 23, 2022, a **re-entrancy attack (V2)** was conducted on the **Defrost Finance** project on AVAX and the hackers gained **$173,000**. Immediately following, on December 24, 2022, the project owner performed a **[Rug Pull](https://twitter.com/CoinDesk/status/1607396862243250176) (V1)** with damage estimated at over **$12 million**.

On December 26, 2022, Defrost Finance stated that the hackers involved in the V1 hack (Rug Pull) had returned the funds.

# Transaction information

**Re-entrancy attack**

> Attack transaction: `0xc6fb8217e45870a93c25e2098f54f6e3b24674a3083c30664867de474bf0212d`
> 
> 
> *Attacker Address: `0x7373Dca267bdC623dfBA228696C9d4E8234469f6`*
> 
> *Attacker contract address: `0x792E8f3727cad6e00c58d478798F0907c4cEC340`*
> 
> *Victim contract address: `0xfF152e21C5A511c478ED23D1b89Bb9391bE6de96`*
> 

**Rug Pull**

> One of the transactions for modifying the prophecy machine.
> 
> 
> *`0x6307fdc4c7cce0c06a477db59a6ad378eb674cf1c902bd1b3748408926b2582d`*
> 
> *Mint transaction: `0x69e9088b9fa395e8a4fca360c74ea86039510422a0fbbb98cae6872da14e8de2`*
> 
> *Developer Address: `0x3cd5854fe3a13707b7882d8290d3cae793a7751a`*
> 
> *Liquidator Address: `0x6F31EB634ABa6921fBf15fc9aA6E08f11348f64f`*
> 
> *Project owner contract address: `0x5a733eb741bc080abae9bf3adaed9400416932f0`*
> 

# Attack process

**Re-entrancy attack**

1. The attacker deploys the attack contract and uses the *swap* function in *JoePair* to call the *flashloan* of *LSWUSDC* by passing the *calldata*.

2. Rewrite the *onFlashLoan* function in the attack contract and call the *deposit* of *LSWUSDC* in it to repeat the coin minting.

3. Drained out the entire amount of coins minted twice and return the amount of flashloan, leaving $173,637 as proceeds.

![https://miro.medium.com/v2/resize:fit:1400/1*8af7paY0StcidyVAMTB2SA.png](https://miro.medium.com/v2/resize:fit:1400/1*8af7paY0StcidyVAMTB2SA.png)

![https://miro.medium.com/v2/resize:fit:1400/1*Pn_GM0Yyp-wrKluimEszsg.png](https://miro.medium.com/v2/resize:fit:1400/1*Pn_GM0Yyp-wrKluimEszsg.png)

**Rug Pull**

1. The project owner calls the *setOracleAddress* function to manually set the malicious prophecy machine for the Collateral Vault of a large number of tokens.

2. Call the *joinAndMint* function to mint fake collateral tokens.

3. Malicious liquidation.

[https://miro.medium.com/v2/resize:fit:1400/0*JzjVo3xIOa6R5qmU](https://miro.medium.com/v2/resize:fit:1400/0*JzjVo3xIOa6R5qmU)

[https://miro.medium.com/v2/resize:fit:1400/0*HILNZ4v5w57uterh](https://miro.medium.com/v2/resize:fit:1400/0*HILNZ4v5w57uterh)

# Analysis of the attack

**Re-entrancy attack**

In the code, the lack of protection against re-entrancy in the *deposit* and *flashloan* functions leads to the attacker being able to re-enter via *onFlashLoan*. The attacker re-enters the *deposit* through the malicious contract, and both the *_deposit* function and the *flashloan* function make calls to the *onDeposit* function, which performs the coin minting operation, which allows the attacker to repeatedly mint coins and gain excess profit.

[https://miro.medium.com/v2/resize:fit:1226/0*n7G63vClbxUMjf1y](https://miro.medium.com/v2/resize:fit:1226/0*n7G63vClbxUMjf1y)

[https://miro.medium.com/v2/resize:fit:1286/0*L3g5Z3_jOuCIQ-1a](https://miro.medium.com/v2/resize:fit:1286/0*L3g5Z3_jOuCIQ-1a)

[https://miro.medium.com/v2/resize:fit:1390/0*Miyrv9E3_DxU9yQL](https://miro.medium.com/v2/resize:fit:1390/0*Miyrv9E3_DxU9yQL)

**Rug Pull**

After the attack occurs, the project owner accidentally modifies the *Oracle address*. However the clearing logic is dependent on the *Oracle address* to get the price. This leads to a malicious liquidation by the project owner using the *liquidate* function.

[https://miro.medium.com/v2/resize:fit:1400/0*kZBRhpsJfwrLU_jn](https://miro.medium.com/v2/resize:fit:1400/0*kZBRhpsJfwrLU_jn)

In the *setOracleAddress* function, a fully centralized method (multiple signatures) is used to determine if the *Oracle* can be changed.

[https://miro.medium.com/v2/resize:fit:1012/0*2cIyI1eCu7WieKa-](https://miro.medium.com/v2/resize:fit:1012/0*2cIyI1eCu7WieKa-)

[https://miro.medium.com/v2/resize:fit:1390/0*p7jfHPgYZoVsR91F](https://miro.medium.com/v2/resize:fit:1390/0*p7jfHPgYZoVsR91F)

# MetaScan can scan for this risk

MetaScan was able to scan for this re-entrancy vulnerability and given two vulnerability reports with suggestion solutions.

- **Unchecked target and call data**, i.e. this attack is caused by not checking the *receiver* and *calldata* passed in by *flashloan*. The report can remind developers to always pay attention to external incoming parameters for problems.

[https://miro.medium.com/v2/resize:fit:1400/0*MPfu18Hp02GDA_pX](https://miro.medium.com/v2/resize:fit:1400/0*MPfu18Hp02GDA_pX)

- **Re-entrancy vulnerabilities**, i.e., potential re-entrancy attacks. This report reminds developers to always be aware of potential re-entrancy vulnerabilities in external calls.

[https://miro.medium.com/v2/resize:fit:1400/0*1rcCOoPtCNoIQV5r](https://miro.medium.com/v2/resize:fit:1400/0*1rcCOoPtCNoIQV5r)

# Reference Links

1. [https://twitter.com/DefiyieldSec/status/1607070666897129473](https://twitter.com/DefiyieldSec/status/1607070666897129473)
2. [https://twitter.com/peckshield/status/1606767457099993088](https://twitter.com/peckshield/status/1606767457099993088)
3. [https://medium.com/@Defrost_Finance/hacked-funds-returned-to-defrost-71b9d2d1b458](https://medium.com/@Defrost_Finance/hacked-funds-returned-to-defrost-71b9d2d1b458)

An analysis of the Defrost Finance project hack that occurred on December 23, 2022. The hack involved a re-entrancy attack and a rug pull, resulting in the loss of over $12 million. This post provides transaction information, attack processes, and an analysis of the vulnerabilities that led to the hack. MetaScan has the ability to scan for these types of risks.

Defrost Finance Event Analysis

# Information

attacker address：`0x14c19962e4a899f29b3dd9ff52ebfb5e4cb9a067`

transaction hash：`0x6bfd9e286e37061ed279e4f139fbc03c8bd707a2cdd15f7260549052cbba79b7`

exploit smart contract：`0x6cfa86a352339e766ff1ca119c8c40824f41f22d`

parameters of this transaction and internal transaction：[https://fefu.io/eth/tx/0x6bfd9e286e37061ed279e4f139fbc03c8bd707a2cdd15f7260549052cbba79b7](https://fefu.io/eth/tx/0x6bfd9e286e37061ed279e4f139fbc03c8bd707a2cdd15f7260549052cbba79b7)

tenderly: [https://dashboard.tenderly.co/tx/mainnet/0x6bfd9e286e37061ed279e4f139fbc03c8bd707a2cdd15f7260549052cbba79b7](https://dashboard.tenderly.co/tx/mainnet/0x6bfd9e286e37061ed279e4f139fbc03c8bd707a2cdd15f7260549052cbba79b7)

a packet of code and Chinese passage：[https://1drv.ms/u/s!At0_LwVPvookh6ApCW53C1CM9ixVIg?e=ewzgtq](https://1drv.ms/u/s!At0_LwVPvookh6ApCW53C1CM9ixVIg?e=ewzgtq)

# How to exploit

See the entire decompiled code: [https://gist.github.com/learnerLj/f6a1ce6e8a1b1fe98510cfbd2a98d3d1](https://gist.github.com/learnerLj/f6a1ce6e8a1b1fe98510cfbd2a98d3d1)

First, the attacker invoked the exploit contract that sets preventive requirements to avert bots front-run his transaction. The decompiled code is simplified, and we ignore some check statements.

```solidity
function 0xb727281f(uint256 varg0, uint256 varg1) public payable {
  require(4 + (msg.data.length — 4) — 4 >= 64);
  require(msg.sender == 0x14c19962e4a899f29b3dd9ff52ebfb5e4cb9a067);
  stor_5 = varg0;
  stor_9 = varg1;
  v0, v1 = stor_0_0_19.viewDeposit(stor_5).gas(msg.gas);
	RETURNDATACOPY(v1, 0, RETURNDATASIZE());
	MEM[64] = v1 + (RETURNDATASIZE() + 31 & ~0x1f);
	if (1 < MEM[v1 + MEM[v1 + 32]]) {
	  if (0 < MEM[v1 + MEM[v1 + 32]]) {
      0x34d3();
      exit;
    }
	}
  revert(Panic(50));
}
```

The statement ***v0, v1 = stor_0_0_19.viewDeposit(stor_5).gas(msg.gas);*** invokes ***viewDeposit*** function, which locates at ***Curve/contracts/Curve.sol#550***

```solidity
/// @notice view deposits and curves minted a given deposit would return
/// @param _deposit the full amount of stablecoins you want to deposit. Divided evenly according to the
/// prevailing proportions of the numeraire assets of the pool
/// @return (the amount of curves you receive in return for your deposit,
/// the amount deposited for each numeraire)
function viewDeposit(uint256 _deposit) external view transactable returns (uint256, uint256[] memory) {
  // curvesToMint_, depositsToMake_
  return ProportionalLiquidity.viewProportionalDeposit(curve, _deposit);
}
```

***roportionalLiquidity.viewProportionalDeposit*** is one of the functions in the library contract at ***Curve/contracts/ProportionalLiquidity.sol#78*** whose first parameter ***curve*** is a complex struct combining an assortment of ***curve*** contract attributes. The second is the planned deposited balance. We skim these details, and the reader needs to see that the purpose of this part is to view how many tokens are exchanged if he deposits another token.

Then, the attacker contract executed the following code after many checks that assure the transaction wound success.

```solidity
function 0x34d3() private {
  v0 = 0x3774(stor_9, stor_7);
  v1 = 0x37e1(1000, v0);
  v2 = _SafeSub(v1, stor_7);
  v3 = 0x3774(stor_9, _uniswapV3FlashCallback);
  v4 = 0x37e1(1000, v3);
  v5 = _SafeSub(v4, _uniswapV3FlashCallback);
  require(stor_0_0_19.code.size);
  v6 = stor_0_0_19.flash(address(this), v2, v5, ‘0xcallflash’).gas(msg.gas);
  require(v6); // checks call status, propagates error data on error
  require(stor_0_0_19.code.size);
  v7, v8 = stor_0_0_19.balanceOf(address(this)).gas(msg.gas);
  require(v7); // checks call status, propagates error data on error
  MEM[64] = MEM[64] + (RETURNDATASIZE() + 31 & ~0x1f);
  require(MEM[64] + RETURNDATASIZE() — MEM[64] >= 32);
  0x43bd(v8);
  require(stor_0_0_19.code.size);
  v9 = stor_0_0_19.withdraw(v8, 0xf285c0bd068).gas(msg.gas);
  require(v9); // checks call status, propagates error data on error
  return ;
}
```

Functions ***0x3774 and 0x37e1*** dispose with arithmetical operation. we focus the critical step ***v6 = stor_0_0_19.flash(address(this), v2, v5, ‘0xcallflash’).gas(msg.gas);*** and the callee is as follows:

```solidity
function flash(
  address recipient,
  uint256 amount0,
  uint256 amount1,
  bytes calldata data
) external transactable noDelegateCall isNotEmergency {
  uint256 fee = curve.epsilon.mulu(1e18);
  require(IERC20(derivatives[0]).balanceOf(address(this)) > 0, 'Curve/token0-zero-liquidity-depth');
  require(IERC20(derivatives[1]).balanceOf(address(this)) > 0, 'Curve/to ken1-zero-liquidity-depth');
  uint256 fee0 = FullMath.mulDivRoundingUp(amount0, fee, 1e18);
  uint256 fee1 = FullMath.mulDivRoundingUp(amount1, fee, 1e18);
  uint256 balance0Before = IERC20(derivatives[0]).balanceOf(address(this));
  uint256 balance1Before = IERC20(derivatives[1]).balanceOf(address(this));
  if (amount0 > 0) IERC20(derivatives[0]).safeTransfer(recipient, amount0);
  if (amount1 > 0) IERC20(derivatives[1]).safeTransfer(recipient, amount1);
  IFlashCallback(msg.sender).flashCallback(fee0, fee1, data);
  uint256 balance0After = IERC20(derivatives[0]).balanceOf(address(this));
  uint256 balance1After = IERC20(derivatives[1]).balanceOf(address(this));
  require(balance0Before.add(fee0) <= balance0After, 'Curve/insufficient-token0-returned');
  require(balance1Before.add(fee1) <= balance1After, 'Curve/insufficient-token1-returned');
  // sub is safe because we know balanceAfter is gt balanceBefore by at least fee
  uint256 paid0 = balance0After - balance0Before;
  uint256 paid1 = balance1After - balance1Before;
  IERC20(derivatives[0]).safeTransfer(owner, paid0);
  IERC20(derivatives[1]).safeTransfer(owner, paid1);
  emit Flash(msg.sender, recipient, amount0, amount1, paid0, paid1);
}
```

It is a standard flash loan implementation. What is noteworthy is the line ***IFlashCallback(msg.sender).flashCallback(fee0, fee1, data);*** , a callback to the attacker contract whereby it runs the following code( also simplified).

```solidity
function 0xc3924ed6(uint256 varg0, uint256 varg1, uint256 varg2) public payable {
  v0 = stor_0_0_19.deposit(stor_5, 0xf285c0bd068).gas(msg.gas);
```

Attacker directly reenter the function ***deposit***, with the specfic parameters ***deposit(uint256 200_000_000_000_000_000_000_000, 16_666_017_386_600)*** . In the function body, it calls the function of the library contract.

```solidity
 /// @notice deposit into the pool with no slippage from the numeraire assets the pool supports
 /// @param _deposit the full amount you want to deposit into the pool which will be divided up evenly amongst
 /// the numeraire assets of the pool
 /// @return (the amount of curves you receive in return for your deposit,
 /// the amount deposited for each numeraire)
 function deposit(uint256 _deposit, uint256 _deadline)
   external
   deadline(_deadline)
   transactable
   nonReentrant
   noDelegateCall
   notInWhitelistingStage
   isNotEmergency
   returns (uint256, uint256[] memory)
 {
   // (curvesMinted_, deposits_)
   return ProportionalLiquidity.proportionalDeposit(curve, _deposit);
 }
```

```solidity

function proportionalDeposit(Storage.Curve storage curve, uint256 _deposit)
  external
  returns (uint256 curves_, uint256[] memory)
{
  int128 __deposit = _deposit.divu(1e18);
  uint256 _length = curve.assets.length;
  uint256[] memory deposits_ = new uint256[](_length);
  (int128 _oGLiq, int128[] memory _oBals) = getGrossLiquidityAndBalancesForDeposit(curve);
  // Needed to calculate liquidity invariant
  // (int128 _oGLiqProp, int128[] memory _oBalsProp) = getGrossLiquidityAndBalances(curve);
  // No liquidity, oracle sets the ratio
  if (_oGLiq == 0) {
    for (uint256 i = 0; i < _length; i++) {
    // Variable here to avoid stack-too-deep errors
      int128 _d = __deposit.mul(curve.weights[i]);
      deposits_[i] = Assimilators.intakeNumeraire(curve.assets[i].addr, _d.add(ONE_WEI));
    }
  } else {
    // We already have an existing pool ratio
    // which must be respected
    int128 _multiplier = __deposit.div(_oGLiq);
    uint256 _baseWeight = curve.weights[0].mulu(1e18);
    uint256 _quoteWeight = curve.weights[1].mulu(1e18);
    for (uint256 i = 0; i < _length; i++) {
      deposits_[i] = Assimilators.intakeNumeraireLPRatio(
        curve.assets[i].addr,
        _baseWeight,
        _quoteWeight,
        _oBals[i].mul(_multiplier).add(ONE_WEI)
      );
    }
  }
  int128 _totalShells = curve.totalSupply.divu(1e18);
  int128 _newShells = __deposit;
  if (_totalShells > 0) {
    _newShells = __deposit.mul(_totalShells);
    _newShells = _newShells.div(_oGLiq);
  }
  mint(curve, msg.sender, curves_ = _newShells.mulu(1e18));
  return (curves_, deposits_);
}
```

The function ***getGrossLiquidityAndBalancesForDeposit(curve)*** calculates previous gross liquidity and the summation of assets the contract control. The attacker contract deposit tokens it borrowed from flash loan after calculating the expected deposit balance and LP exchange ratio.

Here are two logs when borrowing tokens.***{“from”:”0x6cfa86a352339e766ff1ca119c8c40824f41f22d”“to”:”0x46161158b1947d9149e066d6d31af1283b2d377c”“value”:”2325581395325581"}***

***{“from”:”0x6cfa86a352339e766ff1ca119c8c40824f41f22d”“to”:”0x46161158b1947d9149e066d6d31af1283b2d377c”“value”:”100000000000"}***

Subsequently, the ***curve*** funding pool mints token to the attacker contract.***{“from”:”0x0000000000000000000000000000000000000000"“to”:”0x6cfa86a352339e766ff1ca119c8c40824f41f22d”“value”:”387023837944937266146579"}***

The balances of flash loan contract assets before and after the callback of it:***balance0Before = 0x000000000000000000000000000000000000000000000000002463e31a1c492cbalance1Before = 0x00000000000000000000000000000000000000000000000000000068516c41ac***

***balance0After = 0x00000000000000000000000000000000000000000000000000247093e6d40a1dbalance1After = 0x00000000000000000000000000000000000000000000000000000068752f87ac***

***paid0 = 0xcb0ccb7c0f1paid1 = 0x23c34600***

The return tokens are starkly minimal compared to the following borrowed tokens. It demonstrates that the attacker got a large of money from nearly nothing. It retained two tokens, respectively, *0x829b9038770ab* and ***0x1700f05c00***. Repeated the attack process, the attacker exhausted the funding pool.***{“from”:”0x46161158b1947d9149e066d6d31af1283b2d377c”“to”:”0x6cfa86a352339e766ff1ca119c8c40824f41f22d”“value”:”0x83669d03f319c”}***

***{“from”:”0x46161158b1947d9149e066d6d31af1283b2d377c”“to”:”0x6cfa86a352339e766ff1ca119c8c40824f41f22d”“value”:”0x1724b3a200"}***

Summary: the procedure of this hack event is relevantly simple. The ***curve*** contract should not allow reentrance because it did not consider the balance change from its other functions. Generally, carefully evaluate the impact of each callback and check the dependent state variable, whether or not tempered can help avoid such a problem. It is obscure that the flash loan contract fetches balances through a proxy contract and calculates the exchange rate through its ABI-encoded parameters executed by another contract, resulting in a complicated call and return.

> The core of the attack is that in the callback function of the curve flash loan, the attacker deposits the borrowed token into the curve contract. Since the curve contract obtains the balance through balance(curve), the deposited token is also regarded as repayment.
>

An analysis of the DFX Finance attack, focusing on the smart contract code. The attacker exploited a vulnerability in the Curve contract that allowed them to re-enter the deposit function and deposit borrowed tokens, which were then treated as repayment. The attack demonstrates the importance of carefully evaluating the impact of each callback and checking dependent state variables to avoid similar problems.

Security Analysis of BRA Flash loan attack

Blogs

Security Analysis of BRA Flash loan attack

Defrost Finance Event Analysis

From the Source: Analysis of DFX Finance Attack

Products

Company

Legal

Social Media