BTC
ETH
HTX
SOL
BNB
查看行情
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

DeFi保險業新秀COVER遭攻擊,保險業如何保障自己?

PeckShield
特邀专栏作者
本文約1311字,閱讀全文需要約2分鐘
保險公司被攻擊了,該怎麼辦?
AI總結
展開
保險公司被攻擊了,該怎麼辦?
進入9 月後,隨著DeFi 協議流動性挖礦收益銳減,DeFi 市場開始歸於沉寂,探索者們向更深廣的領域進發。

11 月,憑藉Yearn.finance 創始人Andre Cronje(AC)的加持,以及治理代幣的大漲,去中心化保險Cover Protocol 嶄露頭角,引領DeFi 保險站在了聚光燈下。

有觀點認為:“ DeFi 保險項目不僅可以減輕投保人的損失,也讓人們可以更放心地參與DeFi,且有助於健全DeFi 生態。”

然而,就在DeFi 保險的概念越炒越熱時,Cover Protocol 在短時內遭到兩次攻擊,其代幣價格經歷了一場令人驚心動魄過山車。

2020 年12 月28 日,DeFi 保險項目Cover Protocol 疑似遭到黑客攻擊,其代幣價格在攻擊的影響下從700 多美元一度暴跌至最低9 美元。
PeckShield (派盾)通過追踪和分析發現,該攻擊主要是由於業務邏輯錯誤,導致誤算質押用戶獎勵,並在不同DEX 拋售套利。
首先在一段運行時間內,攻擊者先給Blacksmith 打一些LP token,然後直接調用函數updatePool(),通過異常的pool.accRewardsPerToken 來計算COVER 的獎勵;

隨後通過125 和126 行的函數_claimCoverRewards() 和_claimBonus() 記錄挖礦者的獎勵;
最後記錄挖礦者的狀態,包括質押的數量和代碼128 行至131 行所示的函數rewardWriteoff 和函數bonusWriteoff 。
具體而言,當前協議利用pool.accRewardsPerToken 來計算第130 行的miner.amount.mul(pool.accRewardsPerToken).div(CAL_MULTIPLIER) ,由於118 行的pool 類型為memory, 而121 行的函數updatePool()並未對其進行更新,導致最終計算出來的rewardWriteoff 比預期的數額小。
當下一次同一用戶獲取質押獎勵時,質押合約例如Blacksmith 將會鑄造更多的COVER,這將大大提升鑄幣數量。目前,在流通量中鑄造了逾40,000,000,000,000,000,000 枚COVER。
第二次攻擊者被網絡標記為Grap Finance 白帽子的地址,在獲利後,他們將所得收益還給了Cover 團隊,銷毀了剩餘的COVER ,並留言:下一次,管好你自己的事。

有評論稱,白帽子Grap Finance 是DeFi 義俠,將4350 ETH 還給了COVER 團隊。但通過砸盤,讓眾多的投資者血本無歸,這也引起了不少的爭議。
對於DeFi 保險項目而言,其初衷是為其他DeFi 項目降低風險損失。隨著DeFi 生態的壯大,以及鎖倉值持續增長,DeFi 項目遭到黑客覬覦,特別是新興的DeFi 保險項目,理應加強安全防護。如今由於自身漏洞遭到黑客攻擊,這樣的保險項目是否能幫助用戶抵禦風險有待考察。
在DeFi 的世界裡,崇尚“代碼即法律”(Code is Law),項目方不僅要將代碼做到極致,還要防患於未然,DeFi 協議開發者應在攻擊發生後,自查代碼。 PeckShield(派盾)提示,如果對此不了解,應找專業的審計機構進行審計和研究。

COVER
DeFi
安全
歡迎加入Odaily官方社群