更新 (12 月 30 日): この投稿は、新しい CVE ( CVE-2021-44832 ) と関連するパッチを反映するように更新されました。
更新 (12 月 28 日): この投稿は、レガシー Java 7 ( 2.12.3 ) および Java 6 クライアント ( 2.3.1 ) の新しいパッチを反映するように更新されました。
更新 (12 月 20 日): この投稿は、新しい CVE ( CVE-2021-45105 ) と関連するパッチ ( Java 8 クライアント用のLog4j 2.17.0 ) を反映するように更新されました。
更新 (12 月 17 日): この投稿は、 CISA の緊急指令 22-02を参照するために更新されました。
更新 (12 月 16 日): この投稿は、Apache の Log4j バージョン 2.12.2 (Java 7 クライアント) のリリースを参照するように更新されました。
最近公開された Log4j の脆弱性 (CVE-2021-44228) は、組織が過去 10 年間で対処しなければならなかった最も広範囲に及ぶセキュリティ脆弱性の 1 つです。 Log4j はユビキタスであり、あらゆる規模の組織に展開されたアプリケーションとシステムで使用されています。どのアプリケーションやシステムが Log4j を使用しているのかさえ明らかではないため、組織は暴露の範囲と影響を評価するのに苦労しています。ソフトウェア ベンダーは、自社のソフトウェアが Log4j を使用しているかどうかを積極的に判断し、その影響を顧客に伝えています。組織は、セキュリティ パッチの可用性を積極的に監視し、できるだけ早く適用する必要があります。パッチを適用できない、またはまだ認識していない脆弱なシステムの悪用可能性と影響を軽減するために、軽減策を展開する必要があります。残念ながら、このシナリオでは動きの速い攻撃者が有利であり、多くの攻撃者はすでに脆弱な標的ネットワークに足場を築くために大規模な取り組みを行っています。
脆弱性が公開された後、仮想通貨のマイニングに関与する金銭目的の攻撃者が、ターゲットを一斉に悪用した最初の攻撃者の 1 人でした。追加の金銭目的の攻撃者が運用上の脆弱性をますます悪用し、さまざまな収益化活動につながると予想されます。これには、データの盗難、ランサムウェアの展開、および多面的な恐喝が含まれます。これらのアクターは、ゼロデイおよびワンデイ エクスプロイトを迅速に運用に組み込むことが知られているためです。
この脆弱性に関連する脆弱なアプリケーションとシステムを特定してパッチを適用することが緊急に求められているため、2021 年 12 月 17 日、Cybersecurity and Infrastructure Security Agency (CISA)は 緊急指令 22-02 を制定しました。アセットを 2021 年 12 月 23 日までに削除するか、代理店ネットワークから削除してください。
このブログ投稿の公開日の時点で、中国とイランの国家アクターによる搾取の証拠が明らかになりました。 Microsoft は、他の国に拠点を置く攻撃者による悪用を確認しています。まだ行っていない場合は、他の国の脅威アクターがすぐにそれを悪用することが予想されます。場合によっては、国家が支援する攻撃者が、この脆弱性が知られるずっと前から存在していた優先順位の高い標的のリストを利用して攻撃を仕掛けます。他のケースでは、彼らは広範な搾取を行い、その後、任務に応じて標的のさらなる搾取後の活動を行う可能性があります。
このブログ投稿では、この脆弱性が組織に与える影響の概要を説明し、攻撃者が実際にこの脆弱性をどのように利用したかについての追加のコンテキストを共有し、緩和の推奨事項を提供します。
敵対者が足場を悪用して今後数か月で主要な侵害を実行するため、この問題は非常に長く続くと予想されます。
バックグラウンド
Log4j 2は、Apache Foundation によって開発されたオープン ソースの Java ロギング ライブラリです。多くのアプリケーションで広く使用されており、依存関係として多くのサービスに統合されています。 2021 年 12 月 9 日、Apache Log4j 2 ユーティリティの複数のバージョンに影響を与える重大な重大度の認証されていないリモート コード実行の脆弱性 ( CVE-2021-44228別名「Log4Shell」 ) が公開されました。概念実証 (POC) エクスプロイト ツールがすぐに利用可能になり、ライブラリを利用するアプリケーションを実行しているユーザーのコンテキスト内でリモート コード実行機能が提供されました。
CVE-2021-44228 の説明から: 「構成、ログ メッセージ、およびパラメーターで使用される Apache Log4j2 2.0-beta9 から 2.12.1 および 2.13.0 から 2.15.0 の JNDI 機能は、攻撃者が制御する LDAP およびその他の [Javaネーミングとディレクトリ インターフェイス] JNDI 関連のエンドポイント。ログ メッセージまたはログ メッセージ パラメータを制御できる攻撃者は、メッセージ ルックアップ置換が有効になっている場合、LDAP サーバーからロードされた任意のコードを実行できます。」
JNDI インジェクションは、特定のプロトコルを利用して、攻撃者のインフラストラクチャから悪意のあるペイロードを要求できます。
- ライトウェイト ディレクトリ アクセス プロトコル (LDAP)
- セキュア LDAP (LDAPS)
- リモート メソッド呼び出し (RMI)
- ドメインネームサービス (DNS)
たとえば、脆弱性を悪用するために、攻撃者は JDNI 挿入を作成し、それを User-Agent HTTP ヘッダー内に含める可能性があります。これは、Log4j 2 の脆弱なバージョンを利用して悪意のあるクラス ファイルまたはペイロードをダウンロードするアプリケーションまたは Web サーバーを標的にします。
|
2021 年 12 月 14 日、追加の Log4j 脆弱性が特定されました ( CVE-2021-45046 )。これは、Log4j バージョン 2.15.0 が特定のデフォルト以外の構成で CVE-2021-44228 の脆弱性を完全に緩和しなかったという事実に基づいており、結果として、リモートコード実行またはサービス拒否攻撃のいずれかで。これは、Java 8 クライアントの Log4j バージョン2.16.0で緩和されました。
2021 年 12 月 18 日に、バージョン 2.0-alpha1 から 2.16.0 に影響を与える別の Log4j サービス拒否状態 ( CVE-2021-45105 ) が特定されました。これは、Java 7 クライアントの場合は Log4j バージョン2.12.3 、Java 8 クライアントの場合はバージョン2.17.0で緩和されました。
2021 年 12 月 22 日、Apacheはレガシー Java 6 クライアント用のLog4j バージョン2.3.1をリリースしました。
2021 年 12 月 28 日に、Apache は Log4j バージョン2.3.2 (Java 6 クライアント)、 2.12.4 (Java 7 クライアント)、および2.17.1 (Java 8 クライアント) をリリースしました。これはCVE-2021-44832 の軽減策を提供します。リモート コード実行攻撃として分類されていますが、この脆弱性は実際には、攻撃者がターゲット エンドポイントで事前に管理権限を確立している必要があり、その結果、 log4j.xmlファイルを変更できるようになります。このレベルのアクセスでは、攻撃者はログ ファイルを変更して、JDBC アペンダーを介して悪意のある構成を含め、攻撃者が制御する JNDI URI を参照するデータ ソースを含めることができます (リモートでコードが実行される可能性があります)。
CVE と影響を受ける Log4j バージョン
CVE |
影響を受けるバージョン |
影響 |
緩和されたバージョン |
Log4j 2.0-beta9 から 2.3 Log4j 2.4 から 2.12.1 Log4j 2.13.0 から 2.15.0 |
リモート コード実行 (RCE) |
Log4j 2.3.1 (Java 6) Log4j 2.12.2+ (Java 7) Log4j 2.16.0+ (Java 8) |
|
Log4j 2.0-beta9 から 2.3 Log4j 2.4 から 2.12.1 Log4j 2.13.0 から 2.15.0 Context Lookup でデフォルト以外の PatternLayout を具体的に使用する場合。 |
リモート コード実行 (RCE) サービス拒否 (DoS) |
Log4j 2.3.1 (Java 6) Log4j 2.12.2+ (Java 7) Log4j 2.16.0+ (Java 8) |
|
Log4j 2.0-alpha1 から 2.3 Log4j 2.4 から 2.12.1 Log4j 2.13.0 から 2.16.0 Context Lookup でデフォルト以外の PatternLayout を具体的に使用する場合。 |
サービス拒否 (DoS) | Log4j 2.3.1 (Java 6)
Log4j 2.12.3 (Java 7) Log4j 2.17.0 (Java 8) |
|
Log4j 1.2 特に JMSAppender を使用するように構成されている場合、攻撃者が Log4j 構成への書き込みアクセス権を持っている場合、Log4j 1.2 は信頼されていないデータの逆シリアル化に対して脆弱です。 これはデフォルト構成ではありません。 |
リモート コード実行 (RCE) |
Log4j 1.x はサポート終了(2015 年現在) であり、追加の重大度の高いセキュリティ脆弱性が含まれています。 Log4j 2 の現在のバージョンにアップグレードする |
|
Log4j 2.0-alpha1 から 2.3.1 Log4j 2.4 から 2.12.3 Log4j 2.13.0 から 2.17.0 攻撃者は、 log4j.xmlファイルを変更する機能を提供するターゲット エンドポイントで権限を昇格する必要があります。 また、JDBC アペンダー機能が Log4j の一部として利用されている必要があります。 |
リモート コード実行 (RCE) |
Log4j 2.3.2 (Java 6) Log4j 2.12.4 (Java 7) Log4j 2.17.1 (Java 8) |
緩和セクション
範囲を評価する
識別
組織が考慮しなければならない最初のステップは、Log4j ライブラリを活用するアプリケーションと依存サービス (組織が管理する技術とサードパーティの統合技術) の範囲を決定することです。 Log4j ライブラリは、環境内のサーバーやエンドポイントにローカルにインストールされるだけでなく、多くのサードパーティ ベンダーのアプリケーションや製品と統合される可能性があるため、これは非常に困難で時間のかかるプロセスになる可能性があります。
Log4j の存在を特定するために利用できる可能性のあるメソッドの例:
- 組織が利用している製品が影響を受けるかどうかをベンダーに確認します。
- サードパーティのアプリケーションが影響を受ける場合は、ベンダーが推奨する短期的な緩和策と、パッチまたは更新パスが利用可能になる時期を理解する必要があります。
- 脆弱な Log4j インスタンスを特定するための署名またはプラグインを含む内部および外部の脆弱性スキャン ツール (例: Mandiant Attack Surface Management (別名 Intrigue)、Tenable、Rapid7、Qualys、WhiteSource) を活用します。さらに、オープン ソースの脆弱性ツールセットを利用して、次のような脆弱な Log4j インスタンスを特定することもできます。
スキャンは、オンプレミス (外部向けおよび内部向け) のリソースだけでなく、組織によって管理されているクラウド資産およびアプリケーションにも焦点を当てる必要があります。 |
- ソフトウェア資産インベントリ システムを確認して、Java 仮想マシン (JVM) または Log4j ライブラリが存在するかどうかを判断します。さらに、ソフトウェア資産インベントリ システムを活用して、Log4j に依存する影響を受ける製品のベンダー通知に関連するアプリケーションの存在を確認できます。
- EDR ツールを活用して、JAR ファイル (例: log4j-core-2.x.jar )、クラス ファイル (例: JndiLookup.class )、または Log4j に関連付けられたプロセス実行イベントをスキャンします。
- ファイルシステムとコンテナー (例: syft ) のソフトウェア部品表 (SBOM) を生成できるツールを活用します。
SIEM ログ、エンドポイント ログ、またはネットワーク トラフィックを確認して、潜在的な悪用の試みの一致パターンを特定し、観察されたインスタンスを特定のエンドポイントまたはアプリケーションに関連付けてさらに確認します。
含む
範囲が特定されたら、次の高レベルの封じ込め手順に従う必要があります。
- アプリケーションおよびサーバーからの送信機能を制限します。この手順により、Java サービスが LDAP、LDAPS、RMI、または DNS (またはその他の方法) を介して悪意のあるクラス ファイルをダウンロードする機能を基本的に防止し、特定された脆弱性悪用方法の影響を軽減します。
- エクスプロイト ターゲットに利用できるアプリケーション インターフェイスへのアクセスをエンクレーブまたは制限することで、影響を受けるアプリケーションとサーバーの攻撃面を減らします。
注:すべてのサードパーティの統合テクノロジがベンダーによってパッチ適用されていることが確認されるまで、これらは CVE-2021-44228 の悪用のリスクを軽減するための重要な最初のステップです。
- 特定されたアプリケーションとサービスに Log4j のバージョン 2.3.1 (Java 6)、2.12.2 以降 (Java 7)、または 2.17.0 (Java 8) のパッチを適用できるかどうかを判断します。
- サードパーティの統合テクノロジについては、アプリケーション/テクノロジ ベンダーと協力して、プラットフォームが影響を受けるかどうか、およびセキュリティ更新プログラムがいつ利用可能になるかを確認してください。
- セキュリティ更新プログラムが利用可能になったら、更新プログラムをテストしてインストールし、外部向けの (または組織内で広範なアクセス要件がある) テクノロジとアプリケーションを優先します。
- パッチ適用が実行可能なオプションでない場合は、 一時的な緩和策の実装を検討してください。
Cybersecurity and Infrastructure Security Agency (CISA) は、Log4j の脆弱性に対して脆弱な「影響を受ける」および「影響を受けない」サードパーティ ベンダーのリストを収集しました。このリストはGitHubにあります。
パッチ
Log4j バージョン 2.3.1 (Java 6 クライアント)、2.12.3 (Java 7 クライアント)、および 2.17.0 (Java 8 クライアント) には、CVE-2021-44228、 CVE-2021-45046 、およびCVE-2021-45105の脆弱性軽減策が含まれています。 .これらは、Apache がインストールに推奨するアップグレードです。 |
Java 8 クライアント
2021 年 12 月 10 日、ApacheはCVE-2021-44228 の脆弱性が Log4j 2 バージョン2.15.0内で解決されたと報告しました。 2.15.0 の更新では、基本的にメッセージ ルックアップ置換 ( log4j2.formatMsgNoLookups ) 機能が無効になりましたが、JNDI はデフォルトで有効のままでした (ローカルホストへの LDAP ルックアップを許可)。
2021 年 12 月 13 日、Apache は Java 8 クライアント用の Log 4j バージョン2.16.0をリリースしました。これは、Log4j バージョン 2.15.0 がデフォルト以外の特定の構成で CVE-2021-44228 の脆弱性を完全に緩和していないという事実に基づいており、結果として次のいずれかが発生する可能性があります。リモート コード実行 (RCE) またはサービス拒否攻撃。 ( CVE-2021-45046 )。この更新により、デフォルトで JNDI 機能とメッセージ ルックアップ パターンが無効になることに注意してください。
2021 年 12 月 18 日の時点で、Apache は Java 8 クライアント用の Log4j バージョン2.17.0 をリリースしました。この更新により、サービス拒否攻撃 ( CVE-2021-45105 )を引き起こす可能性がある特定の非デフォルト構成の問題が解決されました。
Java 7 クライアント
2021 年 12 月 14 日、Apacheはレガシー Java 7 クライアント用の Log 4j バージョン2.12.2をリリースし、CVE-2021-44228 と CVE-2021-45046 の両方の軽減策に対処しました。 2021 年 12 月 22 日に、Apache は Java 7 クライアント (Log4j バージョン2.12.3 ) 用の追加の更新プログラムをリリースしました。この更新プログラムは、システム プロパティを使用して JNDI を使用するコンポーネントを個別に有効にすることを要求することで、CVE-2021-45105 に対処します。
注: Log4j >= 2.15.0 に更新するには、Java 8 (またはそれ以降) への依存関係が必要です。 Java 7 がまだ必要な場合は、Log4j 2.12.2 へのアップグレードを検討する必要があります。
注: Log4j1.x から Log4j2 にアップグレードする場合、Log4j 2 の API は Log4j 1.x と互換性がありません。
Java 6 クライアント
2021 年 12 月 22 日、Apache はレガシー Java 6 クライアント用の Log4j バージョン 2.3.1 をリリースしました。
アウトバウンド トラフィックの制限
下りトラフィック
影響を受けるバージョンの Log4j インスタンスを実行しているアプリケーション サーバーまたは Web アプリケーション サーバーについては、サーバーが公然と通信し、外部のサイトやアドレスから任意の悪意のあるファイルを読み込もうとすることができないように、エグレス制限を適用する必要があります。 「デフォルトで拒否」の概念はサーバーに適用され、許可リストに登録され、承認された送信トラフィック フローのみが明示的に定義および適用されます。
エグレス トラフィックの制限は、アウトバウンド LDAP、LDAP、RMI、または DNS プロトコルだけに限定するのではなく、サーバーからの外部ポート/プロトコルを含むトラフィックに限定する必要があります (特定のポートを最初のステージ 1 エクスプロイト リクエスト内で指定するか、コマンド アンド コントロールに利用することができるため)ステージ 2 コールバックの場合)。
注: 「デフォルトで拒否」のエグレス トラフィック制限は、影響を受けるバージョンの Log4j インスタンスを実行しているサーバーだけでなく、すべてのサーバーで従うべきベスト プラクティスです。
DNS クエリ
影響を受けるアプリケーションまたは Web アプリケーション サーバーからの DNS クエリも監視する必要があります。脆弱な Log4j インスタンスにより、外部 DNS クエリ (ルックアップ) が実行され、情報漏えいの可能性があるためです。
|
DNS は、影響を受けるサーバー上で任意のコードをリモートで実行する方法を提供しない可能性がありますが、攻撃者の名前空間の単純な解決を利用して、コンテキスト情報の取得、資格情報の取得 (環境変数内に保存)、または DNS を介したデータのトンネリング (他のセキュリティ管理および出国制限)。
この偵察と漏えいの方法から保護することは非常に困難な場合があります。基本的に、影響を受けるサーバーには、DNS 再帰が許可されない制限を適用する必要があるためです (また、内部または信頼できる完全修飾ドメイン名 (FQDN) とホストのみを解決できます)。多くのエンドポイント (一部のサーバーを含む) が外部 FQDN を解決する機能を必要とすることを考慮すると、このレベルの強化を大規模に実施することは非常に困難で非現実的です。
この情報抽出方法を軽減するための考慮事項は、DNS 再帰を許可するように構成されていない内部名前解決専用の内部 DNS サーバーを参照するようにサーバーを構成することです (内部/信頼された FQDN の名前解決のみを許可します)。
一時的に推奨される緩和策
Log4j 2 をバージョン 2.3.1 (Java 6)、2.12.2 (Java 7)、または 2.17.0 (Java 8) にアップグレードすることが実行可能なオプションではない場合、Apache は特定の短期的な緩和策を推奨しています (ただし、サポートされている最高のバージョンに更新します)。が推奨される方法です)。
CVE-2021-44228 および CVE-2021-45046
Apache の投稿に従って、 JndiLookupクラスをlog4j-core jar ファイルから削除します。
|
注:システム プロパティ ( log4j2.formatMsgNoLookups ) または環境変数(LOG4J_FORMAT_MSG_NO_LOOKUPSまたは-Dlog4j2.formatMsgNoLookups)をtrueに構成すること、またはロギング構成を変更してメッセージ ルックアップを無効にすることを含む以前の軽減策は、推奨されなくなりました。 Log4j には、メッセージ ルックアップが引き続き発生する可能性のあるコード パスが存在する可能性があります。
CVE-2021-45105
ロギング構成の PatternLayout 内で、${ctx:loginId} または $${ctx:loginId} に似たコンテキスト ルックアップをスレッド コンテキスト マップ パターン (%X、%mdc、または %MDC) に置き換えます。それ以外の場合は、設定で、${ctx:loginId} または $${ctx:loginId} に似たコンテキスト ルックアップの外部ソース アプリケーション参照を削除します。
注: Log4j バージョン 2.16.0 を実行していて、PatternLayout 構成 (デフォルト以外の構成) でコンテキスト ルックアップを使用していない環境は、CVE-2021-45105 に対して脆弱ではありません。
CVE-2021-4104 (Log4J バージョン 1.2)
CVE- 2021-4104 に従って、組織は Log4j 2 の現在のバージョンにアップグレードする必要があります。
RedHatのガイダンスによると、Log4 2.x の現在のバージョンへのアップグレードが不可能な場合、クラスパスからJMSAppenderクラス ファイルを削除することでこれらの脆弱性を軽減できます。
|
重要: 上記の一時的な軽減策では、アプリケーション サービスと Java 仮想マシン (JVM) インスタンスの再起動が必要になります。 |
CVE-2021-44832
CVE-2021-44832の一時的な緩和策は Apache によって参照されていませんが、この脆弱性に対するリモート コード実行には、JDBC Appender 機能が Log4j の一部として利用されていること、および攻撃者がターゲット エンドポイントで以前に管理権限を確立していることが必要です。 log4j.xmlファイルを変更する機能。
この特定の脆弱性を緩和するために、Apache はLog4j バージョン2.3.2 (Java 6 クライアント)、 2.12.4 (Java 7 クライアント)、または2.17.1 (Java 8 クライアント) にアップグレードすることを推奨しています。
インバウンド URL リクエストのロギングとフィルタリング
現在、多くの Web アプリケーション ファイアウォールおよび SIEM ベンダーは、Log4j エクスプロイト アクティビティの検出を支援できる特定の署名をプラットフォーム内に統合しています。残念ながら、脆弱な Log4j インスタンスを悪用する際に攻撃者が利用している回避戦術も数多くあります。
Web アプリケーション ファイアウォール、リバース プロキシ サーバー、または侵入防止システムがインバウンド Web トラフィックの URL と文字列を検査するように配置されている場合、特定のパターンはスキャン/悪用を示している可能性があり、デバイスがインラインに配置されている場合はブロックされる可能性があります。
注:多数の進化する回避戦術が観察されているため、これは CVE-2021-46288 アクティビティに関連する可能性のある検出文字列の包括的なリストとは見なされませんが、検出に利用できるさまざまなパターンを反映しています。
|
戦術的な修復
侵害された Log4j インスタンスが特定された場合は、フォレンジック調査を実施するだけでなく、潜在的に悪意のあるアーティファクト (コイン マイナー) またはバックドア (Web シェル) を修復 (削除) する必要があります。
攻撃者が利用している追加の戦術は、LDAP または DNS コールバックを使用して、サーバーに保存されている環境変数を取得しようとすることです。
|
資格情報またはキーを含む環境変数は、攻撃者が追加のインフラストラクチャ (オンプレミスまたはクラウドベース) へのアクセスを取得するために利用できます。侵害された Log4j インスタンスが認証情報が環境変数内に保存されているサーバーで実行されている場合、重要な修正手順は、公開またはアクセスされた可能性のあるパスワード/キーをローテーションして変更することです。
このガイドには、アマゾン ウェブ サービス (AWS) 用に設定できる環境変数の例が含まれています。
結論
Mandiant は、この脆弱性に関連する更新プログラムと関連する緩和策を引き続き提供します。 Mandiant Advantage Threat Intelligenceの無料サブスクリプションに登録すると、追加の情報とコンテキストにアクセスできます。
参照: https://www.mandiant.com/resources/blog/log4shell-recommendations
Comments