Back to Blog

冒涜ツール脆弱性に関する短評

Code Auditing
2022年9月21日
5 min read

Wintermuteは1億6000万ドル以上の損失を被る脆弱性により悪用されました。根本原因は、Wintermuteプロジェクトの秘密鍵が、Wintermuteが秘密鍵とイーサリアムアカウントを生成するために使用していたProfanityツールの脆弱性により侵害されたことです。

本ブログでは、Profanityの脆弱性の根本原因と、その脆弱性がどのように悪用されるかを説明します。

イーサリアムアドレス

イーサリアムアドレスは、公開鍵のKeccak-256ハッシュから生成され、16進数で表されます。公開鍵は楕円曲線乗算を用いて秘密鍵から生成され、これは元に戻せません。秘密鍵から公開鍵を取得することはできます。しかし、公開鍵から秘密鍵を取得するには、総当たり攻撃なしでは不可能です。秘密鍵の長さは256ビットであることに注意してください。公開鍵から対応する秘密鍵を見つけるには、最大 2^256 回の計算が必要です。

一言で言えば、秘密鍵/公開鍵とイーサリアムアドレスの関係は、以下の図に示されています。

脆弱性の根本原因

Profanityの目的は、アドレスの先頭5桁がゼロであるなど、特殊なイーサリアムアドレスを見つけることです。この目的のために、Profanityは以下の方法を採用します。

詳細な実装は若干異なる場合があります。

private_key の長さは256ビット(2^256通りの値)ですが、秘密鍵の生成に脆弱性があります。具体的には、シード(ステップ1)はわずか32ビットであり、ステップ1のシードからステップ2のprivate_keyへのプロセスは決定論的です。

ここにどのようなセキュリティ上の影響があるのでしょうか?

悪用方法

例えば、多くの価値ある資産を持つイーサリアムアドレスがあるとします。その秘密鍵を取得できれば、そのアカウントを所有し、すべての資産を転送することができます。しかし、前述したように、秘密鍵を見つけるには 2^256 の空間全体を総当たり攻撃する必要があり、これはほぼ不可能です。

しかし、イーサリアムアドレスがProfanityツールから生成された場合はどうでしょうか?より低い難易度で秘密鍵を見つけるために総当たり攻撃を行うことができます。シードを0から 2^32-1 まで指定し、同じ公開鍵(およびイーサリアムアドレス)を生成できる秘密鍵を見つけるまで同じプロセスを繰り返すだけです。最大 2^32 * loop_threashold 回の計算で済むため、強力なGPUクラスターがあれば数時間または数日/数週間で完了できます。

しかし、これはまだ最適化されたアルゴリズムです。詳細については、Slowmistの記事を参照してください。

まとめ

DeFiプロジェクトを安全にすることは容易ではありません。コード監査に加えて、コミュニティはプロジェクトの状況を積極的に監視し、攻撃が発生する前にブロックするなどのプロアクティブな方法を取るべきだと考えています。

BlockSecについて

BlockSecは、世界的に著名なセキュリティ専門家グループによって2021年に設立された、先駆的なブロックチェーンセキュリティ企業です。当社は、新興のWeb3世界のためのセキュリティとユーザビリティの向上に尽力し、その大規模な採用を促進します。この目的のため、BlockSecはスマートコントラクトとEVMチェーンのセキュリティ監査サービス、セキュリティ開発と脅威のプロアクティブなブロックのためのPhalconプラットフォーム、資金追跡と調査のためのMetaSleuthプラットフォーム、そしてWeb3開発者が仮想通貨の世界を効率的にサーフィンするためのMetaSuites拡張機能を提供しています。

現在までに、MetaMask、Uniswap Foundation、Compound、Forta、PancakeSwapなど300を超える著名なクライアントにサービスを提供し、Matrix Partners、Vitalbridge Capital、Fenbushi Capitalなどの著名な投資家から2回の資金調達で数千万米ドルを受け取っています。

公式ウェブサイト:https://blocksec.com/

公式Twitterアカウント:https://twitter.com/BlockSecTeam

Sign up for the latest updates
安全な保管を超えて、第2部:ウォレットの暗号技術を安全に実装する
Security Insights

安全な保管を超えて、第2部:ウォレットの暗号技術を安全に実装する

攻撃者は、保護された秘密鍵のコピーを読み取らずに、その秘密鍵を復元できるのでしょうか。『Beyond Secure Storage』の第2部では、乱数の品質不足、エントロピーの損失、署名用ノンスの不備によって鍵の予測や復元が可能になった6件の事例を検証します。そこから鍵生成と署名に関する実装要件を導き出し、決済機関がコードレビューと導入済みシステムのテストを通じて、それらをどう評価できるかを説明します。

安全な保管を超えて、第1部:安全な決済・署名ワークフローの設計
Security Insights

安全な保管を超えて、第1部:安全な決済・署名ワークフローの設計

攻撃者が秘密鍵を盗まずに、認可されていない操作が有効な署名を得ることは、なぜ可能なのでしょうか。「安全な保管の先へ」第1回では、Bitget、Bybit、Binanceなどの事例を通じて、支払い要求、トランザクションの構築、署名、実行、決済の各段階における認可の不備を検討します。そのうえで、認可されていない操作を防ぎ、損失を抑えるための設計原則を導き出し、レビュー、監査、ペネトレーションテスト、演習によって、それらの防御策をどう検証できるかを説明します。

NEAR Intentsの悪用:返金処理の欠陥とセキュリティ上の教訓
Security Insights

NEAR Intentsの悪用:返金処理の欠陥とセキュリティ上の教訓

NEAR Intentsへの攻撃では、過大な払い戻しイベントを利用し、預け入れた資産が返還された後も内部残高を維持しました。本分析では、レシートの処理の流れと、合計3,865,021 USDTに上るBNB Chainでの7件の出金を再構成します。また、これらの資金流出とプロジェクトが報告した全額回収を区別し、NEARスマートコントラクトの開発と監査におけるセキュリティ上の考慮事項を示します。

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit