主要５カ国がLog4Shell対策のための共同アドバイザリを発表

米国、英国、オーストラリア、カナダ、ニュージーランドの政府機関は、広く悪用されているApache Log4jソフトウェアライブラリに存在するLog4Shellなどの深刻な脆弱性の影響を受けている人々に向けて、共同でサイバーセキュリティアドバイザリを発行しました。

Mitigating Log4Shell and Other Log4j-Related Vulnerabilities | CISA

この脆弱性は攻撃者が脆弱なシステム上でコードをリモートで実行することを可能にするもので、国家レベルの組織やランサムウェアのグループがすでに利用しているとのことです。

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）のジェン・イースタリー長官は、今回のLog4jの脆弱性について自身の経歴の中でも「最も深刻なもの」と表現し、リスクのグローバルな性質を強調しています。

CISAは、省庁間、民間企業、国際的なパートナーと協力して、Log4jの脆弱性に関連する深刻なリスクを理解し、すべての組織が適切な緩和策を速やかに実施できるよう、実行可能な情報を提供しています

今回の勧告は、CISAとそのJCDC（Joint Cyber Defense Collaborative）が以前に発表したアドバイスを発展させたもので、従来のITやクラウドベンダーベースのネットワークに加えて、運用システムや産業用制御システムの安全性確保に焦点を当てています。

勧告の内容は以下の通りです。

Table of contents

1.環境内の脆弱な資産を特定する
1. A.Log4jのJavaライブラリを使用しているすべての資産を確認
2. B.インベントリに登録されている資産のうち、脆弱性があると思われるものを特定する。
2. 環境内の既知および疑わしい脆弱性資産のリスクを軽減する
3.ハントおよびインシデント対応を開始する。
1. A. 搾取と侵害の兆候を探す
2. B. 侵害が検出された場合、組織は次のことを行う必要があります。
4.その他の緩和策を評価して適用する。

1.環境内の脆弱な資産を特定する

Log4jやその他の影響を受ける製品が自社の環境のどこに存在するかを知ることは、ネットワークを保護する上で重要です。

A.Log4jのJavaライブラリを使用しているすべての資産を確認

公開されている報告書によると、攻撃者は侵害した資産にパッチを当て他の攻撃者に侵害されないようにし、資産のコントロールを維持しています。

このような防御回避を見逃さないために、組織は調査中の資産を注意深く追跡する必要があります。

JavaとLog4jのすべてのバージョンに脆弱性があると仮定し、それらをインベントリに含める
インベントリには、機能、オペレーティングシステム、メーカーに関係なく、クラウド資産を含むすべての資産が含まれていることを確認してください。
インベントリには、各資産に関する以下の情報が含まれていることを確認してください。
- ソフトウェアのバージョン
- 最終更新日と更新者のタイムスタンプ
- 資産のユーザーアカウントとその特権レベル
- 企業トポロジーにおける資産の場所

B.インベントリに登録されている資産のうち、脆弱性があると思われるものを特定する。

CISAのGitHubリポジトリとCERT/CCのCVE-2021-44228_scannerを使用して、Log4Shellの脆弱性がある資産を特定

Log4jの脆弱なインスタンスを検出するための追加リソースを以下に示します。CISA、FBI、NSA、ACSC、CCCS、CERT NZ、NZ NCSC、NCSC-UKは、検知ルールのソースを入手次第、更新していきます。

注：本情報の共有を緊急に行うため、CISA、FBI、NSA、ACSC、CCCS、CERT NZ、NZ NCSC、およびNCSC-UKは本内容をまだ検証していません。

