作者：yudan@慢霧安全團隊
DeFi 項目YFValue （YFV）發佈公告稱，團隊於昨日在YFV 質押池中發現一個漏洞，惡意參與者藉此漏洞對質押中的YFV 計時器單獨重置。目前已有一個惡意參與者正試圖藉此勒索團隊。慢霧安全團隊對此進行了深入分析，以下是相關技術細節。
細節分析
以上是YFValue 的官方說明(來源：https://medium.com/@yfv.finance/yfv-update-staking-pool-exploit-713cb353ff7d)，從聲明中我們可以得知是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 函數，以下是具體的代碼：
function stake(uint256 amount, address referrer) public updateReward(msg.sender) checkNextEpoch { require(amount > 0, "Cannot stake 0"); require(referrer != msg.sender, "You cannot refer yourself."); super .tokenStake(amount); lastStakeTimes[msg.sender] = block.timestamp; emit Staked(msg.sender, amount); if (rewardReferral != address(0) && referrer != address(0)) { IYFVReferral(rewardReferral) .setReferrer(msg.sender, referrer); } } function stakeOnBehalf(address stakeFor, uint256 amount) public updateReward(stakeFor) checkNextEpoch { require(amount > 0, "Cannot stake 0"); super.tokenStakeOnBehalf(stakeFor, amount); lastStakeTimes[stakeFor] = block.timestamp; emit Staked(stakeFor, amount); }
通過代碼不難發現，無論是stake 函數還是stakeOnBehalf 函數，邏輯基本是一樣的，首先是校驗了抵押金額不能為0，接著分別調用上層的tokenStake 和tokenStakeOnBehalf 函數。緊接著更新用戶的抵押時間。只不過stakeOnBehalf 函數可以用於為他人抵押。 tokenStake 和tokenStakeOnBehalf 的代碼如下：
function tokenStake(uint256 amount) internal { _totalSupply = _totalSupply.add(amount); _balances[msg.sender] = _balances[msg.sender].add(amount); yfv.safeTransferFrom(msg.sender, address(this), amount ); } function tokenStakeOnBehalf(address stakeFor, uint256 amount) internal { _totalSupply = _totalSupply.add(amount); _balances[stakeFor] = _balances[stakeFor].add(amount); yfv.safeTransferFrom(msg.sender, address(this) , amount); }
可以看到這裡只是簡單的把對應的token 用transferFrom 的方式轉入到合約中，沒有什麼特別的邏輯點。到這裡整個抵押流程就很清晰了，接下來是收益的過程。計算用戶收益的是stakeReward 函數，領取收益的為withdraw 函數，代碼分別如下：
function stakeReward() public updateReward(msg.sender) checkNextEpoch { uint256 reward = getReward(); require(reward > 0, "Earned too little"); super.tokenStake(reward); lastStakeTimes[msg.sender] = block.timestamp ; emit Staked(msg.sender, reward); } function withdraw(uint256 amount) public updateReward(msg.sender) checkNextEpoch { require(amount > 0, "Cannot withdraw 0"); require(block.timestamp >= unfrozenStakeTime(msg .sender), "Coin is still frozen"); super.tokenWithdraw(amount); emit Withdrawn(msg.sender, amount); }
通過分析計算收益和領取收益的代碼，發現邏輯也很簡單，stake 函數首先是通過updateReward 修飾器更新了用戶的獎勵，然後使用getReward 函數計算了用戶的獎勵，並把抵押時間設置成當前區塊時間。最後，用戶在提取獎勵的時候，withdraw 函數會首先計算當前的區塊時間，再與unfrozenStakeTime 函數中計算出的時間進行對比，只有當前區塊時間大於unfrozenStakeTime 計算出的時間，才允許提現。 unfrozenStakeTime 的代碼如下：
function unfrozenStakeTime(address account) public view returns (uint256) { return lastStakeTimes[account] + FROZEN_STAKING_TIME; }
從代碼中得知，unfrozenStakeTime 是使用用戶的上次抵押時間加上FROZEN_STAKING_TIME 常量得出鎖定時間，只要超過時間，就能通過withdraw 函數提現收益。整個抵押和領取收益的簡化流程如下：
分析了一大堆，回到我們最初的問題，惡意的用戶是怎麼鎖定其他用戶的資產的呢？
回到用戶抵押的邏輯，可以發現抵押邏輯中的stakeOnBehalf 函數本意是幫助進行抵押，但是這裡有個問題，如果這個用戶先前已經有抵押了呢？那通過對已經抵押的用戶再次進行抵押，比方說抵押1 個YFV，是不是就能以極低的成本重置已抵押的用戶的計時器，導致用戶在withdraw 時無法成功調用。更進一步，假設YFV 抵押用戶已經成功調用了stakeReward 函數，在快要達到unfrozenStakeTime 所規定的時間時，惡意的用戶可以通過stakeOnBehalf 函數給這個用戶抵押少量資產，即可再次對抵押獎勵進行鎖定，理論上這樣往復循環，即可使用戶無法取出自己的資產，但這個問題並不會導致資金損失。攻擊流程如下：
前車之鑑
這是本月出現的第二個沒有經過審計的DeFi 項目所暴露出的風險，根據YFValue 的官方聲明(https://medium.com/@yfv.finance/yfv-bringing-true-value-to- yield-farming-bddc4edf889a)，項目代碼是由富有經驗的開發者進行開發的，同時藉鑑了其他成功的項目的代碼，但是仍無可避免的出現了風險。術業有專攻，安全審計一方面需要項目方的正向思維，另一方面，還是需要專業的安全團隊的逆向思維，從專業的黑客角度進行模擬對抗，發現問題。
修復方案
通過分析代碼和漏洞細節，針對本次漏洞，修復方案也很簡單，只要在抵押的時候檢查用戶的抵押狀態是否為已經抵押，如果已經抵押，則不允許再次抵押。或者對每次的抵押進行單獨的處理，不能對先前的抵押狀態產生影響。
APP 
