攻撃トランザクション：
0x26aa86261c834e837f6be93b2d589724ed5ae644bc8f4b8af2207e6bd70828f9
攻撃対象のスマートコントラクトはオープンソースです。
ステップ1：0x054e がトランザクションを送信し、ウォレット (0x41b8) の 0x0eba に管理者ロールを付与します。
次に、0x0eba が「DAOコントラクト」ロールを 0x1c93 に付与します。
最後に、0x1c93 (XXX) が withdrawFromUser 関数を呼び出し、資金を XXX コントラクトに送金します。
興味深いのは、被害者である 0x41b8 が 0x054e によって作成されたことです。
要約すると、0x054e は被害者である 0x41b8 ウォレットを作成しました。その後、0x054e は 0x0eba に管理者ロールを付与し、0x0eba はさらに 0x1c93 に「DAOコントラクト」ロールを付与しました。最後に、0x1c93 が被害者から資金を引き出しました。
安全な保管を超えて、第2部：ウォレットの暗号技術を安全に実装する
攻撃者は、保護された秘密鍵のコピーを読み取らずに、その秘密鍵を復元できるのでしょうか。『Beyond Secure Storage』の第2部では、乱数の品質不足、エントロピーの損失、署名用ノンスの不備によって鍵の予測や復元が可能になった6件の事例を検証します。そこから鍵生成と署名に関する実装要件を導き出し、決済機関がコードレビューと導入済みシステムのテストを通じて、それらをどう評価できるかを説明します。
安全な保管を超えて、第1部：安全な決済・署名ワークフローの設計
攻撃者が秘密鍵を盗まずに、認可されていない操作が有効な署名を得ることは、なぜ可能なのでしょうか。「安全な保管の先へ」第1回では、Bitget、Bybit、Binanceなどの事例を通じて、支払い要求、トランザクションの構築、署名、実行、決済の各段階における認可の不備を検討します。そのうえで、認可されていない操作を防ぎ、損失を抑えるための設計原則を導き出し、レビュー、監査、ペネトレーションテスト、演習によって、それらの防御策をどう検証できるかを説明します。
NEAR Intentsの悪用：返金処理の欠陥とセキュリティ上の教訓
NEAR Intentsへの攻撃では、過大な払い戻しイベントを利用し、預け入れた資産が返還された後も内部残高を維持しました。本分析では、レシートの処理の流れと、合計3,865,021 USDTに上るBNB Chainでの7件の出金を再構成します。また、これらの資金流出とプロジェクトが報告した全額回収を区別し、NEARスマートコントラクトの開発と監査におけるセキュリティ上の考慮事項を示します。
