OpenSSLの脆弱性「CVE-2022-3602」と「CVE-2022-3786」に関するセキュリティアドバイザリー

JITHIN PRAJEEV NAIR, LIDOR PERGAMENT

November 01, 2022 - 5 分で読了

コンテンツ

記事
おすすめのブログ

背景

2022年11月1日、OpenSSLは2つの重大度の高いセキュリティ上の欠陥に関するアドバイザリー「CVE-2022-3786 (X.509メールアドレスの可変長バッファーオーバーフロー)」および「CVE-2022-3602 (X.509メールアドレスの4バイトのバッファーオーバーフロー)」を公表しました。この脆弱性はOpenSSLのバージョン3.0.0以降に影響を及ぼし、OpenSSL 3.0.7で修正されています。

問題の詳細

OpenSSLセキュリティアドバイザリーで公表された脆弱性の詳細は次のとおりです。

CVE-2022-3786

バッファーオーバーランは、X.509証明書の検証、特に名前制約のチェックで発生する可能性があります。これは証明書チェーンの署名検証後にCAが悪意のある証明書に署名したか、信頼された発行者へのパスを構築できないにもかかわらず、アプリケーションが証明書検証を継続することで発生します。攻撃者は証明書内に悪意のあるメールアドレスを作成して、スタック上の「.」文字(10進数の46)を含む任意のバイト数をオーバーフローさせることができます。このバッファーオーバーフローによりクラッシュ(サービス拒否の一因)が発生する可能性があります。TLSクライアントでは、悪意のあるサーバーへの接続がこの問題を誘発する可能性があります。また、TLSサーバーでは、サーバーがクライアント認証を要求して悪意のあるクライアントが接続した場合に発生する可能性があります。

CVE-2022-3602

バッファーオーバーランは、X.509証明書の検証、特に名前制約のチェックで発生する可能性があります。これは証明書チェーンの署名検証後にCAが悪意のある証明書に署名したか、信頼された発行者へのパスを構築できないにもかかわらず、アプリケーションが証明書検証を継続することで発生します。攻撃者は悪意のあるメールアドレスを作成して、スタック上で攻撃者が制御する4つのバイトをオーバーフローさせることができます。このバッファーオーバーフローは、クラッシュ(サービス拒否の一因)またはリモートコード実行を発生させる可能性があります。多くのプラットフォームはスタックオーバーフロー保護を実装しているため、リモートコード実行のリスクが軽減されます。このリスクはプラットフォームやコンパイラーのスタックレイアウトによっても、さらに緩和される可能性があります。CVE-2022-3602の事前発表ではこの問題の重大度は「深刻」と位置付けられていましたが、上記の緩和要因を考慮したさらなる分析の結果、「高」に引き下げられました。ユーザーは引き続き、できるだけ早く新しいバージョンにアップグレードすることが推奨されます。TLSクライアントでは、悪意のあるサーバーへの接続がこの問題を誘発する可能性があります。また、TLSサーバーでは、サーバーがクライアント認証を要求して悪意のあるクライアントが接続した場合に発生する可能性があります。

影響を受けるバージョン

OpenSSLのバージョン3.0.0～3.0.6がこの脆弱性の影響を受けています。信頼できないソースから受信したX.509証明書を検証するOpenSSL 3.0アプリケーションは、脆弱であると考える必要があります。これには、TLSクライアントとTLSクライアント認証を使用するように構成されたTLSサーバーが含まれます。OpenSSL 1.0.2、1.1.1、およびそれ以前のバージョンは影響を受けません。

各組織で行える対策

OpenSSL 3.0.0～3.0.6のユーザーは早急に3.0.7にアップグレードすることが推奨されます。オペレーティングシステムのベンダーまたはその他のサードパーティーからOpenSSLのコピーを入手した場合は、できるだけ早く更新バージョンを要求してください。

TLSサーバーを運用しているユーザーは、修正が適用されるまでTLSクライアント認証を無効にするよう検討することをお勧めします。

