1. HOME
  2. ブログ
  3. 2024年6月版　最速！危険度の高い脆弱性をいち早く解説「脆弱性研究所」第23回

2024年6月版　最速！危険度の高い脆弱性をいち早く解説「脆弱性研究所」第23回

6月に公開された重大な脆弱性（CISA KEV参照）

6月に新たに公開された脆弱性は3242となります。この中で特に重大な脆弱性をいくつかピックアップして説明したいと思います。

第三回で説明したCISAによる「実際に悪用されている脆弱性(Known Exploited Vulnerabilities Catalog)」のデータベース情報もあわせて載せています。

6月にCISAのKEVに登録された脆弱性はトータル8件で、その内訳は

  • Android Pixel: 1件
  • Arm: 1件
  • GeoSolutionsGroup: 1件
  • Linux Kernel: 1件
  • Microsoft: 1件
  • Oracle: 1件
  • PHP: 1件
  • Progress: 1件
  • Roundcube: 1件

になっています。

参考情報

  1. CISA「Known Exploited Vulnerabilities Catalog」

1.  メモリセーフなプログラムと主要なOSSの状態に関するCISAの調査結果報告

2024年6月26日に、CISA/FBI/Australian Cyber Security Centre（ACSC:オーストラリアサイバーセキュリティーセンター）/Canadian Cyber Security Center（CCSC: カナダサイバーセキュリティーセンター）が共同で、重要なオープンソースプロジェクトのプログラムがメモリセーフな状態なのかという調査結果を発表しています。面白い調査ですので、ここで取り上げてみます。

1-1. Secure-by-Design/Secure-by-Defaultへの戦略の切り替え

CISAは2023年4月13日に、NSA/FBI/ACSC/NCSC-UK/CCCS/BSI/NCSC-NL/CERT NZ/NCSC-NZと共同で、「Secure-by-Design(セキュア・バイ・デザイン)とSecure‐by‐Default(セキュア・バイ・デフォルト)へのシフト」の戦略を発表しました。

これは、サプライチェーン・セキュリティなど、バイデン政権が進めてきた「国家サイバーセキュリティ戦略」の一環となるものです。

現在の日常生活はテクノロジーに大きく依存しているため、製品の脆弱性が攻撃に使われることで経済活動や生活・医療まで影響が広がってしまいます。CISAでは脆弱な製品が市場に投入されるのを防ぐために、メーカー側に下記２つの原則に立って、製品ライフサイクル全体に渡るセキュリティの実装を促しました。

●     Secure‐by‐Design(セキュア・バイ・デザイン)

  • 攻撃者がデバイスやデータ、接続されているインフラへ不正アクセスするのを合理的に防ぐ方法で製品が構築されるようにする
  • 重要なシステムに対する一般的なサイバー脅威を列挙してリスク評価を実行する必要がある
  • 進化するサイバー脅威の状況を考慮した保護を製品の設計に組み込む必要がある。これには多層防御なども含まれる

●     Secure‐by‐Default(セキュア・バイ・デフォルト)

  • 一般的に、組織のITスタッフは、セキュリティと運用で過重な負担を強いられており、結果としてサイバーセキュリティ体制を堅牢にするための計画と実装を行う時間が限られてしまうため、デフォルトで「安全な構成」にしておく必要がある
  • セキュア・バイ・デフォルト製品は、追加のセキュリティ設定に費用を請求しない。新車にシートベルトが装備されているように、基本の製品にセキュリティを組み込む

また、「ソフトウェア製品のセキュリティ原則」として下記の３つを策定しています。

ソフトウェア製品のセキュリティ原則

  1. セキュリティの負担を顧客だけに負わせるべきではない。メーカーは顧客が購入した製品のセキュリティについて責任を持ち、製品を進化させるべきである
  2. 徹底した透明性と説明責任を追求する。安全な製品を提供することに誇りを持ち、それにより他社との差別化を図る必要がある。これには、デフォルトで強力な認証メカニズムを採用するなど、顧客の導入から得た情報を共有することが含まれる。また、脆弱性に関する勧告とCVEレコードが完全でかつ正確であることを保証する強いコミットメントも含まる。ただし、CVEの数は健全なコード分析やテストを行なっている証拠にもなるので、マイナスの指標としてカウントしないように注意が必要
  3. これらの目標を達成する組織構造とリーダーシップを構築する。セキュリティを優先するという経営レベルのコミットメントが重要になる

Secure-by-Designの戦術（SSDFと関連）

SSDF(NIST SP800-218)は、安全なソフトウェアを開発するための中核になるもので、サプライチェーン・セキュリティとも関連している「安全なソフトウェアを開発するためのフレームワーク」になります。

Secure-by-Designのため、開発には下記の戦略が必要になると述べています。

  1. メモリセーフなプログラミング言語 (SSDF PW.6.1)
    1. ALSRやCFI・ファジングなどでは不十分なため、C#/Rust/Ruby/Java/Go/Swift など、可能な限りメモリセーフな言語を使用する
  2. セキュアなハードウェア基盤
    1. 粒度の高いメモリ保護を行えるCHERIなどのハードウェアを使用する
  3. セキュアソフトウェアコンポーネント(SSDF PW 4.1)
    1. 十分に保護されたソフトウェア・コンポーネントを入手して維持する。そのため、商用やOSS・サードパーティなどのソフトは検証済みのものを使用する
  4. Webテンプレートフレームワーク(SSDF PW.5.1)
    1. クロスサイトスクリプティングなどの Web攻撃を回避するため、入力の自動エスケープを実装する
  5. パラメータ化されたクエリ(SSDF PW 5.1)
    1. SQLインジェクションを回避するため、クエリ内のユーザー入力を制限する
  6. 静的および動的アプリケーションセキュリティテスト (SAST/DAST) (SSDF PW.7.2、PW.8.2)
    1. SAST および DAST ツールを開発プロセスに組み込み、製品のソースコードとアプリケーションの動作を分析してエラーを検出する
  7. コードレビュー (SSDF PW.7.1、PW.7.2)
    1. 他の開発者によるピアレビューを行う
  8. ソフトウェア部品表 (SBOM) (SSDF PS.3.2、PW.4.1)
    1. SBOMの作成を行い、製品に組み込まれるソフトウェアを可視化する
  9. 脆弱性開示プログラム(SSDF RV.1.3)
    1. 脆弱性が見つかった際の脆弱性開示方法を確立する
  10. CVEの完全性
    1. 公開されたCVEに根本原因や共通点が含まれるようにする
  11. 多層防御
    1. ユーザー権限を厳密に定めてアクセスを制御したり、ソフトウェアサンドボックスを利用したりするなど、さまざまな防御を行う
  12. サイバーパフォーマンス目標(CPG)を満たす
    1. 基本的なセキュリティプラクティスを満たす製品を設計する

Secure-by-Defaultの戦術

　Secure-by-Defaultのため、開発には下記の戦略が必要になると述べています。

  1. デフォルトパスワードの排除
    1. デフォルトパ スワードを排除し、製品のインストールおよび構成時に管理者が強力なパスワードを設定することを必須にする
    2. 特権ユーザーは多要素認証(MFA)を義務化する
  2. シングル サインオン (SSO)
    1. Security Assertion Markup Language (SAML) や OpenID Connect (OIDC)などを追加コストなしにデフォルトで使えるようにする
  1. 安全なログ記録
    1. 追加料金なしで、高品質の監査ログを顧客に提供
  2. ソフトウェア承認プロファイル
    1. 承認されたプロファイルの役割と、指定された使用例に関する推奨事項を提供する必要がある

  3. 後方互換性よりも将来を見据えたセキュリティ
    1. 互換性のあるレガシー機能はリスクをもたらすため、後方互換性よりもセキュリティを優先する
  4. 「セキュリティ強化ガイド」のサイズを追跡して縮小
    1. 製品に含まれる「セキュリティ強化ガイド」のサイズを縮小し、新しいバージョンがリリースされるにつれて、デフォルト構成として「強化ガイド」 のコンポーネントを統合する
  5. セキュリティ設定によるユーザーエクスペリエンスへの影響を考慮
    1. エンドユーザーの負担を増やさないようにするため、セキュリティ設定が存在せず、代わりに最も安全な設定がデフォルトで製品に統合されるようする

CISA・パートナーによるこの共同戦略は、日本のメディアでも取り上げられています。

1-2. メモリセーフのケースロードマップ

先述の「Secure-by-Design/Secure-by-Default戦略への切り替え」の後、CISAはNSA/FBI/ACSC/CCCS/NCSC‐UK/NCSC‐NZ/CERT‐NZと共同で、「メモリセーフのケースロードマップ」を出しました。

これは、先述の「Secure-by-Design」を満たす戦術としての「メモリセーフプログラミング言語（MSL）を実際に実装に使用する際に、メモリセーフロードマップを作成して、公開することを強く推奨するもので、ロードマップには下記のものを含めると良いとしています。

  1. 日付と結果が定義されたフェーズの策定
  2. 新しいシステムでMSLを使う日付の策定
  3. 社内開発者のトレーニングおよび統合計画
  4. ライブラリなど外部依存するものの計画
  5. 透明性計画（上述の計画を定期的に更新する）
  6. CVEサポートプログラム計画

