2億ドル以上が盗まれた。 Cetus セキュリティインシデントからどのような教訓を学べるでしょうか?

純粋に技術的なバックグラウンドを持つチームには、基本的な「財務リスクに関する洞察力」が著しく欠けています。

@CetusProtocol のハッカー攻撃セキュリティ「リプレイ」レポートを読むと、「興味深い」現象に気付くでしょう。技術的な詳細は非常に透明性を持って公開されており、緊急時の対応も教科書レベルですが、「なぜハッキングされたのか」という最も重要な本質的な疑問については、曖昧になっているようです。

このレポートでは、`integer-mate` ライブラリの `checked_shlw` 関数のチェック エラー (≤2^192 であるべきが、実際は ≤2^256) を説明するために多くのスペースが使われており、これを「意味上の誤解」と特徴づけています。この物語は技術的には有効ですが、あたかもシータスもこの技術的欠陥の無実の犠牲者であるかのように、巧妙に焦点を外部の責任に向けさせています。

問題は、`integer-mate` はオープンソースで広く使用されている数学ライブラリであるのに、たった 1 つのトークンで非常に高い流動性シェアを獲得できるという、そんなばかげたミスをなぜ犯したのかということです。

ハッカーの攻撃経路を分析すると、ハッカーが完璧な攻撃を成功させるには、誤ったオーバーフローチェック、大きなシフト計算、切り上げルール、経済合理性の検証の欠如という 4 つの条件を同時に満たす必要があることがわかります。

Cetus は、ユーザーから 2^200 などの天文学的な数値の入力を受け入れたり、非常に危険な大規模変位操作を使用したり、外部ライブラリの検査メカニズムを完全に信頼したりするなど、あらゆる「トリガー」条件において「不注意」でした。最も致命的なのは、システムが「1トークンで超高値の株」という不条理な結果を計算したとき、それが経済常識的なチェックを一切行わずに直接実行されたことです。

したがって、Cetus が本当に反省すべき点は次のとおりです。

1) 適切なセキュリティ テストを行わずに一般的な外部ライブラリを使用するのはなぜですか? `integer-mate` ライブラリはオープンソースで人気があり、広く使用されていますが、Cetus は、このライブラリのセキュリティ境界や、ライブラリに障害が発生した場合に適切な代替ソリューションがあるかどうかなどを十分に理解せずに、このライブラリを使用して数億ドルの資産を管理しています。どうやら、Cetus にはサプライ チェーンのセキュリティ保護に関する最も基本的な認識が欠けているようです。

2) 境界を設定せずに天文学的な数字を入力できるのはなぜですか? DeFi プロトコルは分散化を追求する必要がありますが、成熟した金融システムがオープンであればあるほど、より明確な境界が必要になります。

システムが攻撃者によって綿密に構築された天文学的な数字の入力を許可している場合、チームは明らかにそのような流動性需要が合理的であるかどうかについて考えなかったのでしょうか?世界最大のヘッジファンドでさえ、これほど過剰な流動性シェアを必要としないだろう。どうやら、Cetus チームには財務直感を備えたリスク管理の才能が欠けているようです。

3) 複数回のセキュリティ監査を経ても、なぜ問題が事前に発見されなかったのでしょうか?この文は、致命的な認知上の誤解をうっかり明らかにしています。つまり、プロジェクト関係者はセキュリティ責任をセキュリティ企業にアウトソーシングし、監査を免責の黄金のチケットとみなしているのです。しかし現実は残酷です。セキュリティ監査エンジニアはコードのバグを見つけるのが得意です。素晴らしい交換比率を計算するシステムをテストしているときに、何か問題が発生するかもしれないと誰が考えたでしょうか?

数学、暗号、経済学にまたがるこのような境界検証は、現代の DeFi セキュリティにおける最大の盲点です。監査会社は、「これはコードロジックの問題ではなく、経済モデルの設計上の欠陥です」と言うでしょう。プロジェクト関係者は「監査では問題は見つからなかった」と不満を言うだろう。ユーザーはお金がなくなったことしか知りません。

つまり、これが最終的に明らかにするのは、DeFi 業界の体系的なセキュリティ上の欠陥です。純粋に技術的なバックグラウンドを持つチームには、基本的な「金融リスクの感覚」が著しく欠けているのです。

Cetus のレポートから判断すると、チームは明らかに十分に反省していなかった。

今回のハッカー攻撃における技術的な欠陥にだけ注目するのではなく、Cetus を皮切りに、すべての DeFi チームが純粋に技術的な思考の限界を変え、「金融エンジニア」としてのセキュリティリスク意識を真に培うべきだと私は考えています。

たとえば、技術チームの知識の盲点を補うために金融リスク管理の専門家を導入するなどです。コード監査だけでなく必要な経済モデル監査も考慮した多者間監査およびレビューのメカニズムを実施する。 「金融感覚」を養い、様々な攻撃シナリオとそれに応じた対応策をシミュレーションし、異常な操作などに常に敏感であること。

これは、以前セキュリティ会社で働いていた時のことを思い出させます。そこでは、業界のセキュリティリーダーである @evilcos、@chiachih_wu、@yajinzhou、@mikelee205 も同じ意見でした。

業界が成熟するにつれて、コード レベルの技術的なバグはますます少なくなる一方で、境界が不明確で責任があいまいなビジネス ロジックの「認識バグ」が最大の課題になります。

監査会社はコードにバグがないことを保証することしかできませんが、「論理的な境界」を実現するには、プロジェクト チームがビジネスの性質をより深く理解し、境界を制御する能力を持っている必要があります。 (セキュリティ監査後もハッカーが攻撃を続けた過去の多くの「責任転嫁事件」の根本的な原因はこれにある)

DeFi の未来は、強力なコーディングスキルとビジネス ロジックの深い理解を持つチームに属します。

共有先:

著者:链上观

本記事はPANews入駐コラムニストの見解であり、PANewsの立場を代表するものではなく、法的責任を負いません。

記事及び見解は投資助言を構成しません

画像出典:链上观侵害がある場合は、著者に削除を連絡してください。

PANews公式アカウントをフォローして、一緒に強気相場と弱気相場を乗り越えましょう
おすすめ記事
1時間前
2時間前
3時間前
3時間前
4時間前
5時間前

人気記事

業界ニュース
市場ホットスポット
厳選読み物

厳選特集

App内阅读