Zscalerでは、組織を保護するために実行すべき手順を記したブログも公開しています。

Zscalerクラウドへの影響はゼロ

Zscalerでは調査完了後、Zscalerのクラウドコンポーネントがこの脆弱性の影響を受けないことをお客様にお知らせするZscaler Trustの記事を発表しました。

従来型のNGFWアプライアンスや仮想マシンではなく、ZscalerのようなクラウドネイティブのSSEプラットフォームを採用する主なメリットの1つとして、スプロール化した旧式のハードウェアアプライアンスや仮想マシン全体のソフトウェアにパッチを適用する運用オーバーヘッドを排除できる点が挙げられます。2022年3月に発生したOpenSSLの脆弱性CVE-2022-0778に対して、パッチの適用がわずか数日で完了したのはこのメリットの好例といえます。

Zscalerがこの脆弱性からユーザーを保護する方法

現時点でこれらの脆弱性に対する悪用の試みは確認されていませんが、セキュリティ研究者は悪用を成功に導くPOCを公開しています。ThreatLabzは、Zscalerが保護するエンドユーザーを狙った脅威アクティビティーを積極的に監視し、対処します。この問題はTLSクライアントとTLSサーバーの両方に影響を与える可能性があるものの、mTLS(サーバーがクライアントも認証する相互TLS)は広く使用されていないため、クライアントが悪意のあるクライアントTLS証明書を使用してサーバーを悪用する可能性ははるかに低くなると考えられます。

Zscalerのプロキシに基づいたアーキテクチャーとSSLインスペクションサービスは、悪意で作成されたサーバー証明書を介してエンドユーザーを狙う試みに対し、優れた防御を提供します。Zscalerは信頼できる中間者(MITM)として、宛先TLSサーバーのクライアントブラウザーであるかのようにクラウド内ですべてのサーバー証明書を一元的にスキャンして検証し、Zscalerまたはお客様が発行するCAによって署名された新しいサーバー証明書を発行します。こうすることで、不正な証明書がエンドユーザーに到達するのを防ぎます。

お客様がSSL/TLSインスペクションを有効にしている限り、Zscalerは次の図のように脅威に対する防御を提供します。

1. 攻撃者は、特別に細工されたX.509証明書を提供してOpenSSLの脆弱性を引き起こす悪意のあるサイトをホストします。

2. エンドユーザーは不正な誘導により、TLSインスペクションが有効になっているZscalerを介して、悪意のあるサイトにアクセスしようとします。

3. サーバー名が望ましくないものとして確認されている場合、Zscalerはすぐに接続を切断します。

4. それ以外の場合は、クライアントからのTLSハンドシェイクリクエストを終了させて、宛先サーバーとの独自のハンドシェイクを開始します。

5. Zscalerは、ServerHelloの後でサーバーから送信された証明書を検証します。ZscalerはOpenSSLの脆弱性に対して影響を受けないため、Zscalerのインフラは安全です。

6. Zscalerはドメイン証明書を生成し、エンドユーザーに送信します。その際、適切に生成されたX509証明書のみを発行するため、悪用の試みは効果的に中和されます。悪意のある証明書がエンドユーザーに到達することはありません。

図1: OpenSSLの脆弱性を悪用する試みをZscalerのTLSインスペクションが防止

SSLインスペクションの仕組みやSSLプロキシとしての主な責任については、こちらのブログをご覧ください。

Zscalerがこの脆弱性の影響を受ける企業のワークロードを保護する方法

ワークロードに関しては、Zscaler Posture Controlが組織のAWS、Azure、GCP環境のすべてをスキャンし、注意が必要な資産の特定と優先順位付けを行います。12%のお客様がすぐに効果を実感し、こうした問題に対して脆弱なワークロードを検出しています。なお、脆弱なワークロードの大半は、特に外部公開された資産で検出されています。

参考資料