Teku と Besu は、eMudhra イベント後に、脆弱な証明書キーが外部サービスへの接続ソフトウェア、および一部のイーサリアムバリデーターのデプロイにリスクをもたらしたため、それぞれの Docker イメージを更新しました。
- Teku 26.10.3 および Besu 26.10.2 では、eMudhra イベントに伴い、Docker イメージから影響を受ける証明書の信頼を削除しました。
- Tekuの表示では、デフォルトでメインネットノードには影響がありません。実際の露出度はHTTPS接続および運用者が使用するJavaランタイムに依存します。
- 公開されたリスクは、なりすましサービスとバリデーターの操作に関係していますが、Tekuの通知では悪用された事例は報告されていません。
運営者にとって、現在最も直接的な問題は、他のサービスに接続する際に自社のソフトウェアが偽造証明書を受け入れるかどうかです。この答えは使用している接続方法とJavaのインストール状況によって異なるため、クライアントの更新がすべてのバリデータに同じリスクをもたらすわけではありません。
Teku と Besu の Docker イメージを更新
イーサリアムクライアントチームは、ブロックチェーン外で発生した証明書の問題を修正するための更新をリリースしました。関連する変更は、リモートサービスが本物であるかどうかをソフトウェアが判断する方法に影響します。
Teku 26.10.3 および Besu 26.10.2 は、影響を受ける証明書のルートに対する信頼を Docker イメージから削除しました。このリリースは、証明書発行機関 eMudhra に関連する弱い鍵が発見されたことを受けて実施されました。
バリデータオペレーターにとっての課題は、攻撃者がソフトウェアが接続するサービスをなりすますことです。このサービスの役割によっては、偽の応答が責任の分担を混乱させたり、一部のブロック手数料の支払い先に影響を及ぼす可能性があります。
しかし、これはすべてのイーサリアムバリデーターがリスクにさらされていることを意味するわけではありません。Tekuのセキュリティ通知によると、デフォルトのメインネットノードは影響を受けず、現在のところ悪用された事例は報告されていません。
違いはインストール方法にあります。外部HTTPSサービスを使用する運用者は、完全にローカル化されたコンポーネントのデプロイでは必ずしも存在しない接続を確認する必要があります。
これらの更新は特定のインストール環境に適用されます。パッチ適用後のDockerイメージには、コンテナ内にパッケージ化されたランタイムの変更が含まれており、アーカイブファイルからインストールされたソフトウェアは、運営者が別途提供するJavaを使用する可能性があります。
このイベントはバリデーター周辺のインフラに影響を与えましたが、イーサリアムのコンセンサスルールは変更されていません。
なぜ証明書の問題がセキュリティリスクに発展するのでしょうか？
証明書は、ソフトウェアが意図したサービスに接続しているかを判断するのに役立ちます。信頼できる証明書発行機関は、サーバー証明書に対応するアイデンティティを保証します。
このメカニズムはHTTPSウェブサイトで一般的ですが、ブラウザを通さない通信を行うアプリケーションにも適用されます。バックエンドサービスもこれらの認証に依存している可能性があります。
証明書発行機関は、信頼されたルート証明書の下に中間証明書を使用する可能性があります。これらの中間証明書に関連する秘密鍵は、追加の証明書を発行するために使用される可能性があるため、安全に保持する必要があります。
このイベントでは、問題は単に誰かがサーバーの通常のログイン情報を手に入れたことだけではありません。影響を受けた中間鍵は、すでに公開されている情報から復元できます。
Goセキュリティチームの説明によると、この脆弱性により、マイクロ秒単位で秘密鍵を復元することが可能である。また、攻撃者は自身が制御していないドメインの証明書を生成できるとされている。
脆弱なアプリケーションが、その証明書が信頼する機関に最終的に遡れる場合、それを受け入れる可能性があります。これにより、偽装身份が本来不正な者を拒否するために設けられたチェックを回避する可能性があります。
しかし、攻撃者は依然として被害者の接続を拦阻またはリダイレクトする方法を必要とします。弱い鍵は、自動的に各ユーザーと各サーバーの間に攻撃者を出現させるわけではありません。
この条件は攻撃が発生する方法を制限しますが、証明書の無効化を無害にはしません。ソフトウェアが偽装者を真のエンドポイントと認識する限り、ネットワークのインターセプトはより危険になります。
Kudelski Security の調査は、影響を受けた証明書の階層を検討しました。問題は、ソフトウェアが攻撃者が再現可能な鍵によって発行された証明書を受け入れる可能性があることです。
eMudhraは、弱い鍵を処理エラーに起因すると述べています。
eMudhraのイベント声明によると、研究者が10月17日に8つの弱い中間キーを報告し、同社は翌日これらの8つのキーを無効化しました。
同社は、これらの中间証明書が2025年4月30日の鍵儀式で生成されたと述べている。同社によると、欠陥のあるwrapおよびunwrapステップは、元の強力な鍵に加えて弱いコピーを生成していた。
同社は、認証済みのハードウェアセキュリティモジュールを使用していると述べ、故障の原因をこうしたデバイスの欠如ではなく、周辺プロセスのいずれかのステップに起因すると説明した。
また、会社は7つの中間証明書が本番環境で使用されたことはなく、残りの1つも証明書が発行されていないと述べました。会社は、今回のイベントによりインフラが侵害されたり、データが漏洩したりしていないと述べています。
これらの主張は、eMudhraがその内部運用について説明した内容を裏付けている。しかし、ソフトウェアベンダーはまだ別の可能性に対応しなければならない：他の者が復元可能なキーを利用することである。
証明書システムは、元の運営者が今後一切の証明書を発行しないという約束にのみ依存してはなりません。他の誰かが特定の署名鍵を再現できるようになると、その保証は作成可能なすべての証明書を制御できなくなります。
したがって、対応策は鍵を生成した会社を超え、ブラウザベンダー、オペレーティングシステムベンダー、プログラミング言語チームも、自社ユーザーのソフトウェアが何を受け入れるかを考慮する必要があります。
これらの修正は、異なる更新を通じてユーザーに提供されます。ブラウザはブロックリストを受け取る可能性がありますが、別の独立したJavaアプリケーションは依然として古い信頼された証明書セットを使用し続ける可能性があります。
弱キーとそのキーを受け入れるアプリケーションは、同じ問題の二つの異なる部分である。証明書の無効化は機関の記録レベルでの問題を解決するが、クライアントには、影響を受けた信頼パスを拒否すべきであることを確実に識別する手段が必要である。
外部サービスはバリデーターに異なるリスクをもたらします
イーサリアムノードは、異なる役割を担うソフトウェアで構成されています。イーサリアムクライアントのドキュメントでは、実行クライアントとコンセンサスクライアントを区別しています。前者はトランザクションの実行とステートを処理し、後者はプルーフ・オブ・ステークコンセンサスに従います。
バリデーターソフトウェアには、ブロックを提案し、チェーンを証明する責任が追加されました。オペレーターは、これらのコンポーネントをローカルで実行するか、外部サービスを通じて一部を接続できます。
Tekuはコンセンサスクライアント、Besuは実行クライアントです。両方ともJavaを使用しているため、実行時の証明書の信頼性はそれらのリリースに関連しています。
ローカルマシン以外のサービスは、この設定に追加の認証を課します。ソフトウェアは、リクエストに応答したエンドポイントが期待される提供元であることを確認する必要があります。
たとえば、運営者は署名操作を同じプロセス内に保持するのではなく、リモート署名サービスを使用する可能性があります。また、外部エンドポイントにデータやブロック構築サービスを依存する場合もあります。
偽装者の造成する被害の大きさは、そのサービスが許可されている機能に依存します。監視データの受信のみを行うサービスと、署名決定に参加する情報提供サービスでは、リスクは異なります。
ネットワークパスも同様に重要です。公共インフラを経由する接続は、同一ホスト内または厳密に管理されたプライベートネットワーク内のコンポーネント間の接続と比べ、攔截の機会が異なります。
プライベートネットワークはすべての障害を防ぐことはできませんが、攻撃者がトラフィックを妨害するために必要な位置を取得する機会を減らすことができます。
したがって、クライアント名だけでは露出の有無を判断することはできません。同じソフトウェアは、異なるエンドポイント、トラストストア、アクセス制御を使用する環境にデプロイされる可能性があります。
真正に回答すべき質問は、どの接続が影響を受けたパスを通じて証明書を受け入れたかです。これを明確にすれば、運用者は、偽装されたサービスが検証者の動作において本来持つべきだった権限の範囲を評価できます。
なぜDockerイメージとアーカイブインストールは異なるのですか？
Dockerイメージは、アプリケーションとその実行に必要な環境を一緒にパッケージ化します。これにはJavaランタイムや、そのランタイムが信頼する証明書が含まれる場合があります。
ホスト上のJavaを更新しても、既存のイメージ内のJavaは自動的に置き換えられません。コンテナは引き続きパッケージ化されたファイルを使用し続ける可能性があります。
これがクライアントのリリースノートでDockerの変更が特に言及されている理由です。Tekuの説明によると、当時そのEclipse Temurinベースイメージには該当の削除が含まれていなかったため、クライアントイメージ自体が直接変更されました。
Besuのリリースノートでは、証明書の削除がDockerイメージにも適用され、自己提供のJavaディストリビューションを使用しているユーザーが確認することを明確に要求しています。
アーカイブインストールでは、この責任を運用者に委ねます。イーサリアムクライアントはすでに更新されている可能性がありますが、その個別のランタイムには依然として古い証明書ストアが含まれている可能性があります。
逆に、メンテナンス中にも同様の違いが生じます。ホストランタイムを交換すると、そのランタイムを使用するプロセスに影響を与えますが、別のJavaパスを使用するインストールには影響しません。
Oracleのイベントは、影響を受けるランタイムを更新するか、ドキュメントに記載された代替案に従うようユーザーに推奨しています。また、実行中のインスタンスを再起動し、各独立したインストールを個別に考慮するよう求めています。
これにより、実行中のプロセスがダウンロードされた更新よりも重要になります。サーバーにはパッチが適用されたファイルが含まれている可能性がありますが、古いプロセスは置き換えられるか再起動されるまで継続して実行されます。
カスタム証明書ストアに、さらに別の変更が加わりました。ある組織は、Javaのデフォルト証明書ストアだけでなく、自社サービスのために維持している証明書ストアを使用する可能性があります。
実際のタスクは、クライアントが実際に何を使用しているかを特定することです。インストール方法、実行時の場所、信頼設定の3つが、公開されたパッチがその必要がある接続に到達したかどうかを決定します。
異なるアプリケーションにおける取り消しチェックの違い
取り消しは、証明書がもはや受け入れられてはならないことを意味します。しかし、これは各アプリが接続を確立する前に最新の取り消し情報を確認することを保証するものではありません。
アプリケーションごとに、これらの情報を取得する方法は異なります。一部はオンラインサービスを照会し、一部はベンダーが提供するブロックリストを使用し、また一部はローカルトラストストア内の証明書に主に依存します。
Goチームの対応は、ランタイムベンダーが直接関与する必要がある理由を説明しています。同チームは10月19日に緊急セキュリティリリースを開始し、通知を受け取ってから約7.5時間以内にパッチ版を提供したと述べています。
この操作は、関連するGo検証アクションを使用するアプリケーションにおける影響を受けた証明書パスをブロックします。Javaユーザーは、自身のランタイムおよび信頼設定を通じて保護を受ける必要があります。
Tekuの通知によると、Javaのデフォルトではrevocationチェックは行われません。これが、eMudhraがこれらの中间証明書をrevocationしたにもかかわらず、ローカルで信頼を削除する必要がある理由です。
ルート証明書の削除と中間証明書のブロックは、異なるレベルで機能する可能性があります。前者は特定の損傷したパスを拒否し、後者は削除されたルート証明書に至るより広範な証明書チェーンを拒否できます。
正しい実装は、ベンダーとアプリケーションを保守する組織に属します。一時的に認証を無効にする做法は、信頼の問題を解決するのではなく、保護を削除するだけです。
合法なサービスでも調整が必要な場合があります。それらの証明書がクライアントが今後拒否するパスに依存している場合、サービス提供側はユーザーが不安全な信頼を復元することを期待するのではなく、受け入れ可能な代替案を提供しなければなりません。
これにより、1つの証明書イベントが数日間続く理由も説明できます。発見は即座に可能发生しますが、保護はブラウザ、パッケージ化アプリ、プライベートインフラストラクチャの異なるリリースおよびメンテナンスプロセスを通じて段階的に実装されます。
バリデーターオペレーターにとって、重要な結果は、信頼できないアイデンティティの接続が拒否されたかどうかです。ソフトウェアエコシステムの他の場所での失効通知は、ノードプロセスがこの結果に達したことを証明しません。
報酬とバリデーターのステーキングは同じようにリスクが伴いますか？
バリデーターのステーク、署名の責任、および手数料の支払いは相互に関連していますが、それぞれ異なるメカニズムによって制約されています。いずれかの要素に影響を与える問題は、これらすべてに対する制御を自動的に意味するものではありません。
イーサリアムのステーキングドキュメントでは、バリデーターは責任を果たすことで報酬を得られ、オフライン状態や証明可能な不適切な行動に対してペナルティを受けます。署名権限と引き出し権限は、システム内で異なる役割を果たします。
証明書キーは接続用の認証システムに属しています。これはバリデーターの秘密署名キーではなく、质押されたETHの引き出し権限を直接漏洩することはありません。
ただし、偽装されたサービスは依然としてバリデーターの行動に影響を与える可能性があります。その影響は、そのサービスがどのリクエストまたはレスポンスを処理し、どの追加チェックが維持されているかに依存します。
ブロック提案には、実行に関連する支払いの受取先が含まれます。あるパスが提案または設定を変更できる場合、质押全体を制御せずに結果が生じる可能性があります。
署名サービスは、認証者の行動を承認する際に、別のセットの問題を引き起こします。このサービス自身の保護メカニズム、たとえばリクエストの制限や衝突署名を防ぐための対策は、攻撃者がどの程度の行動を可能にするかに影響します。
サービス停止による責任の不履行も、可能性のある結果の一つです。支払いの移転が成功しなくても、攻撃者が正しい応答を阻止することで、報酬を減らす可能性があります。
これらの結果の財務的影響は異なります。提案されたブロックの機会損失、通常のオフラインペナルティ、およびスラッシングペナルティは、混同してはいけません。
クライアント公告は、影響を受けた設定下で発生し得る結果を説明しているだけで、すべての運営者がこれらの結果を経験したことを証明するものではなく、対応する量のETHが盗まれたことも証明していません。
质押サービスプロバイダーを利用している保有者にとって、実際に重要なのはサービスプロバイダーの実際のデプロイです。管理されているETHの量では、運営者がどのリモートサービスや証明書ライブラリを使用しているかを示すことはできません。
バリデーターはイーサリアム以外のソフトウェアにも依存しています。
イーサリアムネットワークのルールは、オペレーターが依存する要素の一部に過ぎません。ハードウェア、ランタイム、ホスティング、設定、外部サービスも、バリデーターが適切に役割を果たすかどうかに影響します。
証明機関はイーサリアムプロトコルの外部に存在するが、バリデーターソフトウェアがサービスを識別するためにそれを依存している場合、その障害は関係してくる。これだけでも、汎用的なインターネットセキュリティの問題をステーキングインフラに持ち込むことになる。
クライアントの多様性は、異なる実装が単一のコードベースへの依存を減らすため依然として価値があります。しかし、これはすべての依存関係が独立していることを意味するわけではありません。
二つのクライアントは同じプログラミング言語ランタイムを使用できます。異なる運営者も、同じホスティングサービス、署名サービス、またはブロック構築インフラストラクチャを使用する可能性があります。
これらの共有コンポーネントは、イーサリアムソフトウェア自体が異なる場合でも、共通の暴露面を形成します。したがって、デプロイ状況を理解するには、クライアントブランドの数だけを確認するのでは不十分です。
外部委託にもトレードオフが伴います。専用の署名サービスは鍵の保護方法を改善する可能性がありますが、そのサービスとの認証接続の重要性も高まります。
ローカルで実行する場合にも、独自の保守要件があります。コンポーネントを同じマシンに配置することで、一部のネットワーク暴露を減らすことができますが、運営者はソフトウェアの更新とそのマシンへのアクセスを管理し続ける必要があります。
このイベントは、すべての状況で最も安全なアーキテクチャを自動的に提示するものではありません。周囲の各接続の責任を理解し、維持することが必要であることを示しています。
この違いは、一般のETHユーザーにとっても重要です。ノードインフラにおける証明書のパッチは、すべてのウォレットが資金を移動する必要があることを意味するわけではなく、イーサリアムアカウントの残高に変化があることを意味するわけでもありません。
関連する行動は、影響を受けたソフトウェアの運用者に属します。彼らのみが、関与するランタイム、エンドポイント、信頼設定を特定し、これらの接続を構築しているシステムにベンダーの関連ガイドラインを適用する能力を持っています。
運営者は更新を適用し、確認する必要があります
これらのリリースにより、運用者はサポートされているDockerイメージから影響を受けた信頼パスを削除できるようになります。アーカイブされたユーザーは、それぞれのJavaベンダーのガイドに従って、個別のランタイム対応を行う必要があります。
パッチの適用はプロセスの第一歩に過ぎません。更新後の環境が実際に動作し、予期される設定とサービスが正常に機能しなければなりません。
サービス提供者にとって、最近拒否された証明書によって引き起こされた中断は、エンドポイントでの証明書の交換を必要とする可能性があります。サービスを復旧する際には、認証を回避するのではなく、維持する必要があります。
今後の開示により、影響の詳細がさらに明確になる可能性があります。運用者は、影響を受けた証明書チェーンを受け入れている構成を特定したり、特定のサービスに関連するイベントを報告したりする可能性があります。
現在のところ、Tekuの通知レポートは利用されておらず、デフォルトのメインネット使用と影響を受けた外部接続を区別しています。これは、現在のイーサリアムの攻撃面を説明する最も明確な根拠です。
影響を受けた運営者は更新する理由があります。あらゆる財務的損失は、攻撃者がどのサービスを偽装したか、トラフィックをブロックしたかどうか、およびバリデーターがそのサービスに何を許可したかに依存します。
何に注目すべきですか
- クライアントの更新：Teku と Besu のリリースを確認し、パッチ適用済みのバージョンを実行していることを確認してください。
- Java証明書：各インストールで使用されているJavaランタイムおよび証明書ライブラリのベンダーガイドを参照してください。
- 外部リンク：リモート署名、データ、およびブロック構築サービスを指すHTTPSリンクを確認してください。
- セキュリティ通知：クライアントチームおよびJavaベンダーから発表された攻撃の確認または追加情報にご注意ください。
よくある質問
eMudhraイベントとは何ですか？
このイベントは、証明書発行機関eMudhraの中間証明書に関連する弱い秘密鍵を含んでいます。研究者は、これらの鍵が公開情報から復元可能であることを発見し、これにより第三者が自身が制御していないドメインの証明書を生成する可能性があります。この証明書パスを信頼するソフトウェアは、このような偽装されたアイデンティティを受け入れる可能性があります。攻撃者は依然として、ターゲットサービスを模倣するために、接続を傍受またはリダイレクトする何らかの手段を必要とします。
イーサリアムのコンセンサスは失敗したのか？
いいえ。レポートで指摘された問題は、イーサリアムがブロックチェーン上で合意するルールではなく、ソフトウェアが外部サービスの身元を検証する方法に関係しています。クライアントの更新は、影響を受けるソフトウェア環境における証明書の信頼性を変更します。一部のバリデーターのデプロイでは、外部サービスが偽装された場合に依然として運用リスクが生じる可能性があります。この可能性は接続とサービスの役割に依存しており、イーサリアムのコンセンサスルールが破壊されたことを意味するものではありません。
どのクライアントが更新されましたか？
Teku 26.10.3 および Besu 26.10.2 は、影響を受ける証明書の信頼を削除するために、Docker イメージを更新しました。Teku はコンセンサスクライアント、Besu は実行クライアントであり、両方とも Java を使用しています。この変更は、これらのイメージに提供される環境に適用されるため、インストール方法が重要です。クライアントアーカイブをインストールし、独自に Java ランタイムを提供する運用者は、そのランタイムのガイドラインを個別に確認する必要があります。
すべてのバリデーターに影響がありますか？
いいえ。Tekuの通知では、デフォルトのメインネットノードは影響を受けないとされています。リスクは、特定のデプロイが関連する外部HTTPS接続を実行しているかどうか、およびその証明書チェックが影響を受けた信頼パスを受け入れているかどうかに依存します。異なる運用者は、同じクライアントを異なるサービス、Javaバージョン、証明書ライブラリで実行できます。したがって、クライアント名や质押されたETHの数では、特定のバリデーターが暴露されているかどうかを判断できません。
Dockerの更新はすべてのインストール方法を上書きできますか？
できません。パッチ適用後のDockerイメージは、そのイメージにパッケージ化された環境を更新しますが、アーカイブインストールでは運用者が別途提供したJavaが使用される可能性があります。他のコンテナやサービスも独自のランタイムを持つ可能性があります。運用者は、実行中のプロセスがどのインストール方法を使用しているかを特定し、そのベンダーの指示に従う必要があります。サーバー上のパッチ適用済みファイルは、依然として旧環境で実行中のプロセスを保護できません。
利用されていることが確認されましたか？
本文の記載時刻において、Tekuの通知は侵害が発生したとは報告していません。関連する開示は、脆弱性とその可能性のある結果について述べたものであり、攻撃者がそれをバリデーターに利用したことを証明するものではありません。損失について議論する際、この違いは重要です。サービスを装う可能性のある経路が存在するということは、署名の責任が操作され、手数料の支払いが転送され、または质押されたETHが盗まれたことを意味しません。
バリデーターの預金は自動的に公開されますか？
いいえ。証明書署名キーは、バリデータ署名キーや引き出し権限の認証情報とは異なります。影響を受けた証明書キーを回復しても、质押されたETHを引き出すために必要なキーが自動的に漏洩することはありません。偽装されたサービスが、デプロイ方法に応じて責任の分担を混乱させたり、バリデータが使用する情報に影響を及ぼす可能性があります。このサービスを全額預金への自動アクセスと見なすのではなく、その可能性のある影響を評価すべきです。
運営者はどのように行動すべきですか？
運営者は、関連するTekuまたはBesuのリリースノートおよびそのJavaリリースのガイドラインに従う必要があります。コンテナ内に含まれるものを含め、各影響を受けるプロセスで使用されているランタイムと証明書ストアを特定する必要があります。推奨される更新を適用した後、更新されたサービスが正常に動作し、必要な接続が依然として正常に機能することを確認してください。失敗した接続の復元のために証明書チェックを無効にすると、そのチェックが提供すべき保護が削除されます。