CertiK: 傷害保険を販売した保険会社も事故に遭ったのですか？カバープロトコルの脆弱性分析
最近、地域に野良犬が出没し、近所のお子さんがその犬を見て驚いて逃げたが、追いかけられて逆に犬に噛まれたと聞きました。
幸いなことに、両親は機知に富んで子供に傷害保険をかけてくれたので、狂犬病ワクチンの数回の注射にはそれほど費用はかかりませんでした。
通貨国民として、残念ながら暗号化資産が盗難に遭ったとしても、プロジェクト当事者またはあなたが個人的に保険に加入した場合、保険会社が紛失した資産を返済してくれるので安心できます。
しかし、最悪の状況が存在します。しかし、保険会社ですらセキュリティインシデントが発生し、攻撃されたらどうなるでしょうか?
テクニカル分析
攻撃者は、プロジェクトのスマート コントラクトの誓約と取得を繰り返し、トークンの鋳造操作をトリガーし、カバー トークンを無限に発行し、カバー トークンの価格の暴落を引き起こしました。
テクニカル分析
主な攻撃は次のステップに分かれています。
① 合計2,573 DAIの流動性をバランサープールに提供
②攻撃者は、バランサープールに流動性を提供することで、約132,688個のバランサー流動性証明トークンBPTを取得しました。
図1: blacksmith.solのdeposit()関数
デポジット関数を呼び出すことにより、攻撃者は取得した BPT 流動性証明をカバー プロトコルにプレッジします。
まず、図 1 の行 118 を介して現在の流動性プルーフ トークンのプール データをメモリに読み取り、次に行 121 を呼び出して現在のプールのデータを更新します。
次に、図 3 の行 318 に示すように、deposit() は、_claimCoverRewards() 関数を呼び出すことによって、一定数のカバー トークンを関数呼び出し元 (msg.sender) にキャストします。
鋳造されたカバー トークンの数は、pool.accRewardsPerToken、CAL_MULTIPLIER、miner.rewardWriteoff の 3 つの変数に関連します。
ここでの pool.accRewardsPerToken の値は、図 2 の update() 関数を使用して更新された値ではなく、メモリに格納されているプール データを使用することに注意してください。
同時に、図 1 のデポジット関数から、miner.rewardWriteoff の値の更新は、_claimCoverRewards() 関数の実行完了後に発生することがわかります。
したがって、元の設計では、miner.rewardWriteoff の更新された値を使用して、鋳造する必要があるカバー トークンの数を計算する必要がありますが、ここでは、miner.rewardWriteoff の未更新のデータが誤って使用され、実際の鋳造数が計算されます。発行されたトークンの数よりもカバートークンの数が多くなり、その数が増加し、最終的にはトークンの発行につながりました。
誓約が成功すると、攻撃者は blacksmith.sol スマート コントラクトのdraw() 関数を呼び出して、誓約された BPT を取得し、追加の鋳造されたカバー トークンを取得して攻撃を完了します。
デポジット() 関数とwithdraw() 関数を実行した後のトークン残高テーブルを比較すると、この一連のデポジット関数と引き出し関数を呼び出した後、攻撃者は約 704 個の COVER トークンを取得できることがわかります。
デポジット()後:
draw()の後:
攻撃後、この記事の時点で、公式カバーは blacksmith を安全なバージョンに移行しました。
脆弱な鍛冶屋の住所:
0xe0b94a7bb45dd905c79bb1992c9879f40f1caed5
一時的な修正後の鍛冶屋の住所:
0x1d5fab8a0e88020309e52b77b9c8edf63c519a26
一時的に修復された鍛冶屋契約は、攻撃者が攻撃を続けるのを防ぐために、すべての誓約および引き出し操作を一時的に禁止します。
この攻撃で、攻撃者は総額 440 万米ドル、つまり約 2,900 万元の利益を得ました。
この脆弱性を利用して同様の攻撃を仕掛ける攻撃者は他にも存在しており、例えば Grap.finance プロジェクト関係者はこの脆弱性を利用した攻撃に参加し、4,350 ETH トークンを獲得しました。
安全上のアドバイス
安全上のアドバイス
CertiK セキュリティ製品の詳細情報にアクセスするには、CertiK Foundation の公式 Web サイトにアクセスしてください。
