regreSSHion (CVE-2024-6387) の脆弱性で見る FutureVuls での脆弱性管理

先日 OpenSSH の脆弱性（CVE-2024-6387）が公開され、随所で騒がれました。
OpenSSH はサーバへセキュアにリモート接続する目的で利用されるもので、多くのシステムで使われることもあり話題になりました。
本ブログでは、脆弱性管理サービスの FutureVuls を利用していると、この脆弱性がどのように検知され、どのように対応していくかについて説明していきます。

OpenSSHの脆弱性に関する背景

Qualys の調査によると、インターネットに公開されている潜在的に脆弱な OpenSSH のサーバインスタンスは 1400万台以上と、多くのサーバで利用されています。今回の regreSSHion の脆弱性では、 glibcベースの Linux システムで、root として認証されていない任意のリモートコード実行の恐れがあると書かれています。もし悪用されると、システムが完全に乗っ取られ、マルウェアのインストールやデータ操作、永久的なアクセスをするためのバックドアが仕込まれるなどの懸念事項があるようです（詳細）。
また、侵入者は攻撃後に root アクセスを得られるようになると、組織の内部をセキュリティメカニズムを迂回しながら移動して、さらに被害を拡大させます。
ランサムウェアはインターネットに面したところから侵入されるケースが多く、今回の OpenSSH のような状況が該当します。 regreSSHion は RCE な脆弱性であるため、侵入されたとすればランサムウェアの餌食となるでしょう。

ところで、7月に KADOKAWA がランサムウェアの被害にあった騒ぎがありました。その際に、Twitter（現 X）で以下のような投稿がありました。
弊社の神戸も登壇した「ジョーシストーーク」のブログでも掲載されているこの投稿を引用します。

分かる。分かりすぎる。

ちょうどこの OpenSSH の話題が出たときに、お客様からも同じような質問を受けました。

• 「この脆弱性は我が社のシステムに影響があるのだろうか」
• 「これに急いで対応しないといけないのか分からず困っている」
• 「サーバの各担当者に夜の今から連絡してもどうせ対応してくれないだろう」

ご安心ください。FutureVuls でこれらの悩みを解消できます。

手動での脆弱性対応フロー

例えば以下のような流れで対応を進めるとします。

1. 脆弱性が話題になっていることを SNS などを通じて知る
2. 対象のソフトウェアが自組織にあるか、そのバージョンは何かなどの情報確認をする
3. 脆弱性の深刻度・ベンダーのパッチ状況・緩和策などの対応方法を調査する
4. この脆弱性への対応がどの程度重要か判断する
5. 必要にあれば担当者に連絡して、脆弱性への対応を依頼・説得する必要がある

大変ですね。セキュリティ対策に慣れている方でもこれらに対応していくには労力が要ります。
ましてや脆弱性対策に慣れていない方だと尚のこと大変です。
また脆弱性の種類によっては、急いで対応をしなければ被害に遭う可能性もあるという、時間的な制約もありえます。

FutureVulsを導入している場合

CVSS の課題を解消する SSVC

昨今は年間約3万件の新たな脆弱性が報告されており、また急速に進化するサイバー脅威に対応するため、スピーディーかつ適切な対応を求められます。
脆弱性対応する際に利用される指標の１つに、脆弱性の深刻度を0から10までのスコアで表現するCVSS（Common Vulnerability Scoring System）があります。しかし、 CVSS ベースでの対応では真に高リスクな脆弱性を絞り込むことが困難であり、課題となっています。
FutureVuls ではその CVSS での課題を克服するために、SSVC というフレームワークに則った対応優先度決めを推奨しています。 SSVC（Stakeholder-Specific Vulnerability Categorization） とは、脆弱性の対応優先度をリスクベースで判断できるフレームワークです。米国の CISA でも利用が推奨されており、昨今注目を集めています（参考）

FutureVulsを使った脆弱性対応フロー

上記の対応フローについて、FutureVuls を導入しているとどのようになるでしょうか。

	手運用の場合	FutureVuls を導入している場合
1	脆弱性が話題になっていることを SNS などを通じて知る	脆弱性情報が公開されたらスキャナが自動で検知・通知
2	対象のソフトウェアが自組織にあるか、そのバージョンは何かなどの情報確認をする	各サーバのソフトウェア・バージョン情報をスキャナが常に把握
3	脆弱性の深刻度・ベンダーのパッチ状況・緩和策などの対応方法を調査する	脆弱性の一次情報・攻撃情報・パッチ状況・緩和策などを参照可能
4	この脆弱性への対応がどの程度重要か判断する	SSVC により自動判断、緊急対応が必要であれば通知
5	必要にあれば担当者に連絡して、脆弱性への対応を依頼・説得する必要がある	FutureVuls上で対応を依頼 対応が必要な判断理由もSSVCにより明確に分かる

