Zscalerのブログ
Zscalerの最新ブログ情報を受信
購読するOpenSSLの脆弱性「CVE-2022-3602」と「CVE-2022-3786」に関するセキュリティ アドバイザリー
背景
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セキュリティ アドバイザリーで公表された脆弱性の詳細は次のとおりです。
バッファー オーバーランは、X.509証明書の検証、特に名前制約のチェックで発生する可能性があります。これは証明書チェーンの署名検証後にCAが悪意のある証明書に署名したか、信頼された発行者へのパスを構築できないにもかかわらず、アプリケーションが証明書検証を継続することで発生します。攻撃者は証明書内に悪意のあるメール アドレスを作成して、スタック上の「.」文字(10進数の46)を含む任意のバイト数をオーバーフローさせることができます。このバッファー オーバーフローによりクラッシュ(サービス拒否の一因)が発生する可能性があります。TLSクライアントでは、悪意のあるサーバーへの接続がこの問題を誘発する可能性があります。また、TLSサーバーでは、サーバーがクライアント認証を要求して悪意のあるクライアントが接続した場合に発生する可能性があります。
バッファー オーバーランは、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%のお客様がすぐに効果を実感し、こうした問題に対して脆弱なワークロードを検出しています。なお、脆弱なワークロードの大半は、特に外部公開された資産で検出されています。
参考資料