Log4ShellおよびCVE-2021-45046の影響を受ける可能性のあるサーバアプリケーションを特定するには、TrendMicroを参照してください。Log4J Vulnerability Tester
Javaアプリケーションが脆弱なバージョンのLog4jを実行しているかどうかを判断するのに役立つハッシュのリストについては、以下を参照してください。
Rob Fuller氏のGitHubページ。CVE-2021-44228-Log4Shell-Hashes
The NCC GroupのGitHubページ。Cyber-Defence/Intelligence/CVE-2021-44228/を参照してください。
脆弱なインスタンスを検出するためのPowerShellについては、以下を参照してください。
Nathan Kula氏のGitHubページ。PowerShellSnippets/Invoke-Log4ShellScan.ps1
Will Dormann氏のGitHubページ：checkjndi.ps1
Canary Tokenを使用してコールバックをテストする方法については、Twitter thread on using Canary Tokensを参照してください。
Burpsuite Proを使用してスキャンする方法については、以下を参照してください。
Silent Signal社のGitHubページ：burp-log4shell
PortSwigger社のGitHubページ：active-scan-plus-plus
NetMapのNmap Scripting Engine（NSE）の使い方については、DivertorのGitHubページ：nse-log4shellを参照してください。
Florian Roth氏のGitHubページ「Fenrir 0.9.0 – Log4Shell Release」には、Roth氏のFenrirツールを使って脆弱なインスタンスを検出するためのガイダンスが記載されています。

2. 環境内の既知および疑わしい脆弱性資産のリスクを軽減する

A.既知および疑わしい脆弱性のある資産を危険なものとして扱うこと。

疑わしい資産は、緩和されて検証されるまで隔離されるべきです。

使用すべき隔離方法は、資産の重要性によって異なります。可能な隔離方法は以下の通りです。

資産をネットワークから物理的に取り除く（例：ネットワーク・ケーブルを抜く）
監視とセキュリティを強化した “jail VLAN “に資産を移動する。
ネットワーク層でのブロック（スイッチなど）。
ファイアウォール(Webアプリケーションファイアウォールを含む)を導入し、厳格なポート制御とロギングを行う。
アセットの通信（特にインターネットや他の企業ネットワークへの通信）の制限

B.Log4jおよびその他の影響を受ける製品を最新バージョンにパッチする。

Apache Log4j Security Vulnerabilities webpageを参照してください（2021年12月22日現在、Log4jの最新バージョンは、Java 8では2.17.0、Java 7では2.12.3）。注：Javaへのパッチ適用やアップデートだけでは不十分で、Log4jライブラリ自体をアップグレードする必要があります。
その他の影響を受ける製品については、CISAのGitHub pageを参照してください。

注：組織が直ちにLog4jの脆弱なインスタンスを特定してパッチを当てることができない場合は、適切な回避策を適用してください。

CISA、FBI、NSA、ACSC、CCCS、CERT NZ、NZ NCSC、NCSC-UKは、ベンダーが提供する緩和策が利用可能な場合はその利用を推奨しています。

状況が急速に変化しているため、これらの回避策を恒久的なものと考えるべきではなく、適切なパッチが利用可能になり次第、それを適用する必要があります。追加の緩和策を以下に示します。

ただし、これらの緩和策は、不完全であったり、一時的であったり、アプリケーションの不安定性、DoS状態、ログの回避などの有害な効果を引き起こす可能性があるため、組織は自らの責任においてこれらの緩和策を使用する必要があります。

Jndilookup.classをクラスパスから削除します [1]
Jndilookup.classを削除するか、名前を変更してください。注意：JndiManagerを削除すると、JndiContextSelectorとJMSAppenderが機能しなくなります）。[2]
ホットパッチを適用します。
- NCC グループ: log4j-jndi-be-gone: CVE-2021-44228 に対する簡単な緩和策です。
- アマゾンAWS
  - GitHubページ：hotpatch-for-apache-log4j2
  - ブログ Hotpatch for Apache Log4j

C. 既知および疑わしい脆弱性のある資産のインベントリーを作成し、このプロセスを通じてそれらの資産に対して何が行われたかを記録する。

