DeFiネットワークセキュリティ状況レポート

最近、DeFiのセキュリティインシデントが頻繁に発生しています。国家ブロックチェーン脆弱性データベースに記録されているセキュリティインシデントには、無制限のトークンを発行したshroom.financeプロジェクト、Unicatsプロジェクトの認証攻撃、Balancerプロジェクト攻撃、AkropolisとOUSDが再びハッカーに攻撃されたことなどが含まれています。

最近、DeFiのセキュリティインシデントが頻繁に発生しています。国家ブロックチェーン脆弱性データベースに記録されているセキュリティインシデントには、無制限のトークンを発行したshroom.financeプロジェクト、Unicatsプロジェクトの認証攻撃、Balancerプロジェクト攻撃、AkropolisとOUSDが再びハッカーに攻撃されたことなどが含まれています。 DeFi エコシステムのセキュリティ脅威リスクレベルは高いです。

1. DeFiの現在の全体的な発展

2017年12月、世界初のDeFiプロジェクトMakerが正式に開始されました。 DeFiは今年、特に6月から11月にかけて急速な発展を遂げ、DeFiロック資産の価値は10億ドルから約180億ドルに増加し、1,700%増加しました。ピーク時にはプロジェクト数が500を超えました。現在、DeFiの主な商品タイプには、貸付市場、分散型取引所（DEX）、デリバティブ、決済ネットワーク、トークン化された資産などがあります。また、目的やトークンの特性に応じて、DeFiにはインフラストラクチャ、データサービス、ウォレット、ステーブルコインなどのカテゴリもあります。

図1. 主要なDeFiプロジェクトタイプ別の総ロック価値（TVL）シェア

DeFiプロジェクトが急速に発展するにつれ、DeFiを取り巻くさまざまなセキュリティインシデントが頻繁に発生し始めています。

2. DeFiのセキュリティ状況

（I）さまざまなチェーンプラットフォーム上のDeFiのセキュリティ状況 国家ブロックチェーン脆弱性データベースは今年からDeFiのセキュリティインシデントをカウントしており、セキュリティインシデントの82.61％がイーサリアムで発生しました。 TRONブロックチェーンは6.52%、EOSブロックチェーンは4.35%、その他のブロックチェーンは6.52%を占めています。

図2: さまざまなブロックチェーンにおけるDeFiセキュリティインシデントの割合

（II）DeFiプロジェクトのセキュリティ上の問題 1. 無制限発行問題 無制限発行とは、スマートコントラクトに脆弱性が存在し、発行機能を不正に呼び出すことで、攻撃者が自由にコインを発行できる状態を指します。

DeFi プロジェクトの当事者は、ミンター権限を追加することで追加のトークンを発行できます。さらに、コインを発行する権限を持つべきガバナンスコントラクトアドレスが、プロジェクト当事者が保有する外部アドレスに置き換えられ、プロジェクト当事者が無期限にコインを発行できるようになるケースもあります。一部のプロジェクト所有者はタイムロックを記述しなかったため、コインの増加は時間によって制限されず、無期限にコインを増やすことができました。たとえば、DeFi プロジェクト shroom.finance では時間ロックが設定されていないため、トークンの発行は無制限になっています。

2. 認可攻撃の問題 認可攻撃とは、攻撃者が契約ロジックの抜け穴を悪用して、他のユーザーが認可した契約権限を取得し、ユーザーのトークンを自由に転送することを意味します。

投資家がDeFiプロジェクトに参加する場合、便宜上、その後の操作で繰り返し承認が行われないように、通常、すべてのトークンを契約アドレスに承認する必要があります。たとえば、ユーザーが特定のトークンを 1,000 万所有しているとしても、契約では送金のたびに 1,000 万を使用するわけではありません。この場合、契約の譲渡ごとにユーザーの署名が必要になります。最初に契約アドレスに 1000 万を許可しておけば、不要な繰り返し操作を回避できます。しかし、悪意のある人物が契約権限を悪用し、ERC20トークン内のtransferFrom関数を呼び出してプロキシ転送を実装すると、すると、ユーザーのウォレット内のすべてのトークンが攻撃者によって自由に操作される可能性があります。詐欺プロジェクト「Unicats」では、プロジェクト所有者が、アドレスのホワイトリストに相当する、判定条件を回避できる権限を残しており、契約IDを使用して取引を開始し、ユーザーの資産を自由に盗むことが可能となっている。

