Thread by @SlowMist_Team

🚨Brief Analysis of @OMNI_xyz Protocol Exploit🚨

On July 10, 2022, OMNI Protocol was the victim of a flash loan attack. We investigated this incident and these are our findings.

1/ The attacker used #doodle NFTs as collateral through the supplyERC721 function, providing them with the corresponding NToken. They then call the borrow function to borrow WETH.

2/(1) Use withdrawERC721 to withdraw the NFT, and follow up with the internal function executeWithdrawERC721 to find that the withdrawal will first burn the NToken through the burn function.

2/(2) The safeTransferFrom function in the burn function will call the OnERC721Received function of the receiving address externally. The attacker uses this to re-enter the liquidationERC721 function of the contract.

3/(1) In the liquidationERC721 function, the attacker first repaid WETH and received the doodle nft back. After checking, the _burnCollateralNTokens function will be called to burn the corresponding NToken.

3/(2) Then the attacker used the nature of the external call of the burn function to perform the reentrancy operation again. First, he staked the nft obtained by liquidation, and then called the borrow function to borrow 81 WETH.

3/(3) Because the vars variable is defined in the liquidationERC721 function, the second borrowing will not be affected when checking liabilities in the liquidationERC721. Leading the attacker to use userConfig.setBorrowing function and set the user's borrowing status to false.

4/ The userConfig.isBorrowingAny() function will first check the status of a user's borrowing. If it is false, the debt will not be checked. Therefore, the debt of 81 WETH after re-entry is not checked, allowing the attacker to withdraw all NFT profits without repaying.

5/(1) The root cause of this incident is that the burn function calls the OnERC721Received function externally, which caused the reentrancy problems.

5/(2) The value of the old vars is used for the liquidation function, resulting in the status of the user’s borrowing to be set as an unborrowed state. Despite the reentrancy, the status of the user’s borrowing was set to false, so no repayment was required.

6/ The SlowMist security team recommends the use of reentrancy locks in critical coding functions to prevent reentrancy issues in the future.

TX ID: etherscan.io/tx/0x05d65e0ad…