著者: Haotian
@CetusProtocol のハッキングセキュリティ「振り返り」レポートを読み終えると、「興味深い」現象が見えてくる：技術的な詳細は非常に透明に公開され、緊急対応も教科書レベルと言えるが、最も重要な「なぜハッキングされたのか」という根本的な問いについては、軽く触れるだけである。
このレポートでは、'integer-mate' ライブラリの 'checked_shlw' 関数チェックエラー (≤ 2^192 であるべきですが、実際には ≤2^256) を説明するために多くのスペースを費やし、これを "意味的な誤解" として特徴付けています。 この物語は、技術的には妥当であるにもかかわらず、まるでCetusもこの技術的欠陥の無実の犠牲者であるかのように、巧みに焦点を外部の責任に向けています。
問題が発生しました。integer-mateはオープンソースで広く利用されている数学ライブラリであるにもかかわらず、あなたのところで1トークンで高額な流動性シェアを得られるという不条理なエラーが発生したのですか？
integer-mate
ハッカー攻撃のパスを分析すると、ハッカーが完璧な攻撃を実現するためには、4つの条件を同時に満たす必要があることがわかります：不正なオーバーフロー検査、大幅なシフト演算、切り上げルール、経済的合理性の検証の欠如。
Cetusは、2^200のユーザー入力のような天文学的な数字を受け入れること、非常に危険な大変位計算を使用すること、外部ライブラリのチェックメカニズムを完全に信頼すること、そして最も致命的なことに、システムが「1トークンで超高価格シェア」という不条理な結果を計算すると、経済常識的なチェックなしに直接実行されるなど、すべての「トリガー」条件で「過失」があります。
したがって、Cetusが真剣に反省すべき点は以下の通りです：
2）なぜ天文学的な数字の入力を許可し、境界を設定しないのですか？DeFiプロトコルが非中央集権を求めるべきであるとはいえ、成熟した金融システムはオープンであればあるほど明確な境界を必要とします。
システムが攻撃者によって慎重に構築された天文学的な量を許可したとき、チームは明らかにそのような流動性要件が合理的であるかどうかを考えていませんでした。 世界最大のヘッジファンドでさえ、これほど誇張された流動性のシェアを必要とする可能性は低いでしょう。 明らかに、Cetusのチームには財務的な直感を持つリスク管理の才能が欠けていました。
この数学、暗号学、経済学の境界を越えた検証は、現代のDeFiのセキュリティにおける最大の盲点です。監査会社は「これは経済モデルの設計欠陥であり、コードの論理的な問題ではない」と言うでしょう；プロジェクト側は「監査で問題が見つからなかった」と不満を言います；そしてユーザーは自分のお金がなくなったことしか知りません！
ご覧のとおり、これは最終的にDeFi業界のシステム的なセキュリティの弱点を露呈しています：純粋な技術的背景を持つチームは基本的な「金融リスク感覚」を深刻に欠いています。
Cetusのこの報告から見ると、チームは明らかに反省が足りていない。
単に今回のハッキング攻撃における技術的欠陥の不足を指摘するだけではなく、Cetusから始めて、すべてのDeFiチームは純粋な技術思考の限界を克服し、真に「金融エンジニア」としての安全リスク意識を育成するべきだと思います。
たとえば、技術チームの知識の盲点を補うために、財務リスク管理の専門家を紹介します。 コード監査を見るだけでなく、必要な経済モデル監査を構成するために、マルチパーティ監査レビューメカニズムを実行します。 「金融感覚」を養い、様々な攻撃シナリオとそれに対応する対策をシミュレーションし、常に異常動作に敏感になる。
これを聞いて、以前のセキュリティ会社での経験を思い出しました。業界のセキュリティの大物である @evilcos、@chiachih_wu、@yajinzhou、@mikelee205 たちとの交流でも同様の合意がありました：
業界が成熟するにつれて、コードレベルの技術的なバグの問題は減少していくが、境界が不明確で責任があいまいなビジネスロジックの「意識バグ」が最大の課題となる。
監査会社はコードにバグがないことを保証することしかできませんが、「ロジックに境界がある」ことを実現するには、プロジェクトチームがビジネスの本質をより深く理解し、境界をコントロールする能力が必要です。（以前、多くの安全監査後に依然としてハッカー攻撃を受けた「責任転嫁事件」の根本的な原因はここにあります）
DeFiの未来は、コード技術が優れ、ビジネスロジックを深く理解しているチームに属します！
305k 投稿
271k 投稿
178k 投稿
83k 投稿
70k 投稿
69k 投稿
64k 投稿
62k 投稿
53k 投稿
51k 投稿
Cetusの安全問題の教訓：分散型金融チームが注意すべきことは？
著者: Haotian
@CetusProtocol のハッキングセキュリティ「振り返り」レポートを読み終えると、「興味深い」現象が見えてくる：技術的な詳細は非常に透明に公開され、緊急対応も教科書レベルと言えるが、最も重要な「なぜハッキングされたのか」という根本的な問いについては、軽く触れるだけである。
このレポートでは、'integer-mate' ライブラリの 'checked_shlw' 関数チェックエラー (≤ 2^192 であるべきですが、実際には ≤2^256) を説明するために多くのスペースを費やし、これを "意味的な誤解" として特徴付けています。 この物語は、技術的には妥当であるにもかかわらず、まるでCetusもこの技術的欠陥の無実の犠牲者であるかのように、巧みに焦点を外部の責任に向けています。
問題が発生しました。
integer-mateはオープンソースで広く利用されている数学ライブラリであるにもかかわらず、あなたのところで1トークンで高額な流動性シェアを得られるという不条理なエラーが発生したのですか？ハッカー攻撃のパスを分析すると、ハッカーが完璧な攻撃を実現するためには、4つの条件を同時に満たす必要があることがわかります：不正なオーバーフロー検査、大幅なシフト演算、切り上げルール、経済的合理性の検証の欠如。
Cetusは、2^200のユーザー入力のような天文学的な数字を受け入れること、非常に危険な大変位計算を使用すること、外部ライブラリのチェックメカニズムを完全に信頼すること、そして最も致命的なことに、システムが「1トークンで超高価格シェア」という不条理な結果を計算すると、経済常識的なチェックなしに直接実行されるなど、すべての「トリガー」条件で「過失」があります。
したがって、Cetusが真剣に反省すべき点は以下の通りです：
2）なぜ天文学的な数字の入力を許可し、境界を設定しないのですか？DeFiプロトコルが非中央集権を求めるべきであるとはいえ、成熟した金融システムはオープンであればあるほど明確な境界を必要とします。
システムが攻撃者によって慎重に構築された天文学的な量を許可したとき、チームは明らかにそのような流動性要件が合理的であるかどうかを考えていませんでした。 世界最大のヘッジファンドでさえ、これほど誇張された流動性のシェアを必要とする可能性は低いでしょう。 明らかに、Cetusのチームには財務的な直感を持つリスク管理の才能が欠けていました。
この数学、暗号学、経済学の境界を越えた検証は、現代のDeFiのセキュリティにおける最大の盲点です。監査会社は「これは経済モデルの設計欠陥であり、コードの論理的な問題ではない」と言うでしょう；プロジェクト側は「監査で問題が見つからなかった」と不満を言います；そしてユーザーは自分のお金がなくなったことしか知りません！
ご覧のとおり、これは最終的にDeFi業界のシステム的なセキュリティの弱点を露呈しています：純粋な技術的背景を持つチームは基本的な「金融リスク感覚」を深刻に欠いています。
Cetusのこの報告から見ると、チームは明らかに反省が足りていない。
単に今回のハッキング攻撃における技術的欠陥の不足を指摘するだけではなく、Cetusから始めて、すべてのDeFiチームは純粋な技術思考の限界を克服し、真に「金融エンジニア」としての安全リスク意識を育成するべきだと思います。
たとえば、技術チームの知識の盲点を補うために、財務リスク管理の専門家を紹介します。 コード監査を見るだけでなく、必要な経済モデル監査を構成するために、マルチパーティ監査レビューメカニズムを実行します。 「金融感覚」を養い、様々な攻撃シナリオとそれに対応する対策をシミュレーションし、常に異常動作に敏感になる。
これを聞いて、以前のセキュリティ会社での経験を思い出しました。業界のセキュリティの大物である @evilcos、@chiachih_wu、@yajinzhou、@mikelee205 たちとの交流でも同様の合意がありました：
業界が成熟するにつれて、コードレベルの技術的なバグの問題は減少していくが、境界が不明確で責任があいまいなビジネスロジックの「意識バグ」が最大の課題となる。
監査会社はコードにバグがないことを保証することしかできませんが、「ロジックに境界がある」ことを実現するには、プロジェクトチームがビジネスの本質をより深く理解し、境界をコントロールする能力が必要です。（以前、多くの安全監査後に依然としてハッカー攻撃を受けた「責任転嫁事件」の根本的な原因はここにあります）
DeFiの未来は、コード技術が優れ、ビジネスロジックを深く理解しているチームに属します！