最近公開されたLog4jの脆弱性（CVE-2021-44228）は、過去10年間に組織が対処しなければならなかった最も広範なセキュリティ脆弱性の1つです。Log4j は、あらゆる規模の組織に展開されているアプリケーションやシステムで使用されており、遍在しています。組織は、どのアプリケーションやシステムがLog4jを使用しているのかさえ明らかでないため、露出の範囲と影響を評価するのに苦慮しています。ソフトウェア・ベンダーは、自社のソフトウェアが Log4j を使用しているかどうかを積極的に判断し、その影響を顧客に伝えています。組織は、セキュリティ・パッチが利用可能かどうかを積極的に監視し、できるだけ早く適用する必要があります。また、パッチが適用できない、あるいは未知の脆弱なシステムの悪用可能性や影響を減らすために、緩和策を適用する必要があります。残念ながら、このシナリオでは動きの速い攻撃者が有利であり、多くの攻撃者がすでに脆弱なターゲット・ネットワークへの足場を得るための大規模な取り組みを行っています。

脆弱性の公開を受けて、暗号通貨マイニングに関与する金銭目的の攻撃グループが、いち早く大規模な攻撃を展開しました。今後、金銭目的の攻撃者が運用においてこの脆弱性をますます活用し、さまざまなマネタイズ活動につながると考えられます。これには、データ窃盗、ランサムウェアの展開、および多面的恐喝が含まれます。というのは、これらの攻撃者は、ゼロデイおよびワンデイのエクスプロイトを迅速にオペレーションに組み込むことが知られているからです。

このブログ記事の公開日現在、中国とイランの国家を背景とした攻撃者によるエクスプロイトが確認されています。Microsoftは、他の国に拠点を置く攻撃グループによるエクスプロイトを観測しています。他の国の攻撃グループも、まもなく悪用を開始するか、あるいはそのための準備をしていると考えられます。場合によっては、国家支援型の攻撃グループは、この脆弱性が明るみに出る前から準備していた標的対象リストに基づいて攻撃を行います。

このブログでは、この脆弱性が組織に与える影響の概要、攻撃者がこの脆弱性をどのように利用しているかについての補足説明、および脆弱性緩和のための推奨事項を提供します。

この問題は、今後数ヶ月の間に攻撃者がその足場を悪用して大規模な侵害を行い、非常に長い尾を引くと予想されます。

背景

Log4j 2は、Apache Foundationによって開発されたオープンソースのJavaログ出力ライブラリです。多くのアプリケーションで広く利用され、多くのサービスで密接にインテグレーションされています。2021年12月9日、Apache Log4j 2 ユーティリティの複数のバージョンに影響を与える重大な深刻度の未認証のリモート・コード実行の脆弱性（CVE-2021-44228 別名"Log4Shell"）が一般に公開されました。この脆弱性を悪用したPOC（Proof of Concept）ツールはすぐに利用可能となり、ライブラリを利用するアプリケーションを実行しているユーザーのコンテキスト内で、リモートでコードを実行できるようになりました。

CVE-2021-44228 の説明よりから："Apache Log4j2 2.0-beta9 から 2.12.1 と 2.13.0 から 2.15.0 の設定、ログメッセージ、パラメーターに使われている JNDI 機能は、攻撃者が制御する LDAP や他の [Java Naming and Directory Interface] JNDI 関連のエンドポイントから保護されていません。ログメッセージやログメッセージ・パラメーターを制御できる攻撃者は、メッセージの検索置換が有効な場合、LDAP サーバーから読み込んだ任意のコードを実行することができます。"

JNDIインジェクションは、特定のプロトコルを利用して、攻撃者のインフラストラクチャから悪意のあるペイロードを要求することができます 。

• Lightweight Directory Access Protocol (LDAP)
• Secure LDAP (LDAPS)
• Remote Method Invocation (RMI)
• Domain Name Service (DNS)

