aelfが確認した内容
aelfは8月26日の進捗報告で、未承認のスマートコントラクトがトランザクションパラメータを使い、エンコードされた.NETアセンブリと命令をノードのコントラクト実行経路へ送り込めたと説明しました。分析した5種類のペイロードには、ホストコマンドの実行、結果の収集と外部送信の試行、ノード関連の鍵や設定オブジェクトへのアクセス、インフラ偵察の機能が含まれていました。
aelfは、この活動に関連する155件のトランザクション（AELF MainChainで127件、tDVV dAppChainで28件）を特定しました。報告時点で本番ネットワークは正式に再開しておらず、公開トランザクション送信も停止中です。一般利用者の資産の不正移転やウォレット鍵の漏えいを示す証拠は確認されていない一方、ノードとインフラの認証情報が露出した可能性は未解明です。aelf自身も、これは最終的な原因報告ではなく調査中の評価だと明記しています。
コード検査はサンドボックスの一層にすぎない
今回報告された経路はaelfだけの問題ではありません。マネージドコードを使うブロックチェーンでは、台帳上のコントラクトが決定論的でも、実行ランタイムが強力なホスト機能を継承するという危険な不一致が起こり得ます。静的検査や許可リストは既知の危険な構造を減らせますが、リフレクション、動的ロード、ネイティブ連携、シリアライズの挙動、ランタイム版の差異による迂回をソースコード検査だけで封じることはできません。
本番環境の境界は、コントラクト検証が失敗する前提で設計すべきです。実行には独立した最小権限プロセスなどの強い隔離領域を用い、署名情報への暗黙のアクセスをなくし、ファイルシステムを最小限かつ読み取り専用にし、外向き通信を原則遮断し、システムコールと資源使用を制限して、コンセンサス状態へのインターフェースを狭く定義します。署名処理は別サービスまたはハードウェア保護された境界に置き、ノード上のコード実行がそのまま署名権限にならないようにする必要があります。
復旧は稼働率ではなく証拠の問題
aelfが示した復旧条件は参考になります。関連する鍵と認証情報のローテーションまたは失効、信頼できるソースからの環境再構築、既知ペイロードとその亜種を使った恒久的なCodeOps・隔離修正のテスト、決定論的リプレイと台帳継続性の検証、独立したセキュリティレビューです。RPCエンドポイントへの到達やノードのブロック生成は可用性を示すだけで、完全性の証明にはなりません。
再開判断は、署名付きビルドの来歴、独立検証したチェックサム、認証情報ローテーションの完了、再現可能な台帳状態、ブリッジや取引所の記録照合、クリーンなホストからの外向き通信監視と結び付けるべきです。これらを復旧証跡として保存しなければ、サービスが安全に復元したのか、侵害環境が正常らしい出力を再開しただけなのかを区別できません。
Ineezaの見解
今回の事案は、スマートコントラクトVMが敵対的コードを実行する基盤でもあることを改めて示しました。持続的な対策はスキャナーの高度化だけではありません。危険なコードを拒否し、通過したコードを封じ込め、認証情報を実行環境から分離し、ホストの挙動を監視し、検証可能な復旧証跡がそろうまで金融サービスを再開しないという多層防御が必要です。