作者: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),項目代碼是由富有經驗的開發者進行開發的,同時藉鑑了其他成功的項目的代碼,但是仍無可避免的出現了風險。術業有專攻,安全審計一方面需要項目方的正向思維,另一方面,還是需要專業的安全團隊的逆向思維,從專業的黑客角度進行模擬對抗,發現問題。

修復方案

通過分析代碼和漏洞細節,針對本次漏洞,修復方案也很簡單,只要在抵押的時候檢查用戶的抵押狀態是否為已經抵押,如果已經抵押,則不允許再次抵押。或者對每次的抵押進行單獨的處理,不能對先前的抵押狀態產生影響。