Smoofs重入攻击案例分析

案例介绍：

2024年2月，Polygon上的项目Smoofs遭到攻击，项目被攻击的原因是项目设计中存在漏洞，导致被攻击者利用从而发生了重入漏洞，导致丢失4350 MOOVE，其价值目前不得而知。 Total lost: 4350 MOOVE 攻击者: 0x149b268b8b8101e2b5df84a601327484cb43221c 攻击合约:0x367120bf791cc03f040e2574aea0ca7790d3d2e5 被攻击合约: 0x9d6cb01fb91f8c6616e822cf90a4b3d8eb0569c6 攻击交易哈希: 0xde51af983193b1be3844934b2937a76c19610ddefcdd3ffcf127db3e68749a50

攻击前的准备：

该项目的关键安全问题可以分为以下几点： NFT与ERC20代币交互：用户可以将自己的NFT (例如：Smoofs) 转移给项目方，以换取相应价值的ERC20代币 (MOOVE)。 转账前未更新状态：关键的安全漏洞在于合约在更新内部状态（例如：用户的余额）之前先进行了转账操作。这种顺序错误留给了攻击者可乘之机。 缺乏防重入保护：进行代币转账的函数没有使用防重入的修饰符，如 nonReentrant，这允许攻击者在合约的单个事务中多次调用此函数。 攻击者合约的重入调用：在执行代币转账时，合约调用了攻击者的合约。攻击者合约利用重入漏洞，在项目方合约完成状态更新之前，重新进入并触发额外的未授权转账。 潜在的多次支付风险：由于合约逻辑的这种漏洞，攻击者可以多次从项目方合约中提取ERC20代币，导致项目方支付出超过原本预定额度的代币。 这些问题在下图中被详细概括，展示了漏洞存在的环节及其可能被利用的攻击路径。：

攻击流程：

Step1.攻击者调用被攻击项目中的Stake函数，将自己的Smoofs质押给被攻击项目。 Step2.攻击者调用被攻击项目中的Withdraw函数，将自己质押的NFT对应的token取出。 Step3.在攻击者调用Withdraw函数之后，该函数会调用对应NFT项目中的safeTransferFrom函数，而该函数会回调攻击合约。

Step4.在被攻击项目回调攻击合约之后，攻击合约在函数中多次重入。

Step5.在所有的回调结束之后，被攻击项目调用removeStake函数进行状态变量改变。

综上所述，本项目之所以会受到重入攻击是因为合约在转账之后才进行余额扣除(状态改变太晚)，并且还没有使用重入锁等防重入机制来防止重入的发生，这才导致漏洞被攻击者利用完成攻击。

重入攻击案例复现

复现流程： Step1.foundry环境准备： Step2.代码复现： 我们在本地复现了攻击案例的整个流程，在攻击过程中我们模拟攻击者原地址为整个交易的发起者，这样可以使得攻击合约中某些条件检测得以通过，我们编写了自己的攻击合约来复现整个交易流程：

(1)上图为配置实验环境，并且我们将本地的合约作为我们自己的攻击合约，用于复现整个攻击流程。

(2)我们将上述函数作为整个攻击交易的入口， 首先为了模拟整个攻击的流程，需要使用foundry内置的作弊码将一些资产转移到本地攻击合约为攻击做准备，这些资产包括Smoofs NFT以及MOOVE代币，同时本地攻击合约对漏洞项目SMOOFSSTaking合约授权自己的NFT以及ERC20代币的使用权。 (3)之后在攻击合约中调用漏洞项目SMOOFSSTaking合约中的Stake函数，将自己的Smoofs NFT存入SMOOFSStaking合约，此时该合约拥有攻击者的NFT以及改NFT的使用权。

(4)攻击合约调用漏洞项目SMOOFSSTaking合约中的Withdraw函数，想将上一步骤存入到SMOOFSSTaking中的NFT转换成对应的MOOVE代币取出。 (5)之后，漏洞项目SMOOFSStaking中的Withdraw函数会在改变状态变量之前会调用被攻击项目Smoofs代币合约中的safeTransferFrom函数，而在这个函数中回调用攻击合约中的onERC721Received函数，最终造成了重入。

(6)我们只需要在本地onERC721Received函数中进行重入，不断地调用Smoofs合约中的safeTransferFrom函数，就可以让Smoofs合约不断地为我转账，并且还不减少我拥有的NFT余额：

攻击复现整体业务逻辑图为：