重大な OpenSSH の脆弱性のリグレッションに関するガイダンス
エグゼクティブサマリー
CVE-2024-6387 は、2006 年の CVE のリグレッションに起因する OpenSSH の重大なリモートコード実行(RCE)の脆弱性です。
攻撃を実行するためには競合状態に勝利する必要があり、攻撃が成功するまでに数時間または数週間かかる可能性があります。
推奨される対策は、glibc ベースの Linux システムで、影響を受けていないバージョンの OpenSSH サーバーにパッチを適用することです。それが不可能である場合のために、潜在的な影響を緩和するための別の緩和オプションについて説明しています。
また、脆弱性のある OpenSSH のバージョンを検知する osquery も記載しています。
OpenSSH の脆弱性の背景と技術分析
最近、OpenSSH の新しい重大な脆弱性(CVE-2024-6387)が Qualys Threat Research Unit によって発見されました。この脆弱性は、不正な RCE につながる可能性があります。2024 年 7 月 1 日、彼らは脆弱性 CVE-2006-5051 のリグレッションに関する 調査結果 を発表しました。この脆弱性は 2006 年にパッチが適用され、2021 年に再発していました。
同 CVE の根本原因は、ユーザー認証がタイムアウトする際の安全でない信号処理が原因で発生する競合状態です。タイムアウト時に SIGALRM 信号が生成され、これがヒープ管理ルーチンを実行しているスレッドへの割り込みを引き起こします。シグナルハンドラー自体がヒープ管理ルーチンを呼び出すと、予期しないふるまい(このケースでは任意のコードの実行)が発生する可能性があります。
現在では、この脆弱性の悪用に関する 公開概念実証 (PoC)があるため、既知の脆弱性となっています(この PoC は Akamai と提携していないサードパーティが提供しているため、コードとのインタラクションを試みる前にご自身でデューデリジェンスを実施してください)。この脆弱性は重大ですが、悪用を成功させるための制約がいくつかあることが PoC で明らかになっています。主な制約の 1 つは、悪用に要する時間です。システムによって数時間かかる場合もあれば、1 週間かかる場合もあります。その他の制約として、オペレーティングシステムのディストリビューションや、OpenSSH サーバーのバージョンと設定などがあげられます。
影響を受ける対象
この脆弱性は、多くのバージョンの OpenSSH に影響を及ぼします。たとえば、ほとんどの Linux ディストリビューションはデフォルトで OpenSSH を搭載して出荷されるため、影響を受けます。
この脆弱性の根本原因は OpenSSH のコードのリグレッションであるため、非常に古いバージョンの OpenSSH サーバーは元の CVE の影響を受け、(リグレッション前の)新しいバージョンは影響を受けません。
この記事の公開日時点で、この脆弱性の影響を受ける既知の OpenSSH バージョンは次のとおりです。
この脆弱性の旧バージョン(CVE-2006-5051)は、OpenSSH 4.4/4.4p1(2006-09-27)より前のバージョンの OpenSSH に影響を及ぼしています(CVE-2006-5051 および CVE-2008-4109 のパッチが適用されている場合を除きます)
この脆弱性のリグレッションは、バージョン OpenSSH 8.5/8.5p1(2021-03-03)で発生しました
OpenSSH のメンテナーは、バージョン OpenSSH 9.8/9.8p1(2024-07-01)内でこの脆弱性を修正しました
影響を受けるサーバーを検索するためには、次の Insight クエリーを使用します。
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
Akamai の調査によると、 75% のネットワークには脆弱なバージョンの OpenSSH を搭載したマシンがあり、平均するとネットワーク内のマシンの約 35% が脆弱でした。幸いなことに、Akamai が監視している環境では、恣意的にインターネットに開かれている SSH ポートのあるマシンはまだ確認されていません。しかし、 Shodan を手早く検索してみると、 脆弱なバージョンを搭載しているマシン 600 万台以上にアクセス可能 であることが分かります(図を参照)。
潜在的な影響
この脆弱性はデフォルトで OpenSSH に影響を及ぼすため、潜在的な影響は非常に大きくなります。ほとんどの Linux ディストリビューションに影響を及ぼしますが、リグレッションが発生したため、特に新しいバージョンに影響を及ぼします。
しかし、次の 3 つの注意点を念頭に置けば、大パニックに陥るのを回避できます。
現在の PoC は x86 マシンのみを対象としています。なぜなら、現在の標準である amd64 マシンではメモリー保護が強化されているため、脆弱性の悪用が極めて困難だからです。
現在、攻撃をトリガーして成功させるためには、長い時間と複数の接続が必要であると考えられています。そのため、ほとんどの総当たり攻撃検知機能がトリガーされるはずです。
上記の 2 つの注意点があるため、この攻撃はインターネットからの初期アクセスベクトルに適しているようです。一部の影響は、インターネット SSH 接続と、インターネットに面した SSH インターフェース(ジャンプボックスなど)を必要とするマシンからのトラフィックに適切なセグメンテーションを使用することで、緩和することができます。
緩和
パッチ適用
最も明白な対策は、脆弱なバージョンではなく最新バージョンの OpenSSH にパッチを適用することです。ただし、OpenSSH は通常、Linux ディストリビューションにバンドルされているため、パッチの適用はベンダーのパッチリリース次第であり、さらなる時間とテストを要する可能性があります。
ネットワーク管理者は、このブログ記事に記載されている osquery を使用して、脆弱な資産を検知し、時間の経過に合わせて追跡できます。また、Akamai Guardicore Segmentation を利用しているお客様は、その目的のためにスケジュールされたクエリーを使用し、クエリー結果に基づいて資産にラベルを付けることができます。
セグメンテーション
前述のとおり、この CVE の悪用はネットワークへの初期の侵入に適している可能性が高いです。なぜなら、攻撃を成功させるためには、数日とはいかないまでも、数時間はかかるからです。 したがって、インターネット OpenSSH インターフェースのすべてのインスタンスをマッピングし、それらへのアクセスを閉じるか制限することが重要です。
インターネットからの任意の SSH アクセスが必要である場合は、そのマシンにネットワークセグメンテーションを適用して、内部ネットワークへのアクセスを制限し、攻撃や侵害が発生した場合の影響範囲を限定することが推奨されます。
脅威アラートの感度
パッチがすでに利用可能であるとは限らないため、脆弱でありパッチが適用されていない可能性のあるワークロードに対するアラートの感度を上げるのが賢明です。そうすることで、脆弱性が検知されず悪用されても、その後の影響を多少認識することができます。特に、総当たり攻撃が実行される可能性が高いため、総当たり攻撃の試みに対する感度を上げることが推奨されます。
ただし、アラート感度を上げると、アラート疲れも増大します。そのため、ネットワークに対する影響を受けるワークロードの重要性や影響力に応じて、アラートの感度を調整することもお勧めします。
まとめ
このブログ記事では、OpenSSH の重大な脆弱性のリグレッションに関する入手可能な情報を確認しました。この脆弱性は、最近パッチが適用され、公開されたものです。
防御者にとって重要なのは、ネットワーク内のワークロードの脆弱性を特定することです。そのためのサポートとして、OpenSSH の脆弱なバージョンを検知するための osquery を記載しました。また、パッチを適用できない場合に、一部のリスクを緩和するためにすべきことについても説明しました(脅威アラートの感度の調整など)。
このブログ記事では、現在入手可能な情報に基づいた Akamai の見解と推奨事項について概要を紹介しています。Akamai ではレビューを継続的に行っているため、本資料に含まれる情報は変更される可能性があります。また、Akamai の X アカウントでリアルタイムの更新情報を確認できます。