ほとんど全ての作業が自動化され、「検知された脆弱性への対応方針を決定」「対応する場合連絡する」という5.の部分だけを人手でやれば十分になります。

対象のサーバにスキャナを入れておくことで、各サーバの最新の構成情報を常に把握できます。
もしもその中に脆弱性が存在していれば、 FutureVuls で自動で検知され、脆弱性が見つかったことが通知されます。
これにより、巷の話題を知らなくても脆弱性の存在に気が付くことができるでしょう。

また、脆弱性の対応優先度を自動で判断してくれ、その判断根拠も SSVC により明確です。
例えば脆弱性が週末や夜中に発覚した場合を考えてみましょう。
脆弱性が新たに検知された場合にも、システム担当者は FutureVuls で対応が必要かを確認するだけで十分です。
急いで脆弱性の情報を調べ、自組織に影響があるのかを検討し、対応優先度の決定を判断する、という対応をする必要がありません。
もし重要度が高く、対応が必要な場合でも、なぜそのような対応が必要なのかという判断理由を SSVC 決定木から確認できます。
そのため、合理的な判断理由を補足しながら担当者に依頼でき、両者の納得感が増します。

このように脆弱性対応のフローが自動化されていると、人的コストの削減だけでなく担当者の心理的負担も解消され、より良い運用が可能となるでしょう。

FutureVulsコンソールでの脆弱性確認

実際に FutureVuls コンソールでどのような情報が取得できているのかを見てみましょう。

FutureVuls 上でも脆弱性の情報が公開されたタイミングで CVE-2024-6387 の脆弱性は検知されています。
脆弱性の詳細画面では、各種ベンダーが公開している CVSS スコアとベクターを確認できます。CVSS スコアは 8.1 と「Critical」になっています。深刻度だけで見ると優先対応した方が良さそうです。

※ 実際には自組織に影響があるのか、という観点を考慮した リスク評価 をするべきなので、このような判断は非推奨です。

その下には、この脆弱性の EPSS スコアの値と公開されている各種攻撃コードを確認可能です。

2024年7月12日時点で、 EPSS スコアの値は 36.87 ％（97 percentile）とかなり高い値になっていました。7月8日時点では EPSS スコアの値が 4.85 ％だったので、数日で値が大きく変化しています。その値が変動している理由までは EPSS では分かりません（参考）

攻撃コードがいくつか公開されていることが分かりますが、いずれも「有効な攻撃手法ではない」信頼度が低いもののみのようです。

さらに下に、警戒情報や緩和策などの公開情報、CWE や各種参考情報が一覧で表示されています。
CISA KEV カタログなどの警戒情報などは出ていないようです。
また、Red Hat からこの脆弱性に関する緩和策が提供されているようです。パッチの適用が難しい場合、このリンクを辿って緩和策を施すと良いでしょう。
下の Reference には、この脆弱性に関する各ベンダーから提供されている情報などがリストアップされています。

脆弱性が検知されたあと、実際に脆弱性に対応していく際には、上記のような多くの情報をひとつひとつ調べていく必要があります。FutureVuls にはこれらの情報も集約されており、FutureVuls を起点として対応調査にとりかかれます。
逐一「Exploit-DB や CISA KEV カタログに登録されていないか」「攻撃コードの活用状況はどうか」「パッチや緩和策は公開されていないか」などの調査に翻弄されることはありません。

FutureVuls による脆弱性の対応判断

この脆弱性が、 SSVC によりどのように判断されているかを見てみましょう。
SSVC では、サーバが置かれている環境（Exposure）と、そのサーバの事業影響度（Utility Density / Human Impact）を事前に設定しておきます。脆弱性が検知されると、その脆弱性の攻撃利用状況などの外部情報（Exploitation）と、攻撃が自動化できるか（Utility Automatable）という情報を取り込み、決定木に従って対応優先度を算出します。

あるシステムでは、以下のような環境値の設定になっています（一般的なWebサーバを想定）

SSVC Decision Point	Value	意味
Exposure	open	インターネットから制限なしにアクセス可能なシステム
Utility Density	concentrated	重要情報が集中している
Human Impact	high	基幹業務に長期間影響が出る

このシステム内にあるサーバで CVE-2024-6387 が検知されると、その SSVC Priority の値は下図のように「scheduled（定期メンテナンス時に対応する）」となっていました。

決定木の判断ポイントを見ると、以下の原因からこの SSVC Priority になったことが分かります。

• Exploitation : poc（PoC や攻撃コードが公開されている）
• Utility Automatable ： no（攻撃を自動化できない）