図3: 攻撃コードの部分スクリーンショット

現状では、ほぼすべてのプロジェクト関係者が、フロントエンドやその他の場所で、ユーザー認可量をデフォルトで最大値（2^256）に設定することになります。ある契約（A）が他の契約（B）を呼び出す場合、契約（B）も承認する必要がありますが、使用する分だけ承認するという方法が使われることが多いです。したがって、投資家として私たちは、攻撃者の「罠」に陥らないように、DeFi プロジェクトの承認問題に細心の注意を払わなければなりません。

3. 裁定取引の問題 裁定取引とは、同じ仮想デジタル通貨資産を同時に売買することで利益を得る方法です。これは、異なる取引所における同じ仮想デジタル通貨資産の価格設定の違いを利用します。特に、仮想デジタル通貨資産の発行初期段階では、取引所間で流動性が大きく異なるため、取引所間の価格差を利用して裁定取引を行い、利益を得る機会が多くなります。

このような問題は主に、ビジネスがより複雑になる DeFi プロジェクトで発生します。たとえば、Balancer プロジェクトへの攻撃。攻撃者は、「フラッシュローン」、デフレ通貨、およびバランサートークンプールの「定積」ルールの特性を組み合わせ、デフレトークンSTAと「フラッシュローン」を使用して、STAが1ユニットのみの特殊な状況を作り出しました。プール内に STA と他のトークンが 1 ユニットしかない場合、STA の 1 ユニットのみを、より価値の高い他のトークンと交換できます。また、STA にはデフレ特性があり、譲渡時に一部のトークンが破棄されます (一般的には譲渡されたトークンの 1/100)。ただし、STA 1 単位が最小値であるため、STA 1 単位を譲渡すると STA 1 単位も破棄され、プール内の STA 数は変わりません。この操作を繰り返し実行することで、攻撃者は資金プールを空にすることができます。以下のように表示されます。

図4 攻撃プロセス

4. 再入攻撃 再入攻撃とは、コールバック関数を実行する際に攻撃者がコントラクトコードを乗っ取り、本来呼び出されるべきコールバック関数が悪意のあるコントラクトアドレスに置き換えられ、攻撃者が再度関数を呼び出せるようになる状況を指します。たとえば、転送を実行するはずの関数が 2 回呼び出されると、攻撃者は 2 倍の利益を得ることができます。

最近、DeFiプロトコルAkropolisがハッカーの攻撃を受けました。分析の結果、攻撃は主に、コントラクトがパラメータ検証を実行し、再入攻撃を防止できなかったことが原因で発生したことが判明しました。

攻撃者はまず、悪意のあるコントラクト アドレスを関数 deposit() にパラメータとして渡します。ここで、トークン アドレスのパラメータ位置が渡されます。これにより、トークンの safetransferFrom() 関数が実行されると、攻撃者の悪意のあるコントラクトが呼び出されます。攻撃プロセスは次のステップに分かれています。

1. deposit() 関数は最初に depositToProtocol() 関数を実行しますが、depositToProtocol() 関数には悪意を持って乗っ取られた safeTransferFrom() 関数があるため、このステップで攻撃コントラクトが実行されます。

2. 攻撃コントラクトでは、攻撃者は再度 deposit() 関数を呼び出しましたが、今回は渡されたパラメータは通常のトークン アドレスでした。今回、攻撃者は通常の入金操作のために実際の DAI を入金しました。

3. コードからわかるように、ミント関数は以前に残高差の計算を実行し、この差に基づいて硬貨の枚数が計算されます。今回、実際のDAIを預け入れることで残高が増加するため、攻撃者は預け入れたDAIと同等のプールトークンを取得することになります。

4. 悪意のあるコントラクトが実行された後、通常のコントラクトは、depositToProtocol() 関数の後のコードの実行を継続します。

