DeFi 項目 YFValue （YFV）發佈通知，在 YFV 質押池中發現一個漏洞，惡意的用戶可重置 YFV 抵押者的計時器，對 YFV 的抵押者造成不便，但這並不會導致資金損失。這是本月出現的第二個沒有經過審計的 DeFi 項目所暴露出的風險。本文動區專欄作者 慢霧科技 SlowMist 撰稿。
（前情提要：挖蕃薯崩潰風波｜技術解析：YAM 的「一行程式碼」如何蒸發數億美元？）
DeFi 項目 YFValue （YFV）昨發佈公告稱，團隊於前日在 YFV 質押池中發現一個漏洞，惡意參與者藉此漏洞對質押中的 YFV 計時器單獨重置。
目前已有一個惡意參與者正試圖藉此勒索團隊。筆者對此進行了深入分析，以下是相關技術細節。
細節分析
以上是 YFValue 的官方說明，從聲明中我們可以得知是 YFV 抵押池出現了問題，惡意的用戶可重置 YFV 抵押者的計時器，對 YFV 的抵押者造成不便，但這並不會導致資金損失。
通過登陸 YFValue 的官方網站，可以發現在 YFValue 的體系中，用戶可通過質押相關的代幣獲取對應的獎勵，目前YFValue支持的質押代幣池有以下幾個：
可以看到，目前由於漏洞的原因，YFV 的抵押池已經在 UI 介面關閉了抵押功能，但是合約上目前還沒關閉代幣抵押的功能，我們需要跟蹤程式碼來分析具體的細節點。
根據官網提供的 Github 地址，我們溯源到了相關的程式庫，關於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 函數給這個用戶抵押少量資產，即可再次對抵押獎勵進行鎖定。
理論上這樣往復循環，即可使用戶無法取出自己的資產，但這個問題並不會導致資金損失。攻擊流程如下：
前車之鑑
這是本月出現的第二個沒有經過審計的 DeF i項目所暴露出的風險，根據 YFValue 的官方聲明，項目程式碼是由富有經驗的開發者進行開發的，同時借鑑了其他成功的項目的程式碼，但是仍無可避免的出現了風險。術業有專攻，安全審計一方面需要項目方的正向思維，另一方面，還是需要專業的安全團隊的逆向思維，從專業的駭客角度進行模擬對抗，發現問題。
修復方案
通過分析程式碼和漏洞細節，針對本次漏洞，修復方案也很簡單，只要在抵押的時候檢查用戶的抵押狀態是否為已經抵押，如果已經抵押，則不允許再次抵押。或者對每次的抵押進行單獨的處理，不能對先前的抵押狀態產生影響。
📍相關報導📍
「對不起，我失敗了」Yam Finance沈痛宣告項目死亡幣暴跌99%，待2.0再出發
dForce AMA 總整理｜ 還原 Lendf.Me 遭駭始末，坦言考慮部分中心化機制
資安報告｜DeFi 樂高下的米蘭諾鬆塔：Uniswap 和 Lendf.Me 遭駭始末
讓動區 Telegram 新聞頻道再次強大！！立即加入獲得第一手區塊鏈、加密貨幣新聞報導。
LINE 與 Messenger 不定期為大家服務
