共有依存関係がPHPの脆弱性を公共サービスのリスクに変える

SecurityScorecardのSTRIKE脅威インテリジェンスチームは、公開時点でSecurityScorecardが観測したインターネット向け資産のうち、760万件以上がPHPを実行していることを確認しました。

広く使われているPHPコンポーネントでは、1つの未パッチの脆弱性が数十もの機関を同時に危険にさらす可能性があります。

PHPをめぐるこのニュースはパッチ適用だけの問題ではありません。ここ数日で明らかになった、広く使われているプログラミング言語の2件の重大な脆弱性は、公共サービスを停止させる可能性があり、共有依存関係によって被害が拡大するおそれがあります。

CloudflareのCTO（最高技術責任者）は、PHPを狙った初期の攻撃の試みが出始めていると述べ、同社が緊急のWAF（Webアプリケーションファイアウォール）ルールを展開したと明らかにしました。PHPを開発するセキュリティチームはパッチを公開しましたが、多くの組織にとっては、悪用される前に十分迅速にパッチを適用できるかどうかが問われます。

SecurityScorecardのSTRIKE脅威インテリジェンスチームは、SecurityScorecardが観測したインターネット向け資産のうち、約600万件がPHPを実行していることを確認しました。非常に大きな規模であり、1つの脆弱性が見つかれば多数のシステムに一斉に波及し得ます。セキュリティチームは、どのサービスが脆弱なシステムに依存しているのか、そして、同じホスティングプロバイダー、MSP、基盤技術に依存している機関がいくつあるのかを把握する必要があります。

現時点で分かっていること

PHPのメンテナーは10月20日にセキュリティリリースを公開しました。2件の脆弱性は、CVSS（共通脆弱性評価システム）v4で9.2と評価されています（詳細はCVE Detailsを参照）。watchTowrの研究者は、CVE（共通脆弱性識別子）の候補と、PHP 5以降のすべてのバージョンに及ぶ可能性のある影響範囲を報告しています。

公開されたパッチによって、攻撃者は何が変更されたかを把握できるため、防御側は今後数日のうちに悪用の試みが起きると想定すべきです。

STRIKEチームが観測した600万件のエクスポージャーの詳細は、技術ブログをご覧ください。

自社の対応で得た教訓

私たちは助言するだけでなく、自社の資産全体でこの問題に対応しました。他の組織にも役立つと思われる教訓を紹介します。

• 「PHPアプリは1つしか使っていない」はほぼ間違いです。
  当初は1つのアプリだと考えていましたが、実際にはマネージドホスティング上のそのアプリ、複数のクラウドアカウントにあるセルフマネージドVM、サポート終了バージョンのままのコンテナ、現在のどのチームも所有していない放置されたデモ用サーバーにまでPHPが散らばっていました。資産インベントリは、関係者への聞き取りではなく、スキャンとクラウドテレメトリから作成すべきです。忘れられた資産こそ、外部に露出していることが多いのです。
• 到達可能なオリジンの前にあるWAFルールは、見せかけに過ぎません。
  エッジプロバイダーは数時間以内に緊急ルールを提供しましたが、このルールが機能するのは、通信が実際にエッジを通過する場合に限られます。当社のリスクが最も高いホストのいくつかは、クラウド上のオリジンIPアドレスへ直接名前解決されており、攻撃者はWAFを完全に迂回できました。ルールを展開しただけでは対策になりません。オリジンに直接到達できないことを確認して初めて対策になります。
• 「8.2.35にパッチする」という手順は、実際のパッチ適用の現場では通用しません。
  多くのマネージドLinuxディストリビューションでは、アップストリームのバージョン番号はパッケージマネージャーに表示されず、バックポートされたリビジョンが提供されます（当社の場合は、UbuntuによるUSN-8948-1の修正）。追跡すべきは、アップストリームのバージョン番号ではなく、ディストリビューションのアドバイザリです。そうしないと、リポジトリに存在しないリリースを探して時間を無駄にしかねません。また、サポート終了（EOL）が、必ずしも全面的な置き換えを意味するわけではありません。延長サポートのチャネルでは、7.4や5.xに対してもバックポートが提供されました。
• 誰がパッチを適用するかは運用者によって決まるため、初日から作業を分担してください。
  マネージドサイトのプロバイダーは自社でパッチ対応を行いましたが、当社はそれでもベンダーにチケットを起票し、実際にパッチが適用されたかを確認しました。セルフマネージドのホストは当社の責任でした。「対象範囲外」は「無視してよい」という意味ではありません。評価範囲外のサブドメインも、自社の攻撃対象領域の一部です。
• この脆弱性はメモリをリークするため、パッチ適用がゴールではありません。
  2つの脆弱性のうち1つは、プロセスメモリ（トークン、鍵、認証情報など）を開示し得ます。外部に公開されているホストで探りを入れられた形跡が少しでもあれば、秘密情報が読み取られた可能性があるとみなし、ローテーションしてください。パッチは穴を塞ぎますが、攻撃者がすでに持ち出したものを元に戻すことはできません。
• 対応にあたっては、自社ツールの出力を確認してから行動してください。
  自動化された脆弱性レポートでさえ、対応中に再確認が必要でした。修復計画を立てる前に、PHPのアドバイザリやディストリビューションのセキュリティ通知など、信頼できる情報源に照らして検出結果を確認してください。ツールの出力は手がかりであり、絶対的な真実ではありません。

詳しくは、当社のお客様向けアドバイザリブログをご覧ください。