また、MSLに移行するまでの緩和策のサンプルなども挙げられています。

1-3. メモリセーフなプログラムと主要なOSSの状態に関するCISAの調査報告

1-1, 1-2を踏まえて、CISAが主要なOSSの状態を調査し、報告にまとめたものが今回のものになります。

調査対象

今回はオープンソースセキュリティ財団(Open Source Security Foundation)の「Securing Critical Projects Working Group」がまとめている172の重要なプロジェクト（Critical Project）について分析しています。このCritical プロジェクトで代表的なものは以下になります。

  • chromium
  • KVM
  • Linux
  • gcc
  • Python
  • kubernetes

調査結果概要

調査結果の概要は以下の通りです。

  • Criticalプロジェクトの 52%が、メモリセーフでない言語で記述されていました
  • Criticalプロジェクトのすべてのコード行数(LoC)の55%は、メモリセーフでない言語で書かれていました
  • メモリセーフ言語で書かれたCritical プロジェクトを3つ選んで依存関係を確認したところ、メモリセーフ言語で書かれていない他のコンポーネントに依存していることがわかりました

今回の調査で、分析したほとんどのOSSのCritical プロジェクトが、たとえメモリセーフな言語で記述されたものであっても、メモリの安全性に関わる脆弱性を（外部のコンポーネントなどにより）潜在的に含んでいることが判明しました。

さらに、メモリセーフを無効にする低レベルの機能要件により、たとえメモリセーフ言語でコードを記述してあったとしても、メモリセーフに関係した脆弱性が発生する可能性があります。

調査結果の捉え方

　これらの調査結果から

  1. OSSのCriticalプロジェクトに関しては、半数以上がメモリセーフな言語で書かれてはいないため、Secure-by-DesignでOSSを使用する際には気を付けなくてはならない
  2. たとえCriticalプロジェクトでメモリセーフなプログラミング言語を使用していても、外部コンポーネントなどによりメモリの安全性に関わる脆弱性を潜在的に持っている可能性がある
  3. 結局、安全なコーディングプラクティス、セキュリティテストなどを注意深く使用していく必要がある

ということがわかります。

ここで気をつけなければならないのは、メモリセーフなプログラムが使われていないからといって、それが「悪いこと」と言っているのではない、ということです。あくまでもサプライチェーン・セキュリティなどの「国家サイバーセキュリティ戦略」を進めていく中で、戦略として打ち出した「Secure-by-Design」をソフトウェアメーカーに実現させるための「現状の調査」になります。

CISAとしては、この分析を基にして、OSSでのメモリ安全性のリスクを理解し、メモリセーフな言語で重要なコンポーネントの書き換えなどで本リスクを軽減していくことを奨励しています。今後は、この調査結果を踏まえて、「どうやってメモリセーフな言語に置き換えられるのか」「置き換えられない場合にはリスクをどうしていくのか」などの発展的な話につながることになりますので、その点はお間違いないようお願いします。

参考情報

  1. CISA and Partners Release Guidance for Exploring Memory Safety in Critical Open Source Projects 
  2. Exploring Memory Safety in Critical Open Source Projects (PDF)
  3. Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by- Design and -Default
  4. 「セキュア・バイ・デザイン」と「セキュア・バイ・デフォルト」の“戦術”とは？　全20項目を紹介
  5. CHERI
  6. OpenSSF: Identifying Critical Projects

2. Windows用のPHPにリモートコード実行の脆弱性(CVE-2024-4577) 

Windows用のPHPにリモートコード実行の脆弱性が出ています。また、セキュリティ企業・Impervaの調査によると、TellYouThePassランサムウェアがこちらの脆弱性を悪用して攻撃を行っている模様ですので注意が必要です。以下、脆弱性を簡単にまとめます。

一次情報源

CVE情報

公開されたCVEは以下になります。

  • CVE-2024-4577
    • 影響するバージョン: PHP 8.1.x < 8.1.29, 8.2.x < 8.2.20, 8.3.x < 8.3.8
    • CVSS
      • Base Score: 9.8 Critical
      • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    • Windows上でApache CGIでPHPを使用する際に、セットアップでcodeページを使用するようになっている場合は、Windowsはコマンドラインで与えられた文字列を”Best-Fit”するようにWin32-API関数で使用します。PHP CGIモジュールがこれらのPHPオプションの文字列を誤って解釈した場合、悪意のあるユーザーがPHPバイナリをサーバー上で実行させることが可能になります

TellYouThePassランサムウェア

Impervaの調査によると、すでに「TellYouThePass」ランサムウェアが、こちらの脆弱性を攻撃に悪用しているとのことです。

