2022年3月27日，以太坊上的stakingDeFi项目RevestFinance遭到黑客攻击，损失约200万美元。BlockSecTeam团队第一时间介入分析，并在tweeter上向社区分享了我们的分析成果。事实上，就在我们通过tweeter向社区分享我们的分析成果时，我们发现了RevestFinance的TokenVault合约中还存在着一个criticalzero-dayvulnerability。利用该漏洞,攻击者可以用更加简单的方式盗取协议中的资产。于是我们立刻联系了RevestFinance项目方。在确定该漏洞已经被修复后，我们决定向社区分享这篇blog。
0.What'stheRevestFinanceFNFT
RevestFinance是针对DeFi领域中staking的解决方案，用户通过RevestFinance参与的任何DeFi的staking，都可以直接生成一个NFT,即FNFT(FinanceNon-FungibleToken),该NFT代表了这个staking仓位的当前以及未来价值。用户可以通过RevestFinance提供的3个接口和项目进行交互。质押自己的数字资产，mint出相应的FNFT。
?mintTimeLock:用户质押的数字资产在一段时间之后才能被解锁。
?mintValueLock:用户质押的数字资产只有在升值或者贬值到预设数值才能被解锁。
?mintAddressLock:用户质押的数字资产只能被预设的账户解锁。
RevestFinance通过以下3个智能合约完成对用户存入的数字资产的锁定和解锁。
?FNFTHandler:继承自ERC-1155token(openzepplin实现)。每次执行lock操作时，fnftId会进行自增(fnftId类似于ERC721中的tokenId)。FNFT在被创建时，用户需要指定它的totalSupply。当用户想要提走FNFT背后的underlyingasset，需要burn掉相应比例的FNTF。
?LockManage:记录FNFT被解锁(unlock)的条件。
?TokenVault:接收和发送用户存入的underlyingasset,并记录每一种FNFT的metadata。例如fnftId=1的FNFT背后质押的资产类型。
因为此次攻击，黑客攻击的入口是mintAddressLock函数，那么我们以该函数为例，讲述FNFT的生命周期。
UserA调用Revest的mintAddressLock函数
?unlocker:UserX->只有UserX可以解锁这笔资产?recipients:?quantities:->mint数量为100(sum(quantities)),UserA,UserB,UserC各拥有50，25，25枚。?asset:WETH->mint出的FNFT以WETH为抵押品。?depositAmount:1e18->每一枚FNFT背后的抵押品数量为1枚WETH(WETHdecimal为18)
假设当前系统中没有其他FNFT,UserA通过mintAddressLock与系统进行交互，FNFTHandler返回的fnftId=1
LockManger为其添加相应的记录
?fnftId:1?unlocker:UserX
TokenVault为其添加相应的记录
?fnftId:1?asset:WETH?depoistAmount:1e18
接着TokenValut要从UserA这里转走100*1e18数量的WETH。
最后系统分别给UserA,UserB,UserCmint50,25,25枚01-FNFT。
通过mintAddressLock函数铸造FNFT就完成了。
当UserX解锁01-FNFT后，用户B便可以通过withdrawFNFT提走underlyingasset。如图二所示，UserB想要提取自己手中持有的25个01-FNFT质押的数字资产。
协议首先检查01-FNTF是否已经unlock，如果已经unlock,那么协议会burn掉UserB的25个01-FNFT,并给他转25*1e18数量的WETH。此时01-FNFT的totalSupply为75。
Revest合约还提供了另外一个接口，叫做depositAdditionalToFNFT，以便让用户为一个已经存在的FNFT添加更多的underlyingasset。下面我们用2张图描述它的“正常”用法。
这里有三种情况
一.quantity==01-FNFT.totalSupply()如图三所示
以图二中的场景为上下文，UserA要为01-FNFT添加更多的抵押物。
?quantity=75->为75个01-FNFT追加质押。
?amount=0.5*1e18->每一枚01-FNFT追加0.5*1e18数量的WETH。
于是UserA需要向TokenVault转入37.5*1e18WETHTokenVault修改系统记账，将depositAmount修改为1.5*1e18。现在每一枚01-FNFT承载的资产为1.5*1e18WETH。
此时UserC调用withdrawFNFT,burn掉他持有的25枚01-FNFT,他可以拿走25*(1.5*1e18)=37.5*1e18WETH。
于是，此时01-FNFT的totalSupply为50。
二.quantity<01-FNFT.totalSupply()如图四所示
以图三中的场景为上下文，UserA继续为01-FNFT添加更多的抵押物。
?quantity=10->为10枚01-FNFT追加质押。?amount=0.5*1e18->为10枚01-FNFT每一枚追加0.5*1e18WETH
由于quantity<01-FNFT.totalSupply()于是，UserA向协议支付5*1e18WETH系统将会burn掉10枚01-FNFT,mint出10枚02-FNFT,并将burn掉的10枚01-FNFT承载的资产和UserA新转入的资产，注入到02-FNFT中。于是就有
?fnftId:2?asset:WETH?depositAmount:2.0*1e18(1.5*1e18+0.5*1e18)
此时
?01-FNFT.totalSupply:4001-FNFT.depositAmount:1.5*1e18?02-FNFT.totalSupply:1002-FNFT.depositAmount:2.0*1e18
三.quantity>01-FNFT.totalSupply()
这种情况，交易会revert。
1.What'ttheRe-entrancyvulnerability
在理解了mintAddressLock函数和depositAdditionalToFNFT函数的基本工作流程后，来看一下攻击者使用的重入手法。假定thelastestfnftId=1
如图五所示第一步：攻击者调用mintAddressLock函数
?depositAmount=0
?quantities=
mint出了2枚01-FNFT,由于攻击者将depositAmount设置为0，因此他没有转入任何数字资产。相当于01-FNFT背后承载的underlyingasset为0。
第二步：攻击者再次调用mintAddressLock函数
?depositAmount=0
?quantities=准备mint36w枚02-FNFTdepositAmount为0。
在mint的最后一步，攻击者利用ERC-1155的call-back机制重入了depositAdditionalToFNFT函数。
在depositAdditionalToFNFT中，攻击者传入
?quantity=1
?amount=1*1e18
?fnftId=1
因为quantity<fntfId.totalSupply(),因此协议会burn掉攻击者1枚01-FNFT,铸造1枚02-FNFT。(02-FNFT在协议中已经存在，但是fnftId更新延迟)然后修改fnftId=2的depositAmount为amount。相信你已经发现，这一步，攻击者通过重入将fnftId=2的depositAmount从0修改为1.0*1e18,仅仅花费1*1e18RENA就获得了(360000+1)*1*1e18RENA的系统记账。
最后攻击者调用withdrawNFNFT函数，burn掉360,001枚02-FNFT,取走了360,001*1e18RENA。
建议修复方法
2.theNewZero-dayVulnerability
在blockSecTeam团队分析RevestFinance的代码时，handleMultipleDeposits函数引起了我们的注意。
当用户调用depositAdditionToNFT函数追加抵押物时，该函数会改变FNFT的depositAmount。从代码中我们可以发现，当newFNFTId!=0时，该函数既改变了fnftId对应的FNFT的depositAmount也改变了newFNFTId对应的depositAmount。
按照常理，当newFNFTId!=0时，系统应该只记录newNFTId对应的depositAmount。不应该改变fnftId对应的depositAmount。
我们认为这是一个非常严重的逻辑bug，利用该漏洞，攻击者可以很轻松提走系统中的数字资产。下面用3张图描述模拟攻击的原理。假定thelatestfnftId=1
首先攻击者调用mintAddressLock函数，mint出360000个01-FNFT。攻击者将amount设置为0因此他不必转入任何资产到RevestFinance协议中。mint结束后，攻击者拥有360000枚depositAmount=0的01-FNFT。
然后攻击者调用depositAdditionalToFNFT函数，参数如下
?fnftId=1
?amount=1*1e18
?quantity=1
协议转走攻击者amount*quantity数量的代币，即1*1e18RENA协议会burn掉攻击者1枚01-FNFT,并为其铸造一枚02-FNFT按照handleMultipleDeposits函数中的逻辑，fnftId=2的资产，其depositAmount会被设置为1.0*1e18。但是fnftId=1的资产，其depositAmount也会被设置为1.0*1e18，而这个值本应该为0！
第三步，攻击者直接提款，将手中所有的01-FNFT提现。不考虑gas费，他将净赚359,999*1e18数量的REAN代币。
很显然，使用这种方式进行攻击，比真实的重入攻击更加简单直接。
建议修复方法
针对该漏洞，blockSecTeam团队给出了相应的patch方法。
3.项目方的修复方式
由于TokenVaultandFNFTHandler两个漏洞合约存储了许多关键的状态，无法在短时间内重新部署它们，为了快速恢复使用，RevestFinance官方重新部署了Revest合约(https://etherscan.io/address/0x36c2732f1b2ed69cf17133ab01f2876b614a2f27#code)的精简版本。该版本关闭了大部分复杂的功能，以避免被进一步攻击。项目方将在未来迁移状态并重新部署修复过的合约。
4.总结
提升DeFi项目的安全性不是一件容易的事情。除了代码审计，我们认为社区应该采取更加主动的方式，例如项目监控预警、甚至是攻击阻断使得DeFi社区更加安全。(https://mp.weixin.qq.com/s/o41Da2PJtu7LEcam9eyCeQ).
参考文献
*:https://blocksecteam.medium.com/revest-finance-vulnerabilities-more-than-re-entrancy-1609957b742f
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。