まずは、維持しなければならない公共サービスから着手する

最初にPHPのバージョンを確認してください。PHP 8.1以前はサポートが終了しているため、公式の修正は提供されません。影響を受けるバージョンと修正済みバージョンは、PHPの公式通知で確認し、サポート対象外のシステムについてはアップグレードを計画してください。

次に、優先順位の付け方を変えましょう。パッチの未適用分を一律に扱う方法では、すべての脆弱なシステムが同じ扱いになります。行政機関や多くの民間企業は、そのような方法を取る余裕はありません。まず、どの公共サービスがこれらのシステムに依存しているか、そして攻撃者がそれらを侵害したり停止に追い込んだりした場合に何が起きるかを考えてください。

そのうえで、ミッションへの影響度で順位を付けます。公共の安全や緊急サービスを支えているのはどのシステムでしょうか。あるいは、医療、交通、給付や決済、選挙、その他の重要な市民サービスが脆弱になるおそれはないでしょうか。

共有依存関係が共通の単一障害点を生む

見落とされがちなリスクが「集中」です。複数の機関や重要インフラ事業者が、同じホスティングプロバイダー、MSP、または基盤技術に依存していることがあります。そうした1点が侵害されれば、すべてに一斉に波及するおそれがあります。

これにより、数え方が変わります。機関ごとに数百件の別々のエクスポージャーに見えるものが、実際にははるかに少ない共有の単一障害点に行き着く場合があります。それぞれの障害点が、無関係に見えるサービスにまで連鎖的な障害を引き起こし得ます。問うべきは、どのシステムが脆弱かだけではありません。どの公共サービスがそれらに依存しているのか、そして何組織が同じ単一障害点を共有しているのかです。

今すぐ依存関係をマッピングしてください。優先度の高いサービスの背後にどのプロバイダーがいるのか、そしてそのうちどれが近隣の機関にもサービスを提供しているのかを特定します。

何をオンラインに残すかは、結果に基づいて判断する

システムをオンラインのままにするかどうかは、結果に基づく判断です。各サービスを、ミッションへの影響が最も大きいものから順に、次の6つのカテゴリでスコア付けしてください。

当社のトリアージで得た注意点が1つあります。検出件数で順位を付けないでください。当社で最も検出件数が多く、数百件の検出があったホストは、最も危険なホストではありませんでした。最も重要だったのは、稼働中でインターネットに公開されており、全ポート範囲が開いていたホストで、検出件数ははるかに少ないものでした。生の件数ではなく、到達可能なエクスポージャーと想定される影響で優先順位を決めてください。

サービスをオフラインにすればデータは守れるかもしれませんが、公共サービスは中断されます。オンラインのままにすればサービスは継続しますが、侵害のリスクがあります。どちらの結果なら許容できるかを、サービスごとにあらかじめ決めておいてください。

今日できる最善の手は、準備です

• PHPを実行しているすべての本番システムを一覧にしてください。IT部門以外のチームが所有するサイトも含めます。それぞれを、マネージドかセルフマネージドかでタグ付けし（修正方法も所有者も異なります）、リストは記憶に頼らず、スキャンとクラウドテレメトリから作成してください。
• 各システムのPHPバージョンを確認してください。PHP 8.1以前にはセキュリティ修正が提供されなくなっています。アップストリームの番号ではなく、ディストリビューションのアドバイザリを追ってください（当社の場合はUbuntuのUSN-8948-1）。
• 各システムを、それが支える公共サービスに紐付けてください。
• それらのサービスの背後にある、ホスティングプロバイダー、MSP、共有技術を特定してください。
• システムをミッションへの影響度で階層分けし、そのうえで上記の6つの影響カテゴリを適用してください。
• 各システムに、担当者とパッチ適用の時間枠を割り当ててください。
• WAFプロバイダーがルールを展開済みか確認し、それを一時的な対策として扱ってください。そのうえで、ルールが実際にリクエストの経路上にあることを確認してください。オリジンに直接到達できるなら、エッジのルールは何も守りません。
• ログを調べ、過去の攻撃の兆候がないか確認してください。たとえば、メモリ上限エラー、繰り返し発生するサーバーエラー、原因不明のPHPワーカーの再起動などです。見つかった場合は、プロセスメモリが漏えいした可能性があるとみなし、露出した秘密情報をローテーションしてください。
• リリース後にPHPの公式通知を再確認してください。影響を受けるバージョンや識別子が変更される可能性があります。

ホスティングプロバイダーやベンダーに尋ねるべきこと

エクスポージャーは、サービスの背後にいるプロバイダーにも及びます。本日中に主要なパートナーへ連絡し、次の点を尋ねてください。

• 当社のサービスを支える、または当社のデータを扱うシステムで、PHPを実行していますか？
• どのバージョンのPHPを実行していますか？
• いつパッチを適用する予定ですか？
• パッチ適用までの間、それらのシステムを守るために、どのような代替的な対策（WAFルールなど）を講じていますか？
• 当社のサービスは、他の顧客とインフラを共有していますか？

プロバイダー全体で共有されているエクスポージャーを確認する方法

SecurityScorecardのスキャン機能は、テレメトリを用いて、露出したインフラを検出し、露出したPHPを実行しているベンダーを特定できます。Driftnetアドオンを利用しているTITAN Secureのお客様は、php2shell対応ワークフローを作成できます。詳細はウォークスルー動画をご覧ください。

STRIKEチームが観測した600万件のエクスポージャーの詳細は、技術ブログをご覧ください。