攻撃コードはいくつか公開されているが、明確に効果的な PoC や活発な観測、KEV 等への掲載などが無いことから、Exploitation は PoC レベルという判断になっています。また、攻撃手法が複雑で、自動化できるものではないことから、Utility Automatable も自動化できないという判断になっています。 SSVC による判断は妥当と言えるでしょう。
そのため、「即座に対応しなければならない」レベルの脆弱性ではなく、「定期メンテナンス時に対応すればよい脆弱性だ」と判断できます。
これでシステム担当者の方も安心して夜に眠ることができますね。

※ なお、このHuman Impact の値を very high （攻撃を受けると業務続行不能で回復不能になるもの）に変更すると、SSVC Priority の値は 「Out-Of-Cycle（通常よりも迅速に行動し、計画外の機会に緩和策または修復策を実施する）」に変化しました。

日常的な脆弱性管理の運用フロー

SSVC を導入している場合、日常的にはどのように対応していけば良いのでしょうか。
SSVC は Immediate / Out-Of-Cycle / scheduled / defer の4段階に脆弱性対応の優先度を振り分けます。

各対応優先度は以下のようになっています。

対応優先度	意味
Immediate	全てのリソースを集中し、必要に応じて組織の通常業務を停止して可能な限り迅速に対応する
Out-Of-Cycle	通常よりも迅速に行動し、計画外の機会に緩和策または修復策を実施する
scheduled	定期メンテナンス時に対応する
defer	現時点では対応しない

基本的にはリスクの高い順に、 Immediate > Out-Of-Cycle の順に対応していき、その後 scheduled の対応をしていく、という流れになります。

SSVC による絞り込みは非常に強力で、 Immediate と Out-Of-Cycle に分類される脆弱性の量は数％程度で、大半が scheduled / defer に分類されます。運用リソースが足りない場合には、ひとまずリスクの高い脆弱性に対応しておくのが良いでしょう。
（SSVC 機能でどれだけリスクの高い脆弱性を絞り込むことができるのか、というシミュレーション結果がこちらにあります）

上記のものに対応できたら、続いて scheduled に分類された脆弱性への対応へと移ります。
しかし、中には scheduled に分類された脆弱性（自組織ではリスクが低いため、定期メンテナンス時に対応すればよい脆弱性）の中にも、数カ月待たず早期に対応できるとよい脆弱性があります。それは、警戒情報が公開されていたり、将来その脆弱性が悪用される確率を表す EPSS スコアが高い脆弱性などです。
リスクは Immediate や Out-Of-Cycle に比べると低いものの、他の環境では影響度が高いものとして注意されています。そのため、SSVC Priority が同じ scheduled の中でも、さらに細かい優先度付けをして対応できるとよいでしょう。FutureVuls ではこのような指標でのフィルターやソートも可能なため、より細かい優先度付けが可能になります。

実際に、CVE-2024-6387 は SSVC Priority が scheduled に判断されましたが、EPSS スコアは比較的高い値になっています。
自組織に大きな影響があり、喫緊で対策しなければならない脆弱性は SSVC で捕捉します。それ以外に今回の regreSSHion のような、自組織には影響しないが世間で話題になっている脅威度の高い脆弱性は、 EPSS の情報などで捕捉できます。
このような複数の指標を鑑みることで、自組織に影響度の高い脆弱性から順に対応していくことができ、最小の運用負荷で最大のセキュリティ対策効果が得られます。

なお EPSS や脆弱性の対応優先度付けについては以下のブログを参照してください。

• EPSS入門：脆弱性管理を変革する新指標の理解と活用方法
• 脆弱性対応の戦略とフレームワーク

FutureVulsの利点と導入のすすめ

FutureVuls は SSVC という強力な脆弱性トリアージエンジンを搭載しており、組織の脆弱性管理を徹底的に自動化し、運用負荷の削減に貢献しています。
このような運用フローがあることにより、脆弱性管理に不慣れな場合でも、自組織に深刻な脆弱性を発見・対応していくことができるでしょう。
手運用で資産管理・脆弱性対応をしているチームの方がいたら、FutureVuls の利用を検討していただけると幸いです。

警察庁の報告によると、最近のランサムウェアの感染経路には、 VPN 機器やリモートデスクトップなどテレワーク等に利用される機器などの脆弱性や、強度の弱い認証情報を利用したものがあるようです（参考）。
組織内部にあるサーバやネットワーク機器などの脆弱性管理ができていないと、このようなランサムウェアの被害に遭い、さらに被害が拡大してしまう可能性もあります。そのためにも、暫定的な脆弱性診断だけでなく、継続的な脆弱性管理も重要なセキュリティ対策になります。

製品の詳しい説明を聞きたい、実際の画面操作をデモ形式で見たい、などの要望があれば、お気軽にお問い合わせください。
製品の無料トライアルも承っております。以下のページの「お問い合わせ」よりどうぞ。
https://vuls.biz/csirt-lp/