5. 攻撃者は以前に DAI を預け入れているため、今回は再び預け入れた DAI に相当するプールトークンを取得し、資産を 2 倍にします。

攻撃者はこの一連の手法を使用して契約に対して複数の攻撃を仕掛け、最終的に200万DAIを超える利益を得ました。

図5 攻撃プロセス

たとえば、最近の OUSD 再突入攻撃では、攻撃者は再突入攻撃と弾力的な供給調整を利用して攻撃目的を達成しました。この攻撃では、攻撃者は dYdX フラッシュローンを通じて 70,000 ETH を借り入れ、その ETH を対応する USDT と DAI に交換しました。

1. 攻撃者はまず 750 万 USDT を Vault に送金し、Vault 内の価値のシェアを 50% 以上に増やしました。

2. コインを発行するためにコントラクト内の mintMultiple() 関数が呼び出され、2,050 万 DAI と悪意のあるコントラクトによって偽装された別のトークンがパラメータとして渡されます。この関数は通常 2,050 万 DAI を受け取ります。別のトークンを受信すると、攻撃者の悪意のあるコントラクトが実際に呼び出されます。攻撃者は、rebase() 呼び出しをトリガーするために、2,000 USDT を再度攻撃用コントラクトに入金して鋳造します。

3. 通常のコントラクトでは、資産を決済し、移転後に資産の合計値を更新してから、rebase() を通じて分配しますが、この時点でコントラクトはハイジャックされており、コントラクトにはまだ 2,050 万 DAI が Vault 資産の合計値に含まれていないため、rebase() が実行されると、2,050 万 DAI すべてが収入として分配されます。

4. 攻撃者は Vault 内の価値の 50% 以上を保有しているため、攻撃者には何もすることなく 1,025 万 DAI 以上が割り当てられます。その後、契約は正常に実行され、攻撃者は預けられた DAI と同額の oUSD.mint によって発行された OUSD トークンを受け取ります。

最終的に、攻撃者が得た利益の合計は約3,327万OUSDに相当しました。最後に、攻撃者は以前に預けたトークンを償還し、取得したトークンをフラッシュローンに戻します。

（III）DeFiセキュリティインシデントの原因国家ブロックチェーン脆弱性データベースは、ビジネスロジック実装の脆弱性、ビジネス設計の欠陥、プロジェクト関係者の逃走、再侵入攻撃、フィッシング詐欺など、DeFiセキュリティインシデントの主な原因を分析しています。詳細な原因分類を下図に示します。

図6 DeFiセキュリティインシデントの原因

さらに、DeFiセキュリティインシデントが頻繁に発生するもう1つの理由は、市場に多数の「模倣」プロジェクトが急速に出現していることです。これらのプロジェクトは、一般的に技術的基盤が弱い、事業設計が無理であるなどの問題を抱えており、中には詐欺的なプロジェクトではないかと疑われるものも存在します。次に、典型的な問題を次のように分析します。

1. ビジネス ロジック実装エラー いわゆるビジネス ロジック実装エラーとは、要件を満たすプログラムを作成するときに、コードの記述方法が間違っているために脆弱性が存在することを指します。 CherryFi プロジェクトの USDT ロックアップ イベントでは、転送ロジックが safeTransfer 関数を呼び出して特定の転送操作を実行しました。ただし、USDT 転送ロジックは値を返さないため、safeTransfer 呼び出しは成功せず、資金がロックされ、ユーザーは USDT を送金できなくなります。 CherryFi コードは監査されていないことが分かっています。

2. ビジネス設計上の欠陥 ビジネス設計上の欠陥とは、コードの記述上の問題ではなく、ビジネス設計プロセス中の不十分かつ厳密な検討によって生じるビジネス上の欠陥を指します。 DeFi プロジェクトでは、このような問題は主に取引ペアや弾性供給メカニズムに関連するロジックに反映され、悪意のある裁定取引の問題を引き起こす可能性が非常に高くなります。 Curve プロジェクトでは、変更前と変更後の変数 A の交換比率が矛盾すると、裁定機会が発生します。

図7 トークン結合曲線

