ウォレットを新しい未確認の dApp に接続するリスクは何ですか?

未検証の dApp へのウォレット接続のリスク

1. ユーザーが自分のウォレットを未検証の分散型アプリケーションに接続するとき、範囲を完全に理解せずに広範な権限を付与することがよくあります。多くの dApp は無制限のトークン承認を要求し、追加の同意なしに資産を繰り返し引き出すことができる契約を可能にします。

2. 悪意のあるコントラクトには、特にウォレットに転送フックや再入の脆弱性があるトークンが保持されている場合、接続時に自動転送をトリガーするロジックが組み込まれている可能性があります。これにより、ユーザーが取引を承認してから数秒以内に残高全体を失うという多数の事件が発生しました。

3. 偽のインターフェイスは正規のプロトコルを模倣し、ユーザーをだまして標準の接続要求を装ったフィッシング ペイロードに署名させます。これらのペイロードには、「ウォレット接続」または「ログイン」を装った任意のコントラクト呼び出しを許可する悪意のある署名リクエストが含まれる可能性があります。

4. 一部の dApp は、最小限のノード インフラストラクチャを備えた不明瞭な EVM 互換チェーンにデプロイされており、予想される状態遷移を無効にするフロントランニング攻撃、サンドイッチ攻撃、さらにはチェーン再編成の可能性が高まり、ユーザーは沈黙の資金損失にさらされることになります。

5. MetaMask のようなウォレット拡張機能は、署名リクエストを促す前にコントラクトのバイトコードの整合性を検証しません。ハイジャックされた CDN でホストされるライブラリなど、dApp のフロントエンドの依存関係が 1 つ侵害されると、悪意のある署名ロジックがユーザーのブラウザー コンテキストに直接挿入される可能性があります。

トークン承認の悪用パターン

1. 従来の ERC-20 の承認は、プロトコルのアップグレードやチェーンの移行を通じて引き続き有効です。攻撃者は、同一の関数セレクターを共有する新しく展開された悪意のあるコントラクトに対して古い承認を再利用することでこれを悪用します。

2. プロキシ コントラクトに付与された承認は、基礎となる実装がユーザーの通知なしにアップグレードされる可能性があるため、特に危険です。管理キーを制御する攻撃者は、いつでもロジックを交換して、承認されたトークンを排出できます。

3. 一部の dApp はオフチェーンで許可ベースの承認を使用しており、ユーザーは EIP-712 メッセージに署名する必要があります。ドメイン区切り記号が正しく設定されていない場合、またはメッセージ構造があいまいな場合、署名がネットワーク間で再生されたり、不正な転送に再利用されたりする可能性があります。

4. ウォレットでは、承認プロンプト中に ABI でエンコードされた完全な通話データが表示されることはほとんどありません。ユーザーは、承認の対象が本物のトークン アドレスなのか、それとも同様のチェックサム ケーシングや Unicode ホモグラフ トリックを使用して攻撃者によって展開された類似アドレスなのかを確認できません。

フロントエンドのサプライチェーンの脆弱性

1. 開発者が誤ってグローバル スコープで機密参照を公開した場合、npm の依存関係を介して挿入されたサードパーティの分析スクリプトが、メモリ内のウォレット オブジェクトから秘密キーを窃取することが観察されています。

2. dApp ビルダーが使用する侵害された UI フレームワークには、ニーモニック入力フィールドが無効になっているか、CSS によって非表示になっている場合でも、キーストロークをキャプチャする非表示のイベント リスナーが含まれる場合があります。

3. ブラウザ拡張機能の競合により、ウォレットプロバイダーが署名リクエストを正しくインターセプトできず、不正なパラメータまたはナンスで署名された生のトランザクションブロードキャストが発生する競合状態が発生します。

4. 縮小されていない JavaScript バンドルには、多くの場合、ハードコーディングされた API キー、ウォレット アドレス、またはテストネット認証情報が含まれており、攻撃者はこれらを収集して再利用し、悪意のあるリレーラーを介してトラフィックをルーティングする際に、信頼できるバックエンド サービスをシミュレートします。

ネットワークレベルの欺瞞戦術

1. 不正な RPC エンドポイントは、偽のブロックチェーン状態を提供し、取り消しできないアクションを開始する前に偽のトークン残高や偽のトランザクション確認を表示して誤った信頼を誘導します。

2. DNS ポイズニング攻撃は、公式 dApp ドメインにアクセスしようとするユーザーを、同一の UI をホストしているが攻撃者が制御するスマート コントラクトを指しているミラーリングされたサイトにリダイレクトします。

3. 中間者プロキシはウォレットと dApp 間の WebSocket 接続を傍受し、応答ペイロードを変更して保留中の承認を非表示にしたり、既知の詐欺契約アドレスによってトリガーされる警告バナーを抑制します。

4. dApp オンボーディング フローにバンドルされているテストネット フォーセットは、正規のコントラクトと並行して悪意のあるコントラクトを展開する場合があり、ユーザーが両方を操作することを奨励し、メインネットに悪用ロジックを導入する前に信頼を構築します。

よくある質問

Q: トランザクションに署名せずにウォレットに接続するだけで、dApp が資金を盗む可能性がありますか? A: はい。接続だけでは資金は移動しませんが、多くの dApp はすぐにトークンの承認を要求するか、ユーザーのウォレット コンテキストを使用して任意のコードを実行するデリゲートコール パターンを呼び出します。

Q: ハードウェアウォレットを使用すると、これらのリスクは排除されますか? A: いいえ。ハードウェア ウォレットは秘密キーを保護しますが、フロントエンドによって要求されたトランザクションには署名します。 dApp が誤解を招く情報を表示したり、虚偽の通話データを作成したりした場合、ハードウェア デバイスは指示に従ってそれに署名します。

Q: オープンソースの dApp は自動的に安全に接続できますか? A: 必ずしもそうとは限りません。公開されているソース コードは、展開の整合性を保証しません。攻撃者は、静的分析ツールをバイパスする、所有者アドレスの変更やバックドアによるフォールバック機能など、微妙な変更を加えた監査済み契約の修正バージョンを頻繁に展開します。

Q: 一部のウォレット拡張機能では警告が表示され、他の拡張機能では警告が表示されないのはなぜですか? A: 警告の動作は、内線プロバイダーが管理するリアルタイムの契約アドレス評価データベースに依存します。これらのデータベースは新規導入に比べて遅れており、あまり知られていないチェーンや新たに作成された契約をカバーしていないことがよくあります。