Simulation-Aware Malware

シミュレーション認識型マルウェアとは、自分が実行されるその瞬間に、今回の実行が取引シミュレーション環境の中で行われているのか、それとも実際にブロックチェーン上で行われているのかを能動的に判定でき、その判定結果に応じてまったく異なる挙動モードに切り替えられるよう意図的に設計された一連のスマートコントラクトを指す。シミュレーション環境の中では意図的に安全に振る舞い、ユーザーに有利な偽の結果すら表示することで、ユーザーを安心させて確認ボタンを押させる。取引が実際にオンチェーンに送信・実行されて初めて、当初設計された悪意あるロジックに切り替わり、ユーザーの資産を移動させてしまう。この手法はセキュリティ業界では「レッドピル攻撃」（red pill attack）とも呼ばれている。この名称は映画『マトリックス』の「赤い薬を飲むと現実が見える」という場面に由来し、コントラクトが自分が仮想的なシミュレーションの中にいるかどうかを「見抜く」ことができるという意味だ。

この手法が成立する鍵は、シミュレーション環境と実際のオンチェーン環境が理論上は完全に一致するはずでありながら、実務上は両者の間に、コントラクトのロジックによって検知されうる何らかの程度の違いが常に残っているという点にある。もしこの違いがコントラクトの開発者に発見され悪用されれば、本来ユーザーを守るために設計された——署名前に取引結果をプレビューできるようにするための——シミュレーションツールが、逆に攻撃者の手にある欺瞞効果を強化する道具へと変わってしまう。なぜならユーザーが目にする「安全」というプレビューそのものが、まさにユーザーの警戒心を解き、安心して署名させる決定的な一歩だからだ。

シミュレーション認識型マルウェアが実際に機能する根本的な理由は、ブロックチェーンの実行環境に「特殊変数」（special variables）と呼ばれる一連の環境情報が存在することにある——現在のブロック高、タイムスタンプ、そしてブロック生成者のアドレスを表すCOINBASEなどがそれだ。これらの変数の存在は本来、コントラクトのロジックが自分が置かれているオンチェーンの状態を感知し、それに応じた判断を下せるようにするためのものだった。しかしシミュレーション環境では、そもそも本物のブロックや生成者が存在しないため、シミュレーションツールを開発するチームが自らこれらのフィールドにどんな値を入れるかを決めなければならない。2023年のセキュリティ研究チームZenGoの研究では、一部の実装が最も手間のかからない方法を選び、COINBASEなどの変数を全ゼロのアドレスにそのまま設定していたことが判明した。この一見無害に見える簡略化が、悪意あるコントラクトに明確な判断根拠を与えてしまった——この変数がゼロ値であることを検知すれば、自分が今シミュレーション環境にいることを意味し、安心して偽の結果を表示できる。非ゼロの本物のアドレスを検知すれば、すでに実際のチェーン上にいることを意味し、本当にやりたいことを実行できる。

この技術的な根本原因は、なぜこの手法が一時期複数の主流ツールに同時に影響を及ぼせたのかも説明している——COINBASEのような環境変数をシミュレーション環境の中でどう値を埋めるべきかは、ブロックチェーンプロトコル自体が定める標準ではなく、各シミュレーションツール開発チームがそれぞれ独自に選択した実装方法だったからだ。ほとんどのチームが同じ「手間のかからない」簡略化を採用した結果、同じ回避手法が複数の異なる製品に対して同時に有効に機能してしまった。

2023年にZenGoチームが発表した研究は、この手法がPolygonチェーン上でどう機能したかを実際に示している——テスト用の悪意あるコントラクトはユーザーに約0.1 MATICを送るよう求め、シミュレーション結果ではその見返りにユーザーが0.016 WETH（当時の価値で約30ドル）を受け取ると表示され、明らかにお得な取引に見えるよう仕立てられていた。研究チームの調査により、この攻撃パターンが当時、Coinbase Wallet、Rabby、Blowfish、Pocket Universeを含む合計6つの主流ウォレットとセキュリティ拡張機能に影響を及ぼしていたことが判明した——これらのツールはユーザーが取引を送信する前にシミュレーションエンジンを呼び出して取引結果をプレビューするものであり、その中の複数のツールが依拠していたシミュレーションエンジンは、検知されやすい環境変数の値の設定方法を採用していた。ZenGoチームはこの発見を責任ある開示の経路を通じて各ベンダーに通知し、ほとんどのベンダーは通知を受けてから迅速に修正を完了させた。ZenGoもそれによって複数のバグ懸賞金を獲得した。

この研究事例で注目すべき点は、修正方法自体が比較的シンプルだったことだ——シミュレーション環境内の環境変数を、便宜上のゼロ値やヌル値ではなく、実際のチェーンの状態から取得した意味のある具体的な値で埋めるようにするだけで、悪意あるコントラクトが「自分がシミュレートされているか」を判断するために依拠していた根拠を失わせることができた。しかしこの修正は、公に研究されたこの特定の一つの手法にしか対処できず、将来まだ発見されていない新たな環境の違いが悪用されないことを保証するものではない。これこそが、ほとんどのセキュリティ研究者が「シミュレーション環境が実際の環境と完全に区別不可能な状態を実現できるかどうか」を、継続的にリソースを投じ続けなければ優位を維持できない長期的な競争だと考える理由だ。

一般ユーザーにとって、この概念の最も実践的な参考価値は、あるシミュレーションツールの背後にある技術的な実装が安全かどうかを自分で判断することを求めるものではなく（それは一般ユーザーが自分で判断できる範囲をはるかに超えている）、取引シミュレーションツールへの期待値を調整することにある——シミュレーション結果は非常に信頼性の高いシグナルだが、絶対に迂回できないものではない。これは特定の高リスクの状況下では、シミュレーション結果自体に頼らない判断方法を追加で取る価値があることを意味する。具体的には、ある取引のシミュレーション結果が異常に有利で、合理的な範囲を明らかに超えた見返りを示している場合（例えばわずかな金額で何倍もの価値がある資産を得られるなど）、この「うますぎる」というシグナル自体が、鵜呑みにすべき朗報としてではなく、警戒を高めるべき手がかりとして扱われるべきだ——攻撃者がシミュレーション結果を偽装してユーザーを騙す最も強い動機を持つのは、まさにこの種の一見損をすることのない取引だからだ。

もう一つ身につける価値のある習慣は、取引シミュレーションを唯一の判断根拠としないことだ。特に出所不明のコントラクト、稼働開始からまだ日が浅いコントラクト、あるいは著名なプロトコルと意図的に酷似するよう設計されたコントラクトに直面した際にはなおさらだ。完全に独立した情報源（ブロックチェーンエクスプローラーのコントラクトソースコード照会機能、あるいはコミュニティ内での他のユーザーによるそのコントラクトに関する議論や報告など）を使って追加でクロスチェックすることは、シミュレーション結果自体が不正確な可能性がある状況において、第二の判断根拠を提供してくれる。この原則の背後にあるロジックは、本サイトが繰り返し強調している「単一の防御線だけに頼らない」ということと本質的に同じだ。シミュレーションツールは非常に効果的な第一の防御線だが、どんな単一の防御線も特定の状況下では回避されうる。複数の防御を重ねることこそが、比較的確実な方法なのだ。