上の図に示すように、Curve トークン プール内のさまざまなトークンの残高はこの曲線を満たす必要があります。この裁定取引空間の形成プロセスをさらに説明するために、トークン X が USDT であり、トークン Y が別のトークンであると仮定します。 A=1（青い曲線）の場合、ユーザーは保有するすべての USDT とトークン Y をトークン Y に交換します。図の赤い点に示すように、交換前にプールに 150 USDT と 50 トークン Y があると仮定します。この点は青い曲線上にあり、150対50（1.5:0.5）の比率が維持されています。ユーザーは50 USDTを保有しています。現在の曲線によれば、ユーザーが 50 USDT を使用してトークン Y を交換する場合、プールには 200 USDT が存在することになります。比率が青い曲線上にあることを確認するために、赤い点は黄色い点に移動し、対応する比率は 200:30 (2:0.3) になるため、50 USDT を 20 トークン Y と交換できます。

A=10（赤い曲線）のとき、プールの現在の残高は200 USDTと30 Token Yであると仮定します。この時点で、保有している20 Token Yを使用してUSDTに交換します。現時点では、プールには 50 個のトークン Y があります。赤い曲線の比率を満たすには、黄色の点が緑の点に移動し、プールの残高は 140 USDT と 50 Token Y になるはずです。つまり、20 Token Y を 60 USDT に交換できるので、10 USDT の利益が得られます。これは、変更前と変更後の A によって形成される裁定空間です。

3. コード エラー コード エラーは通常、プログラマーの不注意によりコード記述エラーが発生するため、コード記述時に発生します。この問題はプロジェクトにとって壊滅的な影響を与える可能性があります。たとえば、コーディング エラーにより、YAM プロジェクトは弾性供給計算プロセス中に精度で除算するのを忘れました (下の図を参照)。その結果、契約で保持されるトークンが多すぎます。ガバナンスには投票が必要です。提案を開始するには、提案者が提案を成功させるために総トークンの 1% を寄付する必要があります。トークンの総数が多すぎると、担保として必要なトークンの量が膨大になり、提案に必要なトークンを誰も購入できなくなります。結局、プロジェクト側はプロジェクトの終了を発表せざるを得ませんでした。

図8 いくつかのエラーコードのスクリーンショット

最後に、DeFi 業界の急速な発展に伴い、ますます多くの組み合わせイノベーションが DeFi プロジェクトに適用されていますが、セキュリティ テストやセキュリティ監査中に組み合わせ後のリスクを発見することが難しいことがよくあります。例えば、Lendf.me 攻撃では、プロジェクトのビジネス ロジックや ERC777 自体には問題はなかったものの、それらを組み合わせたときに再入可能性の脆弱性が存在していました。組み合わせリスクの問題は、ブロックチェーン セキュリティ業界のさまざまなメーカーによってまだ解決される必要があります。

3. 結論現在の DeFi プロジェクトはまだ開発の初期段階にあり、スキルや技術的条件のレベルはさまざまです。まず、一部の DeFi プロジェクトは専門的なコードセキュリティ監査を受けていません。第二に、ブロックチェーン技術の特性を無視し、従来の金融集中型システムの経験に基づいてのみ構築しています。第三に、ブロックチェーンアプリケーションの中には真正性が検証されていないものもあり、デジタル資産投資や財務管理などのトリックを使って犯罪者に騙されるリスクがあります。一部のプロジェクト関係者が大量のデジタル資産をアドレスに転送していることも判明しており、関係者の緊急の対応が必要です。要約すると、DeFi エコシステムのセキュリティ脅威リスクレベルは高いです。

国家ブロックチェーン脆弱性データベースは、国家インターネット緊急センターによって運営されています。ブロックチェーンセキュリティベンダー、ホワイトハット、ブロックチェーン企業などに対し、ブロックチェーンセキュリティエコシステムの構築に参加するよう呼びかけ、指導することで、中国におけるブロックチェーンの脆弱性やセキュリティインシデントの発見、分析、早期警告、全体的な研究レベル、緊急対応能力を向上させ、中国のブロックチェーン業界のセキュリティ保証に重要な技術およびデータサポートを提供します。