悪意のあるグループがネットワーク侵害した後、業務を保護するためにパッチを当てる可能性があるため、パッチの適用状況を追跡することは重要です。攻撃者が資産にパッチを適用した可能性があるかどうかを特定するために、パッチを適用した脆弱性資産を綿密に記録しておく必要があります。

D. 可能であれば、緩和策が機能したことを確認する。

手順 1.B に記載されているツールや方法を使用して、パッチを適用した/緩和した資産をスキャンします。緩和策が正常に適用されたことを確認するために、複数の方法を使用します。
資産を注意深く監視します。
資産に搭載されているソフトウェアのベンダーによる変更に常に注意を払う。また、CISAのGitHub pageでは、既知の影響を受ける製品やパッチ情報を確認できます。ベンダーからパッチがリリースされると、CISAはこのリポジトリを継続的に更新します。

3.ハントおよびインシデント対応を開始する。

この脆弱性が広く利用されていることを踏まえ、CISA、FBI、NSA、ACSC、CCCS、CERT NZ、NZ NCSC、NCSC-UKは、すべての組織に対し、Log4jを使用している資産が侵害された可能性があると想定し、ハント手順を開始することを推奨します。

A. 搾取と侵害の兆候を探す

Log4jを使用している資産を疑わしいものとして扱い、それらの資産のフォレンジック調査を精力的に行う。
Log4jを使用している資産に存在する、または接続する企業全体のアカウントを検査、監視する。
2021年12月1日以降に行われた構成の変更を検査し、特にLog4jを使用している資産上で、それらが意図されたものであることを確認する。
CISAのGitHub pageを使用して、悪用や侵害の可能性を検出する。

悪用や漏洩の可能性を検出するための追加リソースを以下に示します。CISA、FBI、NSA、ACSC、CCCS、CERT NZ、NZ NCSC、NCSC-UKは、この情報を緊急に共有するため、この内容をまだ検証していません。

Cisco Talosのブログ。Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild
Curated Intelligence社のGitHubページ。Log4Shell-IOCs (注: Curated Intelligenceは、「これらのフィードで共有されるIOCは信頼性が低いものから中程度のものであり、ブロックリストに追加しないことを強く推奨します」と述べています)
CVE-2021-44228 activityアクティビティの検出を支援するシグネチャ
Florian Roth氏のGitHubページ。
- Log4j RCE Exploitation Detection (Log4j RCEエクスプロイト検出)
- signature-base/yara/expl_log4j_cve_2021_44228.yar
- log4shell-detector
Huntressのブログです。重大なRCE脆弱性：log4j – CVE-2021-44228
Mandiantのブログ。シリアライズするのか、しないのか – Systematically Hunting for Deserialization Exploits
Microsoft AzureのGitHubページ。Azure-Sentinel/Detections/MultipleDataSources/Log4J_IPIOC_Dec112021.yaml
NCCグループです。Log4Shell: Reconnaissance and post exploitation network detection
シグマのGitHubページ。
- sigma/rules/web/web_cve_2021_44228_log4j.yml
- sigma/rules/web/web_cve_2021_44228_log4j_fields.yml

B. 侵害が検出された場合、組織は次のことを行う必要があります。

