本文の内容は、2022年11月1日にMichael Clarkが投稿したブログ（https://sysdig.com/blog/stop-openssl-vulnerability-cve-3786/)を元に日本語に翻訳・再構成した内容となっております。
OpenSSLプロジェクトチームは、10月25日、OpenSSL v3バージョン3.0.6までのすべてのバージョンに影響を及ぼす2つのHIGH severityの脆弱性（CVE-2022-3602、CVE-2022-3786）を発表しました。これらの脆弱性は、11 月 1 日にリリースされたバージョン 3.0.7 で修正されています。OpenSSL 1.X バージョンは脆弱性の影響を受けません。 CVE-2022-3602 は当初、深刻度 CRITICAL としてタグ付けされていましたが、いくつかの OpenSSL パートナー組織による 1 週間のテストの後、最も一般的な構成とプラットフォームでは、バグを悪用する可能性が十分でないことが判明しました。 したがって、OpenSSL は重大度を HIGH にダウングレードしました。
修正された脆弱性には、X.509 証明書検証の名前制約チェック部分における 2 つのスタックベースのバッファ オーバーフローが含まれます。 メンテナーによると、認証局 (CA) が悪意のある証明書に署名するか、信頼できる発行者へのパスがないにもかかわらず、脆弱なアプリケーションが証明書の検証を続行する必要があります。 TLS クライアント構成 (別名相互認証) では、クライアントが悪意のあるサーバーに接続すると、脆弱性がトリガーされる可能性があります。 TLS サーバー構成では、サーバーがクライアント認証を指定し、クライアントが悪意のある証明書に接続すると、バグに到達する可能性があります。
注目すべき主なリモートアクセス可能なバグ（CVE-2022-3602）は、攻撃者が悪意のある電子メールアドレスを作成し、攻撃者が管理するデータでスタック上の4バイトをオーバーフローさせてしまうというものです。スタックレイアウト（使用するプラットフォームアーキテクチャやコンパイラによって変化する）によっては、攻撃者がサービス拒否（DoS）を達成するのに十分な可能性がありますが、リモートコード実行（RCE）の可能性は低いと思われます。前回の CVE と同様に、最も一般的なコンパイラとプラットフォームの組み合わせを評価した結果、オーバーフローしてしまうバッファは未使用となり、エクスプロイト（RCE または DoS）は不可能であることが判明しました。また、1997年以降、ほとんどのプラットフォームでは、様々な手段でスタックベースのバッファオーバーフロー対策が施されています。高度な攻撃者は、より少ない人数でより多くのことを行うようになったため、パッチ適用が依然として重要であることを理解する必要があります。
今回のパッチで修正されたもう一つのバグであるCVE-2022-3786も、オーバーフローの長さだけが攻撃者に制御されていることから、HIGHと評価されています。このバグにより、攻撃者は任意の数の「.」文字でバッファーをオーバーフローさせることができ、リモートコード実行への暴露は、どのプラットフォームでも想定されません。ここでは、最新のOpenSSLの脆弱性を阻止する方法を５つのステップで紹介します。
1. 脆弱性のあるワークロードやホストの発見
OpenSSLは、インターネット上のほとんどのソフトウェアに暗号化およびセキュアな通信機能を提供するソフトウェアライブラリです。OpenSSL は、Apache や NGINX などのソフトウェアで、TLS（Transport Layer Security）を介して HTTP 接続を保護するために使用されていることで、最もよく知られています。OpenSSLライブラリーはユビキタスで、ネットワークをまったく使用しないアプリケーションであっても、さまざまなアプリケーションに含まれ、使用されています。もし暗号が関係しているならば、OpenSSLが使われていることは間違いないでしょう。例えば、Apacheサーバーの管理者はgrepというツールを使って、Apacheの設定ファイルでTLSクライアント認証が有効になっているかどうかを確認することができます。返された行が SSLVerifyClient のステータスが “require” であれば、TLS クライアント認証は有効になっています。
```
grep -n SSLVerifyClient
grep -n “SSLVerifyDepth 1
``` OpenSSLはどこにでもあるので、完全な可視性を得るのは難しいかもしれません。もしあなたがそれを見ることができないなら、それを修正することはできません。OpenSSLが使用されている場所を特定するために、クラウドとオンプレミムの両方で、ホストとコンテナ環境をチェックする必要があります。最初のステップは、影響を受けるワークロードと資産のリストを提供するマニフェストベース（別名SBOM）脆弱性管理ツールを使用することです。エージェントレス脆弱性管理ツールは、オンプレミス環境の評価が困難であるため、それだけに頼ることはできないことを覚えておくことが重要です。
しかし、OpenSSL は、自社で管理していないネットワーク上の機器でも使用することができるため、これだけでは十分ではありません。これらのデバイスからOpenSSLのバージョンを検出できる従来の脆弱性スキャナーが強く推奨されます。多くのインシデント対応作業は、これらの管理されていないデバイスが重要なパッチを適用しないまま放置されていることが原因です。
2.使用されているものに優先順位をつける
スキャンを実行した後、影響を受けるワークロードやホストの非常に長いリストが出来上がってしまうかもしれません。合理的な時間内にこれらすべてに対応することは不可能であるため、リストは、修正することが本当に重要なものに絞り込まれる必要があります。多くのパッケージは、OpenSSL を含んでいても、実際にはそれを使っていないかもしれません。これは、偶然入っていたり、使わないアプリケーションの一部に過ぎないなど、様々な理由で起こり得ます。チームは、ランタイムインサイト（例：ランタイムにロードされたパッケージを見る）を活用して、パッケージが使用されているかどうかを判断する必要があります。これにより、ノイズを排除し、本番環境で本当に動作しているものだけに焦点を当てることで、小麦と籾殻を分けることができます。リストが管理しやすいサイズになったので、どのワークロードが重要かを理解することで、さらに優先順位付けを行うことができるようになりました。コンテナ、クラウド、Kubernetesのメタデータをレポートに融合させることで、本番環境と開発など、どのワークロードが重要かを理解することが容易になります。インターネットからトラフィックを受け取るホストやワークロードも、リストの上位に表示されるはずです。このようにリストを短くすることで、意思決定がさらに管理しやすくなります。
Sysdigは、影響を受けるopensslのバージョンを持つすべてのイメージを分析し、そのうちのいくつが本番環境で本当に稼働しているかを調べました。注：この情報を抽出した時点では、openssl 3.xブランチを含むイメージのインストールベースは、他のバージョンと比較して比較的少なかったです。3.xブランチが広く採用されるにつれて、このパーセンテージは変化する可能性があります。
3.脅威の修復または軽減
理想的な世界では、脆弱性を使用するすべてのアプリケーションは簡単に修正でき、何の問題も生じません。しかし、悲しいことに、これは私たちが生きている世界ではありません。重要なホストとワークロードが特定されたら、修正をデプロイするために、それらを担当するチームが関与する必要があります。もし、コンテナやそのイメージの中にあるのなら、開発チームがOpenSSLのアップデートに責任を持つべきです。ただし、OpenSSLがベースイメージ、つまりOSに含まれている場合は、別のチームが責任を負う可能性があります。コンテナランタイム（CRI）やKubernetesからのメタデータは、アプリケーションが何であるか、どのチームがその開発に責任を持つかをレポートから直接理解することを可能にし、このプロセスを単純化することができます。OpenSSLがホスト上に存在する場合、インフラストラクチャーチームはパッケージのアップグレードを任務とする必要があります。
重要なシステムであっても、新しいバージョンがアプリケーションを破壊したり、他の問題を引き起こしたりすることがあるため、直ちにパッチを適用することは常に可能とは限りません。この場合、脆弱性の緩和を試みるのが最善です。OpenSSLプロジェクトが現在推奨している対処法は、ライブラリーのパッチが適用されるまでクライアントのTLS認証を無効化することです。
4.悪用された場合の検知と対応
本脆弱性を利用した攻撃は、クラッシュ（サービス拒否）として現れる可能性が最も高いですが、リモートでコードが実行される可能性もあります。この脆弱性は、Apache などのクライアント TLS 認証を行うアプリケーションで発生する可能性があります。もし成功すれば、攻撃者は通常非特権アカウントである apache のパーミッションを使用してアクセスします。ここから、特権を上げ、目標に向かうために、標準的な搾取後の活動が行われるでしょう。Sysdig Secureは、このような侵入後の活動を検知するための信頼性の高いポリシーを2つ提供しており、これらはデフォルトで有効になっています。
- Sysdig Runtime Threat Intelligence
- Sysdig Runtime Threat Detection
これらには、プレミアム脅威インテリジェンスに基づくルールとFalcoのルールが含まれます：
- dev/shmからの実行
- Linuxカーネルモジュールインジェクションの検出
- 疑わしいCronの変更
- Sudoの潜在的な特権のエスカレーション
その他の脅威の検出に関する情報およびルールについては、以下のリソースを参照してください。
- CVE-2022-42889 (別名 Text4shell) の検出と緩和策
- BPFDoor (no e!) によるファイアウォールの破壊 – Falco を用いた検出方法
- ファイルレスマルウェアによる読み取り専用コンテナの侵害
5.修復が行われていることを確認する
OpenSSL の脆弱性の修正は、アトミックな操作ではなく、サイクルです。 脆弱性管理ツールを使用して環境のステータスを継続的に再評価し、アプリケーションとシステムにパッチが適用されていることを検証する必要があります。 この検証が行われる頻度は、脆弱性管理のポリシーと目標によって異なります。まずは、1日1回レポートを実行するようスケジューリングするとよいでしょう。このレポートには、まだ脆弱性が残っているシステムが表示され、修正されたシステムはレポートから除外されます。RiskSpotlight を活用すれば、脆弱性のあるバージョンの OpenSSL を使用し始めたばかりのワークロードも報告されるので、遅滞なく対処することができます。
まとめ
OpenSSLの脆弱性は、ありがたいことに、Heartbleedのような事態にはならないことが判明しました。しかし、リサーチャーが当初はエクスプロイト不可能と考えたバグのエクスプロイトが以前から公開されています。したがって、脆弱性管理のプロセスを完全に行使することは、依然として重要かつ価値あることです。インシデント対応や他の分野と同様に、実践は脆弱性に対処するための重要な要素であり、ギャップを明らかにするのに役立ちます。Sysdig Secureの脆弱性管理は、特にFalcoベースの脅威検知・対応機能と組み合わせることで、プロセス全体をはるかに容易にすることができます。
Sysdig Secureは、コンテナやクラウドにおける侵害を検知・阻止し、新たな脆弱性の影響を受けているかどうかを迅速に把握することを支援します。今すぐお試しください！