例として、攻撃者は脆弱性を悪用するためにJDNI挿入を構築し、それをユーザー・エージェントHTTPヘッダー内に含めることができます 。 Log4j 2の脆弱なバージョンを活用するアプリケーションまたはWebサーバーをターゲットに、悪意のあるクラス・ファイルやペイロードをダウンロードすることができます。

2021年12月14日、Log4jバージョン2.15.0が特定のデフォルト以外の設定でCVE-2021-44228の脆弱性を完全に緩和しておらず、サービス拒否攻撃を受ける可能性があることに基づき、追加のLog4j脆弱性（CVE-2021-45046）が確認されました。

CVEsと影響を受けるLog4jのバージョン

緩和

スコープの評価

特定

組織が考慮すべき最初のステップは、Log4j ライブラリを活用するアプリケーションと関連するサービス（組織が管理するテクノロジーとサードパーティが統合するテクノロジー）の範囲を特定することです。Log4j ライブラリは、環境内のサーバーやエンドポイントにローカルにインストールされるだけでなく、 多くのサードパーティ・ベンダーのアプリケーションや製品と統合されるため、この作業は非常に困難で時間のかかるプロセスである可能性があります。

Log4j の存在を確認するために活用できる可能性のあるメソッドの例を以下に示します。

• 組織で活用している製品が影響を受けるかどうか、ベンダーに確認する。
  • サードパーティ・アプリケーションが影響を受ける場合、パッチやアップデート・パスが利用可能になる時期に加えて、ベンダーの推奨する短期的な緩和策を理解すること。
• 脆弱な Log4j インスタンスを特定するための署名またはプラグインを含む内部および外部の脆弱性スキャン・ツール（例：Mandiant Attack Surface Management （別名 Intrigue), Tenable, Rapid7, Qualys, WhiteSource）を活用する。さらに、オープンソースの脆弱性ツールセットも、脆弱な Log4j インスタンスを識別するために活用できます。
  • Nuclei
  • log4j-finder
  • log4j-scan

• ソフトウェアアセットインベントリシステムをレビューし、Java仮想マシン（JVM）またはLog4jライブラリが存在するかどうかを判断する。さらに、ソフトウェアアセットインベントリシステムは、Log4jに影響を受ける製品のベンダー通知と関連するアプリケーションの存在を確認するために活用することができます。
• EDRツールを活用し、Log4jに関連するJARファイル（例：log4j-core-2.x.jar）、クラスファイル（例：JndiLookup.class）、プロセス実行イベントなどをスキャンする。
• ファイルシステムやコンテナのソフトウェア部品表（SBOM）を生成できるツール（例：syft）を活用する。

SIEMログ、エンドポイント・ログ、ネットワーク・トラフィックをレビューし、悪用の可能性があるパターンを特定し、観察されたインスタンスを特定のエンドポイントやアプリケーションに関連付け、さらに詳しくレビューします。

封じ込め

スコープが特定されたら、以下のハイレベルな封じ込めのステップに従います。

• アプリケーションやサーバーからの出入り機能を制限する。このステップでは、Java サービスが LDAP、LDAPS、RMI、または DNS（または潜在的に他の方法）を介して悪意のあるクラス・ファイルをダウンロードする能力を持つことを本質的に防ぎ、特定された脆弱性の悪用方法の影響を軽減します。
• 悪用ターゲットに利用される可能性のあるアプリケーション・インターフェイスを囲い込むかアクセスを制限することで、影響を受けるアプリケーションやサーバーの攻撃対象領域を縮小する。

注：すべてのサードパーティ製統合技術のベンダーによるパッチ適用が確認されるまでは、CVE-2021-44228の悪用リスクを軽減するための重要な初期ステップとなります。

