イーサリアムのクライアント、ETH報酬を横取りされ得る脆弱性を修正

インドの証明書会社で起きた暗号処理上の不備がイーサリアムにも波及し、攻撃者が一部バリデータのブロック報酬を自身のアドレスに転送できた可能性があった。バリデータの多くがイーサリアムのプルーフ・オブ・ステーク（PoS）運用に使うソフトウェア「Teku」は火曜日、バージョン26.10.3を公開した。イーサリアムのトランザクション処理を担う「Besu」は月曜日、バージョン26.10.2を公開した。両アップデートは、多くの運用者が使うパッケージ済みDockerイメージ内で、インドの認証局eMudhraに紐づく証明書を信頼しないようにした。バリデータはETHをステークしてイーサリアムを保護し、ブロック提案の手数料を得るコンピューター。一部はインターネット経由で他のサービスと通信し、正しい相手と接続していることを確認するためにデジタル証明書を使う。10月17日、研究者はeMudhraの8つの中間認証局の秘密鍵が、乱数が不十分な状態で生成されていたことを発見した。鍵は公開されている証明書自体から算出できた。鍵を持つ者は、未修正のソフトウェアが本物と認める証明書を発行できた。ブラウザーは証明書をブロックし、eMudhraは翌日に失効させた。同社はその後、証明書事業から撤退すると表明した。TekuとBesuが動作するプログラミング言語Javaは、既定では証明書の失効確認を行わない。このためTekuのDockerイメージは、ブラウザーが拒否した後も問題の証明書を信頼し続けた。バリデータと接続先サービスの中間に位置する攻撃者は、そのサービスになりすませた。Tekuはセキュリティ勧告で、この手口でだまされたバリデータが、手数料を攻撃者のアドレスに支払うブロックを提案する可能性があると説明した。バリデータの鍵を保管する別サービス「外部サイナー」になりすませば、報酬の送金先を変更するための署名を渡す可能性があり、Tekuはこれを最もリスクの高い構成と位置付けた。「メインネット上の既定のTekuノードは影響を受けず、対応も不要」とチームは記し、「悪用された報告はない」と付け加えた。TekuのセキュリティパートナーであるConsensys Diligenceが最初に問題を指摘した。Dockerを使わず、TekuやBesuを直接マシン上で動かす運用者はJavaを自ら更新する必要がある。イーサリアム用ソフトを更新しても、Javaの信頼済み証明書リストは変わらないためだ。新しいDockerイメージもホスト上のJavaを修正しない。Java 26を使い続ける利用者の対応はより難しい。Tekuは同バージョンがサポート終了で修正版を提供しないとし、Java 25への移行を求めている。