去中心化取引所TMXがArbitrumネットワーク上の未検証のコントラクトを狙ったハッキングにより、約140万ドルの損失を被りました。CertiKの監視データによると、ハッカーは巧妙に設計された繰り返し操作を通じて、コントラクト内のUSDT、wrapped SOL、WETH資産を系統的に枯渇させました。この事件は、DeFiエコシステムにおける重大に過小評価されたリスクを再び浮き彫りにしています:監査を受けていないコントラクトは鍵のかかっていない金庫のようなもので、こじ開けられるのを待っているのです。## ハッカーはどうやってやったのかハッカーの攻撃手法は複雑ではありませんが、効率は驚くべきものです:- TMX LPトークンとUSDTのペアを鋳造- USDTをUSDGに交換- TMX LPのステーキングを解除- USDGを売却してより多くの資産を獲得- 上記操作をループして繰り返すこの「アービトラージループ」が成功する理由は、コントラクトのロジックに脆弱性があったためです。ハッカーは価格差や交換メカニズムの欠陥を繰り返し利用できることを発見し、多重に操作を行うことで、最終的にコントラクト内の流動性を吸い尽くしました。## なぜ「未検証コントラクト」なのかここでの「未検証」は重要なキーワードです。これは次のことを意味します:| 検証済みコントラクト | 未検証コントラクト ||---------------------|------------------|| CertiK、OpenZeppelinなどのセキュリティ会社による監査済み | 第三者によるセキュリティ審査なし || コードロジックが専門的に検査済み | コードの脆弱性が発見されていない || リスクが比較的透明 | リスクが隠された「地雷」のようなもの || ハッカーのコストが高い | ハッカーのコストが低い |最新の情報によると、多くの新規プロジェクトは迅速なローンチのために監査を省略しています。このやり方はコスト削減に見えますが、実際には確率に賭けているのです—誰も脆弱性を見つけないことに賭けているのです。一方、ハッカーはまさにその「見逃さない人」なのです。## このケースから何がわかるか表面的には、これはTMXの損失のように見えますが、より深い問題は次の通りです:### DeFiユーザーのリスク意識不足多くの人は流動性マイニングや取引に参加する際、コントラクトが監査済みかどうかを積極的に確認しません。これに対し、Mutuum Financeプロジェクトが18600人以上のホルダーを惹きつけた重要な理由の一つは、HalbornとCertiKの二重のセキュリティ監査を完了している点にあります。これは明確な対比を成しています。### プロジェクト側のリスク管理の欠陥未検証のコントラクトを公開すること自体が赤旗です。正規のプロジェクトであれば、機能が完全になった段階ですぐに監査を行うべきであり、問題が出てから修正するのは遅すぎます。### ハッカーのコストが低下しているこのような攻撃が成功するたびに、ハッカーはより多くの「手口」を蓄積しています。次の未検証コントラクトは、同様のリスクに直面する可能性があります。## 今後注目すべき点- TMXプロジェクト側は公式声明と補償計画を発表するか- Arbitrumネットワークは新しいコントラクトのリスク警告を強化するか- この140万ドルの盗難資産は追跡・凍結されるか- 類似の未検証コントラクトは他にどれだけリスク状態にあるか## まとめこの事件の核心的な教訓は非常にシンプルです:DeFiにおいて、コントラクトの検証は選択肢ではなく必須事項です。もしあるプロジェクトが正式なセキュリティ監査を受けずにローンチした場合、その参加資金はすべてプロジェクトのコードのレベルに賭けていることになります。そして、ハッカーこそが最も真剣な「コード監査員」なのです。ユーザーにとっては、どんなDeFiプロジェクトに参加する前でも、EtherscanでコントラクトにCertiKやOpenZeppelinなどの監査報告があるかどうかを確認することが重要です。このステップは技術的な背景を必要としませんが、リスクを大きく低減できます。プロジェクト側にとっては、監査のコストは被害を受けるコストよりもはるかに低い—140万ドルという教訓は最良の例です。
140万ドルが一夜で蒸発:未検証のコントラクトがハッカーのセルフキャッシュマシンになる方法
去中心化取引所TMXがArbitrumネットワーク上の未検証のコントラクトを狙ったハッキングにより、約140万ドルの損失を被りました。CertiKの監視データによると、ハッカーは巧妙に設計された繰り返し操作を通じて、コントラクト内のUSDT、wrapped SOL、WETH資産を系統的に枯渇させました。この事件は、DeFiエコシステムにおける重大に過小評価されたリスクを再び浮き彫りにしています:監査を受けていないコントラクトは鍵のかかっていない金庫のようなもので、こじ開けられるのを待っているのです。
ハッカーはどうやってやったのか
ハッカーの攻撃手法は複雑ではありませんが、効率は驚くべきものです:
この「アービトラージループ」が成功する理由は、コントラクトのロジックに脆弱性があったためです。ハッカーは価格差や交換メカニズムの欠陥を繰り返し利用できることを発見し、多重に操作を行うことで、最終的にコントラクト内の流動性を吸い尽くしました。
なぜ「未検証コントラクト」なのか
ここでの「未検証」は重要なキーワードです。これは次のことを意味します:
最新の情報によると、多くの新規プロジェクトは迅速なローンチのために監査を省略しています。このやり方はコスト削減に見えますが、実際には確率に賭けているのです—誰も脆弱性を見つけないことに賭けているのです。一方、ハッカーはまさにその「見逃さない人」なのです。
このケースから何がわかるか
表面的には、これはTMXの損失のように見えますが、より深い問題は次の通りです:
DeFiユーザーのリスク意識不足
多くの人は流動性マイニングや取引に参加する際、コントラクトが監査済みかどうかを積極的に確認しません。これに対し、Mutuum Financeプロジェクトが18600人以上のホルダーを惹きつけた重要な理由の一つは、HalbornとCertiKの二重のセキュリティ監査を完了している点にあります。これは明確な対比を成しています。
プロジェクト側のリスク管理の欠陥
未検証のコントラクトを公開すること自体が赤旗です。正規のプロジェクトであれば、機能が完全になった段階ですぐに監査を行うべきであり、問題が出てから修正するのは遅すぎます。
ハッカーのコストが低下している
このような攻撃が成功するたびに、ハッカーはより多くの「手口」を蓄積しています。次の未検証コントラクトは、同様のリスクに直面する可能性があります。
今後注目すべき点
まとめ
この事件の核心的な教訓は非常にシンプルです:DeFiにおいて、コントラクトの検証は選択肢ではなく必須事項です。もしあるプロジェクトが正式なセキュリティ監査を受けずにローンチした場合、その参加資金はすべてプロジェクトのコードのレベルに賭けていることになります。そして、ハッカーこそが最も真剣な「コード監査員」なのです。
ユーザーにとっては、どんなDeFiプロジェクトに参加する前でも、EtherscanでコントラクトにCertiKやOpenZeppelinなどの監査報告があるかどうかを確認することが重要です。このステップは技術的な背景を必要としませんが、リスクを大きく低減できます。プロジェクト側にとっては、監査のコストは被害を受けるコストよりもはるかに低い—140万ドルという教訓は最良の例です。