Cover协议被黑简要分析:一次由存储状态引发的惨案

  • Cover协议于2020年12月29日遭遇黑客攻击,导致其代币价格暴跌,慢雾安全团队对此事件进行了分析。
  • 攻击者利用Blacksmith合约中的deposit和withdraw函数进行多次操作,通过updatePool函数更新池子并记录累计奖励。
  • 问题核心在于rewardWriteoff参数的计算错误,攻击者在第二次操作时获取了旧的Pool值,导致accRewardsPerToken记录不准确。
  • 由于新旧参数差值,攻击者在claimRewards时获得了比实际更多的奖励,导致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参数差值变化如下图:

分享至:

作者:PA荐读

本文为PANews入驻专栏作者的观点,不代表PANews立场,不承担法律责任。

文章及观点也不构成投资意见

图片来源:PA荐读如有侵权,请联系作者删除。

关注PANews官方账号,一起穿越牛熊
推荐阅读
6小时前
2025-12-13 03:43
2025-12-12 09:46
2025-12-12 06:00
2025-12-10 13:00
2025-12-10 10:25

热门文章

行业要闻
市场热点
精选读物

精选专题

App内阅读