インシデント対応手順を開始する。ネットワークのハンティングや調査に関するガイダンスや、インシデント対応におけるよくある間違いについては、ACSC、CCCS、NZ NCSC、CERT NZ、NCSC-UK、CISAによる共同勧告「Technical Approaches to Uncovering and Remediating Malicious Activity」を参照してください。CISA、FBI、NSA、ACSC、CCCS、CERT NZ、NZ NCSC、NCSC-UKは、CISAの「Federal Government Cybersecurity Incident and Vulnerability Response Playbooks」を組織に推奨しています。これらのプレイブックは、米国のFCEB機関に合わせて作成されていますが、サイバーセキュリティ・インシデントおよび脆弱性対応活動を計画・実施するための運用手順が記載されており、インシデントおよび脆弱性対応の各ステップについて詳しく説明されています。
侵害行為を直ちにサイバーセキュリティ当局に報告することを検討する。インフラの悪用に使用されたIPアドレス／ドメイン、悪用されたアプリケーション／サーバ、管理者の連絡先、攻撃の開始日と終了日などの情報を含め、可能な限り詳細に報告することが推奨されます。
米国の組織は、CISAおよびFBIに侵害行為を報告する必要があります。
オーストラリアの組織は、cyber.gov.auにアクセスするか、1300 292 371（1300 CYBER 1）に電話して、サイバーセキュリティのインシデントを報告することができます。
カナダの組織は、CCCS（contact@cyber.gc.ca）に電子メールでインシデントを報告することができます。
ニュージーランドの組織は、NCSC.govt.nzにアクセスしてインシデントを報告できます。
英国の組織は、重大なサイバー・セキュリティ・インシデントをncsc.gov.uk/report-an-incident（24時間監視）で報告するか、緊急の支援が必要な場合は03000 200 973に電話してください。

4.その他の緩和策を評価して適用する。

A. 資産に搭載されているソフトウェアのベンダーによる変更に常に注意を払い、ベンダーから自社製品にこの脆弱性に対するパッチがあることが通知された場合、直ちに資産にアップデートを適用する。また、CISAのGitHubリポジトリには、既知の影響を受ける製品とパッチ情報が掲載されています。CISAは、ベンダーがパッチをリリースすると、このリポジトリを継続的に更新します。

B. 引き続きLog4Jの資産を注意深く監視する。悪用を示す可能性のあるシグネチャや侵害の指標を継続的に使用する。

ステップ3.A.(4)に記載されている悪用と検知のリソースを参照する。
悪用文字列を難読化する方法は数多く存在することに留意すること。一つの検知方法に常に依存しないこと。

C. Apache Log4j Security Vulnerabilitiesを継続して監視し、新しいアップデートを確認する。注：これは進化している状況であり、Log4Jの新しい脆弱性が発見されているため、企業はApache Log4jが最新であることを確認する必要があります。企業が使用しているソフトウェアを特定し、他の更新プログラムや修正プログラムに取って代わられる可能性があるため、更新プログラムを常に把握するようにしてください。

D. 特定のアウトバウンドTCP（Transmission Control Protocol）およびUDP（User Datagram Protocol）ネットワークトラフィックをブロックする。

アウトバウンドLDAP：ほとんどのネットワークでは、LDAPは内部で使用されていますが、LDAPリクエストがネットワーク外にルーティングされることはまれです。組織は、アウトバウンドLDAPをブロックするか、または既知の良好な目的地へのアウトバウンドLDAPに許可リストを使用する必要があります。注：これは、アプリケーション層のフィルタリングを行うファイアウォールがないと、特定のポートで検出するのは難しいかもしれません。
リモート・メソッド・インヴォケーション（RMI）：ほとんどのネットワークでは、RMIは使用されていないか、内部ソースに使用されています。組織は、アウトバウンドRMIをブロックするか、または既知の良い宛先へのアウトバウンドRMIに許可リストを使用する必要があります。
アウトバウンドDNS：エンタープライズDNSリゾルバを使用している組織は、識別されたDNSリゾルバ以外のソースからのアウトバウンドDNSをブロックすることができます。少なくとも、エンタープライズDNS解決機能を使用するように設定されたWebアプリケーションサーバーからの直接のアウトバウンドDNSをブロックすることで、それらのシステムのリスクを軽減することができます。

注：このイベント中に攻撃者のインターネットIPアドレスをブロックすることは、悪意のない研究者やベンダーからのスキャンが大量に行われるため困難です。IPアドレスの誤検知が多くなります。組織は、スキャンではなく、悪用が成功した兆候を探すことに集中すべきです。

またCISAは連邦政府機関に対し、Log4jの脆弱性に対処するよう「緊急指令」を出し、国土安全保障省がバグバウンティプログラムを拡大し、関連する問題の報告を含めることを発表しました。