執筆者:エリック(フォアサイト・ニュース)
本日北京時間午前10時21分頃、デルタニュートラル戦略を用いてステーブルコインUSRを発行するResolv Labsがハッキングされた。アドレス0x04A2から始まるアドレスが、10万USDCを使用してResolv Labsプロトコルから5000万USRを不正に発行した。
この事件が明るみに出た後、USRは一時的に約0.25ドルまで下落したが、執筆時点では約0.80ドルまで回復した。RESOLVトークンの価格も一時的に約10%下落した。
その後、ハッカーたちは同じ手法を用いて10万USDCで3000万USRを偽造した。USRのペッグが大幅に解除されたため、裁定取引業者が迅速に行動し、USR、wstUSR、その他の担保をサポートしていたMorpho上の多くの貸付市場はほぼ完全に枯渇した。BNBチェーン上のLista DAOも新規の融資申請を停止した。
影響を受けるのはこれらの融資プロトコルだけではありません。Resolv Labsのプロトコルでは、ユーザーがRLPトークンを発行できます。RLPトークンは価格変動が大きく、高い収益をもたらしますが、同時にプロトコルによって発生した損失に対する責任を負うことにもなります。現在、約3,000万個のRLPトークンが流通しており、Stream Financeが1,300万個以上を保有しているため、純リスクエクスポージャーは約1,700万ドルに上ります。
そうです、以前xUSDの影響で大きな打撃を受けたStream Financeは、再び打撃を受ける可能性があるのです。
この記事執筆時点で、ハッカーはUSRをUSDCとUSDTに変換し、イーサリアムの購入を続けており、すでに1万枚以上のコインを購入している。20万USDCを使って、ハッカーは2000万ドル以上の資産を抜き取り、弱気相場の中で「100倍コイン」を手に入れた。
またしても、「厳密さの欠如」が原因で抜け穴が悪用された。
昨年10月11日の急落により、デルタニュートラル戦略を用いて発行された多くのステーブルコインが、ADL(自動レバレッジ解消)によって担保損失を被った。アルトコインを資産クラスとして利用しているプロジェクトの中には、さらに大きな損失を被ったものもあり、中には完全に消滅してしまったものもあった。
今回攻撃を受けたResolv Labsも、USRの発行に同様の仕組みを使用していた。同プロジェクトは2025年4月、Cyber.FundとMaven11が主導し、Coinbase Venturesも参加した1000万ドルのシードラウンドを完了したと発表し、5月下旬から6月上旬にかけてトークンRESOLVをローンチした。
しかし、Resolv Labsが攻撃を受けた理由は、極端な市場状況によるものではなく、USRを発行する仕組みが「十分厳格ではなかった」ためだった。
セキュリティ企業や公的機関は、このハッキング事件の原因をまだ分析していません。DeFiコミュニティメンバーのYAMによる予備分析では、ハッカーがプロトコルのバックエンドで使用され、ミントコントラクトにパラメータを提供するSERVICE_ROLE関数を乗っ取ったことが攻撃の原因である可能性が高いと示唆されています。
Grokの分析によると、ユーザーがUSRをミントする際、オンチェーンでリクエストを開始し、コントラクトのrequestMint関数を呼び出します。その際のパラメータには以下が含まれます。
_depositTokenAddress: トークンが預け入れられるアドレス。
_amount: 保存する金額。
_minMintAmount: 受け取るUSRの最低予想額(滑り止めポイント)。
その後、ユーザーはUSDCまたはUSDTをコントラクトに預け入れます。プロジェクトのバックエンドであるSERVICE_ROLEはリクエストを監視し、Pythオラクルを使用して預け入れられた資産の価値を確認し、completeMintまたはcompleteSwap関数を呼び出して実際に発行されたUSRの量を決定します。
問題は、ミントコントラクトがSERVICE_ROLEから提供される_mintAmountを完全に信頼し、その数値がPythによってオフチェーンで検証済みであると想定している点にある。そのため、上限を設定したり、オンチェーンオラクルで検証したりすることなく、直接mint(_mintAmount)を実行してしまう。
これに基づき、YAMは、ハッカーがプロジェクトチームが管理するはずだったSERVICE_ROLEを乗っ取り(内部オラクルの不具合、内部犯行、または鍵の盗難が原因の可能性あり)、ミント中に_mintAmountを直接5000万に設定することで、10万USDCで5000万USRをミントする攻撃を実行したと推測している。
最終的に、Grokは、Resolvがプロトコルの設計時に、ユーザーによるコイン発行リクエストを受け取るアドレス(またはコントラクト)がハッカーによって制御される可能性を考慮していなかったと結論付けた。USRの発行リクエストが最終的にUSRを発行するコントラクトに送信された際、最大発行量は設定されておらず、発行コントラクトは二次検証のためにオンチェーンオラクルを使用しなかった。その代わりに、SERVICE_ROLEによって提供されるすべてのパラメータを直接信頼していた。
予防策も不十分だった。
YAMはハッキングの理由について憶測を述べるだけでなく、プロジェクトチームが危機への対応において準備不足だったことも指摘した。
YAMはX上で、Resolv Labsがプロトコルを停止したのは最初のハッキングから3時間後であり、そのうち約1時間はマルチシグネチャトランザクションに必要な4つの署名を集めるのに時間がかかったためだと述べた。YAMは、緊急停止には1つの署名のみが必要であり、この権限は可能な限りチームメンバーまたは信頼できる外部オペレーターに割り当てられるべきだと考えている。これにより、オンチェーンの異常に対する認識が高まり、迅速な停止の可能性が高まり、異なるタイムゾーンへの対応も改善されるだろう。
単一の署名だけでプロトコルを停止するという提案はやや過激だが、異なるタイムゾーンにまたがる複数の署名を必要とするプロトコル停止要求は、緊急事態において重大な遅延を引き起こす可能性がある。今回の事件から得られた教訓は、オンチェーンの動作を継続的に監視する信頼できる第三者機関を導入すること、あるいは緊急停止権限を持つ監視ツールを使用することである。
DeFiプロトコルに対するハッカー攻撃は、これまでコントラクトの脆弱性を狙ったものに限られていました。しかし、Resolv Labsの事件はプロジェクトチームへの警告となります。プロトコルのセキュリティに関して、プロトコルのどの部分も信用できないという前提に立ち、パラメータを含むすべてのリンクは、プロジェクトチーム自身が運用するバックエンドであっても、少なくとも2回の検証を受ける必要があることを改めて認識すべきです。




