一次由存儲狀態引發的慘案 Cover協議被黑簡要分析

By :  Kong@慢霧安全團隊

據慢霧區情報，2020 年 12 月 29 日，Cover 協議價格暴跌。慢霧安全團隊第一時間跟進相關事件並進行分析，以下為分析簡略過程。

攻擊流程簡析

1、在 Cover 協議的 Blacksmith 合約中，用戶可以通過 deposit 函數抵押 BPT 代幣；

2、攻擊者在第一次進行 deposit - withdraw 後將通過 updatePool 函數來更新池子，並使用 accRewardsPerToken 來記錄累計獎勵；

3、之後將通過 _claimCoverRewards 函數來分配獎勵並使用 rewardWriteoff 參數進行記錄；

4、在攻擊者第一次 withdraw 後還留有一小部分的 BPT 進行抵押；

5、此時攻擊者將第二次進行 deposit，並通過 claimRewards 提取獎勵；

6、問題出在 rewardWriteoff 的具體計算，在攻擊者第二次進行 deposit - claimRewards 時取的 Pool 值定義為 memory，此時 memory 中獲取的 Pool 是攻擊者第一次 withdraw 進行 updatePool 時更新的值；

7、由於 memory 中獲取的 Pool 值是舊的，其對應記錄的 accRewardsPerToken 也是舊的會賦值到miner；

8、之後再進行新的一次 updatePool 時，由於攻擊者在第一次進行 withdraw 後池子中的 lpTotal 已經變小，所以最後獲得的 accRewardsPerToken 將變大；

9、此時攻擊者被賦值的 accRewardsPerToken 是舊的是一個較小值，在進行 rewardWriteoff 計算時獲得的值也將偏小，但攻擊者在進行 claimRewards 時用的卻是池子更新後的 accRewardsPerToken 值；

10、因此在進行具體獎勵計算時由於這個新舊參數之前差值，會導致計算出一個偏大的數值；

11、所以最後在根據計算結果給攻擊者鑄造獎勵時就會額外鑄造出更多的 COVER 代幣，導致 COVER 代幣增發。

具體 accRewardsPerToken 參數差值變化如下圖：

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。