• 特定されたアプリケーションとサービスにLog4jのバージョン2.16.0へのパッチが適用可能かどうかを判断する。
  • サードパーティの統合技術については、アプリケーション／技術ベンダーと連携し、そのプラットフォームが影響を受けるかどうか、また、セキュリティ・アップデートがいつ提供されるかを確認する。
  • セキュリティ・アップデートが利用可能になったら、アップデートのテストとインストールを行う 。 外部向け（または組織内で幅広いアクセス要件を持つ）のテクノロジーとアプリケーションを優先する。
• パッチングが実行可能なオプションでない場合、一時的な緩和手段の実施を検討する。

米国サイバーセキュリティ・インフラ・セキュリティ庁（CISA）は、Log4jの脆弱性を持つ「影響を受ける」サードパーティ・ベンダーと「影響を受けない」サードパーティ・ベンダーのリストを収集しました。このリストは、GitHubで見ることができます。

パッチ

2021年12月10日、ApacheはLog4j 2バージョン2.15.0内でCVE-2021-44228の脆弱性が解決されたことを報告しました。 2.15.0 のアップデートでは、メッセージルックアップ置換 (log4j2.formatMsgNoLookups) 機能が基本的に無効になっていますが、JNDI はデフォルトで有効になっています (localhost への LDAP ルックアップを許可) 。

2021年12月13日現在、ApacheはLog4j 2バージョン2.15.0が特定のデフォルト以外の設定でCVE-2021-44228の脆弱性を完全に緩和しておらず、サービス拒否攻撃（CVE-2021-45046）を引き起こす可能性があることを踏まえ、Log4j 2バージョン2.16.0をリリースしています。

注：Log4j >= 2.15.0 にアップデートするには、Java 8 (またはそれ以上) の環境が必要です。Java 7 がまだ必要な場合は、Log4j 2.12.2 が利用可能になったときにアップグレードを完了する必要があります。

注：Log4j1.x から Log4j2 にアップグレードする場合、Log4j 2 の API は Log4j 1.x と互換性がありません。

アウトバウンド・トラフィック規制

トラフィックの緩和

Log4j インスタンスの影響を受けたバージョンを実行しているアプリケーションまたは Web アプリケーション・ サーバーでは、サーバーが公然と通信し、外部のサイトやアドレスから任意の悪意あるファイルをロードしようとしないように、出口規制が実施される必要があります。「デフォルトで拒否」のコンセプトは、許可リストと承認された退出トラフィック・フローのみを明示的に定義し、強制することで、サーバーに適用する必要があります。

送信トラフィックの制限は、LDAP、LDAPs、RMI、または DNS プロトコルだけでなく、サーバーからの外部ポート/プロトコルを含むトラフィックに限定すべきです（特定のポートが、第1段階として、 エクスプロイト・リクエスト内で指定されたり、第２段階として コールバックのコマンドおよびコントロールに利用されたりする可能性があるからです）。

注：「デフォルトで拒否」による退出トラフィックの制限は、Log4jインスタンスの影響を受けるバージョンを実行しているサーバーだけでなく、あらゆるサーバーで従うべきベストプラクティスです。

DNSクエリ

また、脆弱な Log4j インスタンスが外部の DNS クエリ（ルックアップ）を実行すると、情報漏えいの可能性があるため、影響を受けるアプリケーションやWebアプリケーションサーバからの DNS クエリも監視する必要があります。

DNSは、影響を受けるサーバー上で任意のコードをリモートで実行する方法を提供しないかもしれませんが、攻撃者の名称空間を単純に解決することで、コンテキスト情報の取得、（環境変数内に格納された）認証情報の取得、またはDNSを通じたデータのトンネル（他のセキュリティ・コントロールと出口制限の回避）を利用することができる可能性があります。

このような偵察や漏えいから保護することは非常に困難です。基本的に、影響を受けるサーバーは、DNS再帰が許されない（内部または信頼できる完全修飾ドメイン名（FQDN）とホストのみが解決できる）という制限を実施する必要があるためです。多くのエンドポイント（一部のサーバーを含む）が外部FQDNを解決する能力を必要とすることを考慮すると、このレベルのハードニングを大規模に実施することは非常に困難で非現実的である可能性があります。