TellYouThePassは、2019年から観測されているランサムウェアで、Windows／Linuxの両方に対するサイバー攻撃キャンペーンを行なっており、企業や個人をターゲットとしています。Curated.intelによると、TellYouThePassランサムウェアは、いわゆる「RaaS（Ransomware As A Service）」としては動作していないとの見解がなされています。

TellYouThePassの使用する脆弱性

　TellYouThePassは、下記の脆弱性を悪用していることが観測されています。

  • CVE-2021-44228 (Apache Log4j)
  • CVE-2023-46604(Apache ActiveMQの脆弱性)
  • CVE-2024-4577

TellYouThePassの過去の攻撃

  • 2021年、中国のユーザーに対してLog4jの脆弱性を用いたTellYouThePassランサムウェアがOA製品を対象に攻撃に使用した形跡がSangfor EDRにより観測されている
  • 2021年では、中国語圏のコミュニティでは研究結果が公開されているが、英語圏のコミュニティでは特に研究結果が公開されておらず、どうやら2021年にはTellYouThePassは主に中国語圏に攻撃を加えていた模様
  • Curated.intelによると、TellYouThePass は RaaS (Ransomware-as-a-Service)として動作していないとの見解がなされている
  • 2024年のSangforによる観測では、TellYouThePassはHTMLアプリケーションを使用して配信される.NETサンプルの形をとっている

TellYouThePassの現在の攻撃（Impervaによる調査）

Impervaの調査によると、攻撃者はCVE-2024-4577を悪用して、標的のシステムで任意のPHPコードを実行し、「system」機能を使用してmshta.exeバイナリを介し、攻撃者が制御するWebサーバーのHTMLアプリケーションファイルを実行します。 mshta.exeは、リモートペイロードを実行できる一般的なWindowsコマンドです。

その後、C2サーバーからダウンロードされるバイナリがディレクトリを列挙し、プロセスを終了させたり、暗号化キーを生成したりして、列挙されたディレクトリ内の定義されたファイル拡張子を持つファイルを暗号化します。

参考情報

3. VMWare vCenterサーバーの脆弱性（CVE-2024-37079, CVE-2024-37080, CVE-2024-37081）

VMWare vCenter ServerのDCERPCプロトコル実装で、複数のヒープオーバーフロー脆弱性が見つかりました。vCenter Server へアクセスできる攻撃者によって任意のコードが実行されたり、管理者権限を持たない一般ユーザーが特権へ昇格できてしまう可能性があります。

一次情報源

CVE情報

公開されたCVEは以下になります。

  • CVE-2024-37079
    • CVSS
      • Base Score:
      • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    • VMWare vCenter ServerのDCERPCプロトコル実装で、複数のヒープオーバーフロー脆弱性が見つかりました。ネットワークアクセスできる悪意のある攻撃者は、これを悪用して特別に細工されたパケットを送ることにより、リモートコードの実行が可能になります
  • CVE-2024-37080
    • CVSS
      • Base Score:
      • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    • VMWare vCenter ServerのDCERPCプロトコル実装で、複数のヒープオーバーフロー脆弱性が見つかりました。ネットワークアクセスできる悪意のある攻撃者は、これを悪用して特別に細工されたパケットを送ることにより、リモートコード実行が可能になります。
  • CVE-2024-37081
    • CVSS
      • Base Score:
      • Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
    • VMWare vCenter Serverのsudo設定に問題があり、ローカルの一般ユーザーが特権昇格できる脆弱性が見つかりました。認証を通過したローカルの攻撃者は、これを悪用してvCenter Server Appliance上でroot権限を奪取することができます。

参考情報

6月のまとめ

6月ですが、他にもMOVEitのCriticalな脆弱性（Critical: CVE-2024-5806）や、ASUSのルータの脆弱性（CVE-2024-3079,  CVE-2024-3080）、FortiOSの脆弱性（CVE-2024-23110）などが出ています。皆様も使用ベンダーからの情報に気をつけて、きちんと更新を行うようにしてください。

＜著者＞　面 和毅
サイオステクノロジー株式会社 上席執行役員
OSS/セキュリティエバンジェリスト

OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。
2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍中。また、ヒートウェーブ株式会社でも講師として活動中。
専門分野はSELinuxを含むOSのアクセス制御、AntiVirus、SIEM、脅威インテリジェンス。

「脆弱性研究所」の最新話は、メールマガジンにてもご案内致しています。是非JAPANSecuritySummit Updateのメールマガジンにご登録ください。
メールマガジンの登録はこちらからお願いします

最速！　危険度の高い脆弱性をいち早く解説「脆弱性研究所」の過去の記事はこちらから

関連記事

サイバーセキュリティの課題をテーマ別に紹介中！！