?More than Re-entrancy : Revest Finance 被攻击事件分析-ODAILY

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

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:15ms0-3:693ms