この情報抽出方法を軽減するために、DNS再帰を許可しない（そして内部/信頼できるFQDNの名前解決のみを許可する）内部の名称解決専用の内部DNSサーバーを参照するように、サーバーを構成することが考慮されます。

推奨される一時的な緩和策

Log4j 2 をバージョン 2.16.0 にアップグレードすることが実行可能な選択肢ではない場合、2021 年 12 月 14 日現在、Apache は CVE-2021-44228 と CVE-2021-45046 に対する特定の短期的な緩和策のみを推奨しています（ただしバージョン 2.16.0 へのアップデートが推奨されています）。

Log4J 2 Versions < 2.16.0

Apacheの投稿に従って、log4j-core jarファイルからJndiLookupクラスを削除してください。

注：システムプロパティ (log4j2.formatMsgNoLookups) または環境変数 (LOG4J_FORMAT_MSG_NO_LOOKUPS または -Dlog4j2.formatMsgNoLookups) を true に構成する、またはメッセージ・ルックアップを無効にするロギング設定を変更するなど従来の緩和策は、まだメッセージ・ルックアップが発生するかもしれない Log4j のコードパスがあるため不十分だと判明したことから、現在は推奨されていません。

Log4J Version 1.2

CVE-2021-4104 により、組織は Log4j バージョン 2.16.0 (またはそれ以上) にアップグレードする必要があり、以前のバージョンから多数の他の問題が解決されています。Log4j 1.xは（2015年現在）製造中止しており、追加のセキュリティ脆弱性を含んでいます。

RedHat のガイダンスによると、Log4 2.x の最新バージョンへのアップグレードが不可能な場合、クラス・パスから JMSAppender クラス・ファイルを削除することでこれらの脆弱性を緩和することが可能です。

インバウンドURLリクエストのログ取得とフィルタリング

多くのWebアプリケーション・ファイアウォールやSIEMベンダーは、Log4jの悪用行為の検知を支援する特定の署名をプラットフォーム内に統合しています。 残念ながら、脆弱なLog4jインスタンスを悪用する際に、攻撃者が活用する多くの回避戦術も存在します。

Webアプリケーション・ファイアウォール、リバース・プロキシ・サーバー、侵入防止システムが、受信するWebトラフィックのURLや文字列を検査するように配置されている場合、特定のパターンがスキャンや悪用を示すことがあり、デバイスがインラインに配置されていれば、ブロックされる可能性があるのです。

注: 多数の進化した回避戦術が観察されているため、これは CVE-2021-46288 の活動に関連する検出可能な文字列の包括的なリストとは見なされませんが、検知のために活用できるさまざまなパターンを反映したものとなっています。

戦術的修復

漏えいした Log4j インスタンスが特定された場合、フォレンジック調査だけでなく、潜在的に悪意のあるアーティファクト（コイン・マイナー）やバックドア（ウェブ・シェル）の修復（除去）を行う必要があります。

さらに、LDAPやDNSのコールバックを使って、サーバーに保存されている環境変数を取得しようとする手法もあります。

認証情報やキーを含む環境変数は、攻撃者が追加のインフラストラクチャ（オンプレミスまたはクラウドベース）へのアクセスを取得するために利用することができます。もし、漏洩した Log4j インスタンスが環境変数に保存されているサーバーで実行されている場合、重要な改善策は、漏えいまたはアクセスされた可能性のあるパスワードやキーをローテーションして変更することです。

アマゾン ウェブ サービス（AWS）で設定可能な環境変数の例を紹介しています。

結論

Mandiantは、この脆弱性に関連する最新情報および関連する緩和策を引き続き提供していく予定です。追加情報およびコンテキストは、Mandiant Advantage Threat Intelligence の無料サブスクリプションに登録することでアクセスいただけます。