编者按：本文来自慢雾科技，Odaily星球日报授权转载。前言
据链闻消息，DeFi项目YFValue发布公告称，团队于昨日在YFV质押池中发现一个漏洞，恶意参与者借此漏洞对质押中的YFV计时器单独重置。目前已有一个恶意参与者正试图借此勒索团队。慢雾安全团队对此进行了深入分析，以下是相关技术细节。细节分析
以上是YFValue的官方说明(来源：https://medium.com/)，从声明中我们可以得知是YFV抵押池出现了问题，恶意的用户可重置YFV抵押者的计时器，对YFV的抵押者造成不便，但这并不会导致资金损失。通过登陆YFValue的官方网站，(https://yfv.finance/staking)，可以发现在YFValue的体系中，用户可通过质押相关的代币获取对应的奖励，目前YFValue支持的质押代币池有以下几个：
可以看到，目前由于漏洞的原因，YFV的抵押池已经在UI界面关闭了抵押功能，但是合约上目前还没关闭代币抵押的功能，我们需要跟踪代码来分析具体的细节点。根据官网提供的Github地址，我们溯源到了相关的代码仓库(https://github.com/yfv-finance/audit)，关于YFV抵押的相关逻辑在YFV_Stake.sol合约中，合约中关于抵押的函数有2个，分别是stake函数和stakeOnBehalf函数，以下是具体的代码：
通过代码不难发现，无论是stake函数还是stakeOnBehalf函数，逻辑基本是一样的，首先是校验了抵押金额不能为0，接着分别调用上层的tokenStake和tokenStakeOnBehalf函数。紧接着更新用户的抵押时间。只不过stakeOnBehalf函数可以用于为他人抵押。tokenStake和tokenStakeOnBehalf的代码如下：
可以看到这里只是简单的把对应的token用transferFrom的方式转入到合约中，没有什么特别的逻辑点。到这里整个抵押流程就很清晰了，接下来是收益的过程。计算用户收益的是stakeReward函数，领取收益的为withdraw函数，代码分别如下：
通过分析计算收益和领取收益的代码，发现逻辑也很简单，stake函数首先是通过updateReward修饰器更新了用户的奖励，然后使用getReward函数计算了用户的奖励，并把抵押时间设置成当前区块时间。最后，用户在提取奖励的时候，withdraw函数会首先计算当前的区块时间，再与unfrozenStakeTime函数中计算出的时间进行对比，只有当前区块时间大于unfrozenStakeTime计算出的时间，才允许提现。unfrozenStakeTime的代码如下：
从代码中得知，unfrozenStakeTime是使用用户的上次抵押时间加上FROZEN_STAKING_TIME常量得出锁定时间，只要超过时间，就能通过withdraw函数提现收益。整个抵押和领取收益的简化流程如下：
分析了一大堆，回到我们最初的问题，恶意的用户是怎么锁定其他用户的资产的呢？回到用户抵押的逻辑，可以发现抵押逻辑中的stakeOnBehalf函数本意是帮助进行抵押，但是这里有个问题，如果这个用户先前已经有抵押了呢？那通过对已经抵押的用户再次进行抵押，比方说抵押1个YFV，是不是就能以极低的成本重置已抵押的用户的计时器，导致用户在withdraw时无法成功调用。更进一步，假设YFV抵押用户已经成功调用了stakeReward函数，在快要达到unfrozenStakeTime所规定的时间时，恶意的用户可以通过stakeOnBehalf函数给这个用户抵押少量资产，即可再次对抵押奖励进行锁定，理论上这样往复循环，即可使用户无法取出自己的资产，但这个问题并不会导致资金损失。攻击流程如下：
前车之鉴
这是本月出现的第二个没有经过审计的DeFi项目所暴露出的风险，根据YFValue的官方声明(https://medium.com/)，项目代码是由富有经验的开发者进行开发的，同时借鉴了其他成功的项目的代码，但是仍无可避免的出现了风险。术业有专攻，安全审计一方面需要项目方的正向思维，另一方面，还是需要专业的安全团队的逆向思维，从专业的黑客角度进行模拟对抗，发现问题。修复方案
通过分析代码和漏洞细节，针对本次漏洞，修复方案也很简单，只要在抵押的时候检查用户的抵押状态是否为已经抵押，如果已经抵押，则不允许再次抵押。或者对每次的抵押进行单独的处理，不能对先前的抵押状态产生影响。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。