[2022-03-31 10:00 PDT更新] 脅威に関する情報: Apache Log4jに新たな脆弱性(CVE-2021-44228) 実際の悪用も確認

This post is also available in: English (英語)

概要

2021年12月9日、Apache Log4j 2に存在するリモートコード実行 (RCE) の脆弱性がすでに実際に悪用されていることが確認されました。公開されたPoC (proof of concept: 概念実証) コードは、その後の調査で、驚くほど簡単に悪用できることが判明しました。特別に細工されたリクエストを脆弱なシステムに送信することで、システムの構成によっては、攻撃者がそのシステムに悪意のあるペイロードをダウンロードして実行するよう指示することができます。この脆弱性が発見されたのが最近のことであるため、オンプレミスおよびクラウド環境の両方において、まだパッチが適用されていないサーバーが多数存在します。多くの深刻度の高いRCEエクスプロイトと同様に、これまでのところ、パッチが適用されていないシステムを探し出して悪用する目的で、CVE-2021-44228に対する大規模なスキャン活動がインターネット上で始まっています。すべてのシステムにおいて、Apache Log4j 2の最新バージョン (2.17.1) にアップグレードすることを強くお勧めします。このバージョンでは、12月14日に見つかった追加の脆弱性CVE-2021-45046、12月17日に見つかったCVE-2021-45105、12月28日に見つかったCVE-2021-44832も修正されています。

12月22日に本稿を更新し、パロアルトネットワークスNGFWの脅威防御シグネチャ「Apache Log4j Remote Code Execution Vulnerability」のヒット数分析から判明したLog4jのエクスプロイト試行の統計を掲載しました。エクスプロイトが成功した場合に試行されうる、大規模スキャン、脆弱なサーバーの発見、情報窃取、CobaltStrikeの配信、暗号通貨のマイニングなどのさまざまなアクティビティについて解説します。このほか、Log4j脆弱性に関連した最近のイベントを時系列で解説します。

12月28日、本稿を更新し、CVE-2021-44832に関する情報を掲載しました。CVE-2021-44832は、Log4j 2のインスタンスに影響を与えるリモートコード実行(RCE)の脆弱性で、これにより攻撃者がログ設定ファイルの変更権限を持ち、JDBC Appenderを使って悪意のある設定を行うことができる場合があります。このJDBC Appenderは、その後影響を受けるデバイス上でリモートコードを実行できるJDNI URIを参照します。

目次

影響を受けるバージョン
影響を受けるソフトウェア
Apache log4j 2の背景
脆弱性 (CVE-2021-44228) の説明
根本原因分析
エクスプロイト
実際に行われている攻撃
Log4jのリモートコード実行エクスプロイト試行に関する統計
観測されたアクティビティ
大規模スキャン
脆弱なサーバーの発見
V8パスワードスティーラ
Happy Everyday!とCobaltStrike
XMRigコインマイナー
パッチとバイパス: CVE-2021-45046、CVE-2021-45105、CVE-2021-44832に対する修正の追加
タイムライン
結論
追加リソース
謝辞

影響を受けるバージョン

2.17.0 未満の Apache Log4j 2.x (2.16.0 は後述の新たな脆弱性を含む)

影響を受けるソフトウェア

相当数のJavaベースアプリケーションがログユーティリティとしてlog4jを使用しており、このCVEの脆弱性があります。私たちの知る限りでは、少なくとも以下のソフトウェアに影響を及ぼす可能性があります。

• Apache Struts
• Apache Solr
• Apache Druid
• Apache Flink
• ElasticSearch
• Flume
• Apache Dubbo
• Logstash
• Spring-Boot-starter-log4j2

パロアルトネットワークスのお客様は、脅威防御セキュリティサブスクリプションをもつ次世代ファイアウォール(PA-Series、VM-Series、CN-Series)またはPrisma Accessで保護されています。またCortex XDRは、Linuxエンドポイントではエクスプロイト保護により、Windows、Mac OS、Linux エンドポイントではBTP (Behavioral Threat Protection) によりお客様を保護しています。Prisma Cloudは、Log4jの脆弱なインスタンスをもつ継続的インテグレーション（CI）、コンテナイメージ、およびホストシステムを検出できます。さらにCortex XSOARを利用すると、インシデント対応を自動化できます。

Apache log4j 2の背景

Apache log4j 2は、オープンソースのJavaベースのロギングフレームワークで、世界中多くのJavaアプリケーションで利用されています。オリジナルのlog4j 1.Xリリースと比べると、log4j 2は以前のリリースにおける問題に対処し、利用者にプラグインアーキテクチャを提供してきました。2015年8月5日、log4j 2が主流となり、旧バージョンのlog4jユーザーはすべてlog4j 2へのアップグレードが推奨されました。Apache log4j 2は、Apache Struts、ElasticSearch、Redis、Kafkaなど、多くの一般的ソフトウェアアプリケーションで広く使用されています。

簡単で柔軟なユーザーエクスペリエンスを提供する一方で、Apache log4j 2は歴史的に、ユーザー入力を処理してデシリアライズする際の脆弱性がありました。以前にも2つのデシリアライゼーションの脆弱性 (CVE-2017-5645およびCVE-2019-17571) が発見されており、提供されたユーザー入力データに対して必要な処理が行われなかったためにコードインジェクションやさらなるRCEが発生していました。

• CVE-2017-5645: Apache log4j 2.x の 2.8.2 以前では、log4j サーバーが他のアプリケーションから TCP または UDP ソケットサーバーを介して受信した任意のログイベントをデシリアライズします。この脆弱性を利用して細工したバイナリペイロードが送信されると、任意のコードが実行される可能性があります。
• CVE-2019-17571: Apache log4j のバージョン 1.2 (1.2.17 まで) では、SocketServer クラスに信頼されていないデータのデシリアライズに対する脆弱性があり、デシリアライズ用のガジェットと組み合わせられた場合、リモートからコードを実行される可能性があります。

脆弱性 (CVE-2021-44228) の説明

Apache log4jライブラリは、開発者がアプリケーション内でさまざまなデータを記録することを可能にします。特定の状況下では、ログに記録されるデータはユーザーの入力に由来するものになります。このユーザーの入力に特殊文字が含まれており、その後log4jのコンテキスト内でログに記録されると、最終的にはJavaメソッドのlookupが呼び出され、LDAPサーバー内のユーザー定義のリモートJavaクラスが実行されます。これにより、脆弱なlog4j 2インスタンスを使用している被害サーバーでRCEが発生します。

根本原因分析

詳細に調べてみたところ、log4j 2.xはlookupsと呼ばれるメカニズムをサポートしており、これが通常ならユーザーに柔軟にlog4j設定をセットアップするために使用されます。lookupsについての公式な説明は以下の通りです。

lookupsは、任意の場所でlog4jの設定に値を追加する方法を提供します。これらのプラグインは，StrLookupインターフェースを実装する特殊なタイプのプラグインです。

この機能を使うことで、一般ユーザーは、あらかじめ用意されたフォーマットを使って、任意の場所に便利かつ柔軟に値を設定することができます。具体的には、アプリケーションでlogメソッドを呼び出す際、log4j 2.xはformatメソッドを呼び出し、各ログに含まれる特定の文字${をチェックします。

これらの文字が存在する場合、Javaメソッドのlookupが呼び出され、文字${の後の文字列を見つけ、文字${の後の式を見つけておいた実際の値に置き換えます。たとえば、図1に示した内容をログに記録するためにアプリケーションのlog関数を呼び出す場合、${という文字の後にあるjava:runtime、java:vm、java:osという文字列はlookupメソッドのパラメータとみなされ、最終的には対応する値に置き換えられます。たとえば、Java(TM) SE Runtime Environment (build 1.7.0_67-b01) from Oracle Corporation、Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)、Windows 7 6.1 Service Pack 1, architecture: amd64-64などです。

lookups の機能がサポートするlookupには、Jndi Lookup、JVM Input Arguments Lookup (JMX) 、Web Lookupなどの種類があります。Jndi Lookupを使うとJNDIによって変数を取得させることができます。Jndi Lookupでは、リモートからlookupを行うために、LDAPやRMIなどのプロトコルがサポートされています。ログに図2のような文字列が含まれている場合、Javaメソッドのlookupが呼び出され、文字列 jndi:logging/context-nameが検索されます。

多くのアプリケーションにおいて、ログの内容は通常ユーザーに公開されており、攻撃者が容易に制御できることを考慮すると、攻撃者が図3に示すように文字列を制御し、攻撃者が制御するLDAPサーバーに悪意のあるJavaクラスを設定すれば、lookupメソッドを使ってリモートLDAPサーバー上の悪意のあるJavaクラスを実行させられることになります。

log4jライブラリは、非常に柔軟な機能をサポートする強力なログフレームワークです。しかし、便利な機能は同時に、セキュリティ上の問題を生じさせることもあります。ユーザーの入力を慎重にフィルタリング、そのデータ厳密にサニタイズしなければ、ユーザーの入力を盲目的に信頼することで、深刻なセキュリティ問題を引き起こす可能性があります。

エクスプロイト

CVE-2021-44228の脆弱性はエクスプロイトコードが公開されています。脆弱性のあるバージョンの log4j 2.x を使用している Java アプリケーションによってホストされているユーザー入力は、Java アプリケーション内でのロギング実装方法によっては、この攻撃にさらされる可能性があります。

実際に行われている攻撃

これまでのところ、インターネット上では、log4jの脆弱なインスタンスを特定する目的で、広範なスキャンが行われています。これらのスキャンはHTTP経由で行われており、特定のアプリケーションを対象としているわけではないようです。これらのリクエストの多くは、User-Agentフィールドを利用してインターネット上のシステムを特定し、悪用することを目的としています。こうしたリクエストの例は、以下のようなものです。

base64エンコードされたログがデコードされると、次のようなコマンドが表示されます。

この大規模なスキャンで観測された他のコマンドには、Kinsingコインマイナーマルウェアファミリに帰属する以下のものがあります。

Log4jのリモートコード実行エクスプロイト試行に関する統計

お客様が直面しているLog4jの最近の脆弱性の影響をより理解するために、Apache Log4j Remote Code Execution Vulnerability脅威防御シグネチャのヒット数を2021年12月10日～2022年2月2日にかけて分析しました。テレメトリに基づき、シグネチャをトリガーした関連パケットキャプチャを含む1億2,589万4,944件のヒットが観測されました。図7は、1日あたりのヒット数を示したものです。これには12月12日から16日にかけての大きなスパイク、12月16日から21日にかけてのアクティビティの漸減が見られ、2022年1月1日には再び大きなスパイクを記録していることがわかります。新年の急増後、シグネチャのヒット結果はカウントが日々ジグザグに上下していましたがスパイクは以前に比べて劇的に少なくなっています。

12月10日から31日にかけてシグネチャをトリガーしたパケットキャプチャを解析したところ、HTTPリクエスト内のさまざまな場所、主にURLやHTTPリクエストヘッダ内のフィールドにエクスプロイト試行が出現することがわかりました。パケットキャプチャから7,057万7,055個のエクスプロイト文字列を抽出したところ、49%以上がHTTPリクエストのトップ6フィールドに含まれていることが分かりました(表1)。なお多くのパケットキャプチャはHTTPリクエスト内の複数のフィールドに悪意のある文字列を含んでいるため、それぞれの文字列がこの数値に重複してカウントされている点にはご留意ください。

表1 Log4jのエクスプロイト試行で利用されたHTTPリクエスト内のフィールド上位6つ

観測されたアクティビティ

2021年12月10日以降、Log4jのエクスプロイトによるさまざまなアクティビティ試行が観測されています。なおこれらアクティビティの詳細の調査は、エクスプロイト試行時のコールバックURL上にホスティングされていたファイルを分析することで行いました。要するに「仮にエクスプロイトが成功していたら何が起こっていたのか」について調査したものです。エクスプロイト後に観察された活動は、大規模スキャンで脆弱なサーバーを特定するというシンプルなものから、機密情報の流出や追加ツールのインストールを目的としたバックドアの設置、金銭的利益を得るためのコインマイニングソフトウェアのインストールまで多岐にわたります。なお弊社テレメトリでは継続して攻撃が発見され続けているためこのセクションで説明した事例はまったく網羅的な内容ではありません。

大規模スキャン

Apache Log4j Remote Code Execution Vulnerabilityシグネチャに関連するアクティビティを分析したところ、Log4jのエクスプロイト試行の大半は大規模な脆弱性スキャンに関連していました。表2は、Log4jのエクスプロイト文字列内のコールバックURLに見られる上位ドメインとIPアドレスを示したものです。これらが12月10日から31日にかけてのシグネチャヒット数の80%強を占めています。これらのコールバックURLに見られるすべてのRFC1918のIPアドレス(IPv4プライベートアドレス範囲)を各アドレス範囲(10/8、172.16/12、192.168/16)に分類すると、この時間帯にヒットしたシグネチャの54％は内部スキャンによって生成されていることがわかりました。さらにこのリストではnessus[.]org などの有名どころの脆弱性スキャンサービスもリモートロケーションを含むコールバックのトップとして表示されています。

表2 Log4jのエクスプロイト試行のコールバックURLで見られた上位ドメインとIPアドレス

脆弱なサーバーの発見

私たちが観測したインバウンドのエクスプロイト試行の多くは、エクスプロイト成功を送信者に通知するアウトバウンドリクエストを送信するだけのものでした。これらの試みのすべてがスキャンを目的としていたのか、悪意のあるアクターの偵察活動の一環であったのかは確認できていません。そのなかにはコールバックURLとの最初のやりとりが脆弱なサーバーであることを示すというだけのエクスプロイト試行もあり、その多くは、以下のコールバックURLに見られるような「カナリアトークン」を使用していました。

x[hostname].l4j.2sk9753uabgse6xz75tooe5ix.canarytokens[.]com

ただし、アクターがコールバックURLからJavaクラスをロードして実行することにより当該の脆弱性をフルに悪用していることが確認されているケースもあります。それらのJavaクラスでは、外部サーバーへの接続により、システムの脆弱性の有無や悪用の可否を確認しています。たとえば、ここ数日のエクスプロイト試行で観測されたコールバックURLには以下のようなものがあります。

ldap://2.57.121[.]36:8000/mss_useragent
ldap://2.57.121[.]36:8000/mss_xapi
ldap://2.57.121[.]36:8000/mss_xforward

このURLにアクセスした当該サーバーはhxxp://2.57.121[.]36/Rjava.classにあるJavaクラスにアクセスします。 このコードを逆コンパイルしたのが 図8に示す内容です。

見ればわかるとおりこのJavaコードはhxxp://2.57.121[.]36/juccessへのHTTP GETリクエストを発行するだけで、レスポンスに対しては何も行っていません。このJavaコードの発行者は、対象のサーバーに脆弱性があり、このJavaクラスを正常に実行できるかどうかを判断する目的でエクスプロイトを利用しているものと考えられます。

V8パスワードスティーラ

こうした脆弱性スキャンに加え、エクスプロイトに成功してインフォスティーラが実行された例も観測されています。たとえば、下記の例に示したように、コールバックURLに1ma[.]xyzというドメインを含むコールバックURLを使用したエクスプロイト試行が複数観測されました。

<省略>.com.80.reference.1ma[.]xyz:1389/a

上記URLにより以下のファイルがもたらされます。

上記コードは、HTTP POSTリクエストやDNSトンネリングを介してデータを送信し、サーバーから情報を流出させようとしています。HTTP POSTリクエストは、以下のURLに送信されることになります。

hxxp://[hostname].[username]8.pef.mur.1ma[.]xyz/
hxxp://[hostname].[username]5.pef.mur.1ma[.]xyz:53/
hxxps://[hostname].[username]4.pef.mur.1ma[.]xyz/

DNSトンネリングでは、以下の構造でドメインへのクエリを行うことでデータをサーバーに送信します。

[hostname].[20 bytes of data].[chunk number].spif.mur.1ma.xyz

ここでC2ドメインに流出されるのは、2種類の一般的な情報です。1種類めは侵害されたサーバーにある機微な /etc/passwd ファイルの内容です。2種類めは環境変数名とそれぞれの値で、このコードはこれらの情報も取得してC2に送信します。

またこのJavaコードは、curlや wgetアプリケーションを使うコマンドを実行することでもC2サーバへのデータ送信を試みます(図11参照)。

Happy Everyday!とCobaltStrike

情報窃取のほかには、Log4jを悪用してバックドアが設置される例も確認されています。たとえば次のようなコールバックURLを含むエクスプロイト試行が見られました。

ldap://139.155.2[.]105:8888/EvilObj

上記URLにより以下のファイルがもたらされます。

hxxp://139.155.2[.]105:8081からのEvilObj.classという ファイルを逆コンパイルすると、図13に示したJavaコードが含まれています。

上の図13 のJava は、139.155.2[.]105:1234に対してrawソケットを作成し、そのソケットを介して以下の使用方法示を送信しています。

happy everyday!
help: list [dir] | read [file] | exec [cmd]

listコマンドは脅威アクターの指定するパス上のファイルをリストアップし、 readコマンドは指定されたパスにあるファイルの内容を読み取ります。execコマンドは Java.lang.Runtime.exec メソッドと使ってコマンドを実行し、その結果をアクターに送り返します。これら3つのコマンドは対象システムを完全にコントロールするのに十分な機能を備えています。

2021年12月18日、私たちは、CobaltStrikeサーバーが139.155.2[.]105にホストされているのを確認しました。このCobaltStrikeサーバーはTCP/4433でホストされており、CobaltStrikeビーコンの構成は、図14に示したとおりです。

XMRigコインマイナー 

金銭的動機を持つアクターがLog4jの脆弱性を利用してコインマイニング用のソフトウェアをインストールした形跡も確認されています。次のようなコールバックURLを含むエクスプロイト試行が見られました。

ldap://192.46.216[.]224:1389/Exploit

このコールバックURLでは以下のような応答が返ります。 

hxxp://165.22.2[.]186:80/wp-content/themes/twentyseventeen/Exploit.classが返したJavaクラスを逆コンパイルした内容を図16に示します。

図16のJavaコードは、システムがOSとしてWindowsを実行しているかどうかをチェックし、実行している場合はPowerShellコマンドを実行して追加ファイルをダウンロードして実行します。最初にダウンロードされたファイルはhxxp://150.60.139[.]51:80/wp-content/themes/twentyseventeen/s.cmdでホストされていたもので、このファイルにはコマンドラインから実行される以下のPowerShellが含まれています。

このPowerShellコマンドは、hxxp://68.183.165[.]105:80/wp-content/themes/twentyseventeen/xmrig64.exeからアプリケーションをダウンロードして実行しようとします。 これは暗号通貨Moneroのマイニングに使用されるXMRigの実行ファイルで、具体的には 46QBumovWy4dLJ4R8wq8JwhHKWMhCaDyNDEzvxHFmAHn92EyKrttq6LfV6if5UYDAyCzh3egWXMhnfJrEhWkMzqTPzGzsE のウォレットアドレスを使用していました。

パッチとバイパス: CVE-2021-45046、CVE-2021-45105、CVE-2021-44832に対する修正の追加

Apacheの公式パッチが公開されたことにより、当初は2.15.0-rc1でCVE-2021-44228の脆弱性が修正されたものと報告されていましたが、その後当該パッチをバイパスする方法が発見されました。新たにリリースされた2.15.0-rc2では、この脆弱性からユーザーを保護することができます。

12月14日、Log4j 2.15.0でリリースされた修正プログラムが不十分であることが判明しました。CVE-2021-45046が新たに発見された脆弱性に割り当てられました。 12月17日、Apacheはこの脆弱性の深刻度を上方に修正し、特定の状況下でリモートコードの実行に利用される可能性があることを示しました。

12月17日、CVE-2021-45105を修正するバージョン2.17.0がリリースされました。この新しい脆弱性は、バージョン2.16が、自己参照ルックアップによるコントロールされていない再帰から保護されていないことに起因しています。これが悪用されると、Log4jを実行しているプロセスに対してDoS攻撃を受ける可能性があることに注意してください。この脆弱性は、これまでのRCEの脆弱性に比べて重要度は低いものの、これにより攻撃者が脆弱なアプリケーションをクラッシュさせる可能性があります。潜在的な緩和策については、Apache Log4j のセキュリティアドバイザリを参照してください。

12月28日、CVE-2021-44832の修正のためバージョン2.17.1がリリースされました。 この新しい脆弱性により、デフォルト以外の特定条件下でRCEにつながる可能性があります。攻撃者がログ設定ファイルの変更権限を持ち、JDBC Appenderを使って悪意のある設定を行える場合、このJDBC AppenderがJDNI URIを参照して、影響を受けるデバイス上でリモートコードを実行する可能性があります。

タイムライン

結論

CVE-2021-44228、CVE-2021-45046、CVE-2021-45105、CVE-2021-44832の脆弱性は、影響の全容把握のため、今現在も積極的な調査が行われています。現在入手可能な情報からこれらの脆弱性は現在および将来において、深刻な影響を及ぼす可能性があります。影響を受けるアプリケーションの多くは企業ネットワークやホームネットワークで広く使用されています。ユーザーの皆様におかれましては、以下の通り、これらの脆弱性から保護するために必要な措置を講じてください。

Unit 42は、弊社の機器やクラウドソリューションを介した異常なトラフィックを積極的に監視しています。パロアルトネットワークスはこの脆弱性のエクスプロイトに対する保護を以下の方法で提供しています。

• 次世代ファイアウォール(PA-Series、VM-Series、 CN-Series)または脅威防御セキュリティサブスクリプションを持つPrisma Accessは、以下の脅威IDでこの脆弱性に関連するセッションを自動的にブロックできます。
  • 91991, 91994, 91995, 92001, 92007, 92012 (Application and Threat content update 8506)
  • すでに弊社のセキュリティベストプラクティスにしたがって対策をされているお客様は、これらの攻撃に対し、手動で介入することなく自動的に保護が提供されます。これらのシグネチャは攻撃の最初のステージをブロックします。
  • セキュリティプロファイルのベストプラクティスが適切なセキュリティポリシーに適用されていること、「Critical(緊急)」レベルの脆弱性が「reset(リセット)」または「default(デフォルト)」アクションに設定されていることを確認します。
  • またLog4jのリモートコード実行には外部にホストされたコードへのアクセスが必要です。Advanced URL Filtering セキュリティサービスは常時監視を継続し、新たな未知/既知の悪意のあるドメイン/Webサイトによる安全でない外部への接続をブロックします。
  • さらに、適切な出口方向(Egress)のアプケーションフィルタリングを使えば攻撃の第2段階をブロックできます。ldap、rmi-iiopのApp-IDを利用すると、信頼されていないネットワークや予期せぬ接続元との間のすべてのRMI、LDAPをブロックできます。
  • HTTPSを介した既知の攻撃をブロックするにはファイアウォール上で「SSL復号化」を有効にする必要があります。
  • log4jが自社環境内にあるお客様は、各ベンダが指示にしたがい、アップグレードまたは緩和策の適用を行うようにし、脅威防御シグネチャだけにたよらないようにしてください。
• Cortex XDRでLinuxエージェントとコンテンツ290-78377を稼働しているお客様は、すべてのエクスプロイトチェインからJava Deserialization Exploit protection moduleにより保護されています。Cortex XDRのお客様は、BTP (Behavioral Threat Protection) により、CVE-2021-44228に起因する様々な観測済みペイロードから保護されます。また、Analyticsを使用しているXDR Proのお客様は、この脆弱性に関連したポストエクスプロイト活動が検出されます。
• Cortex XSOARで「CVE-2021-44228 - Log4j RCE」パックを利用しているお客様は、同脆弱性が自動的に検出・緩和されます。 詳しくは、XSOAR マーケットプレイスからご確認ください。
• Prisma Cloud Compute Defenderエージェントは、継続的インテグレーション (CI) プロジェクト、コンテナイメージ、またはホストシステムが、2.14.1またはそれより古いバージョンの脆弱なLog4jパッケージまたはJARファイルを保持しているかどうかを検出できます。このほか、Web Application and API Security (WAAS) ルールを使ってエクスプロイトのペイロードを検出・ブロックできます。詳細は、Prisma CloudのLog4Shell 緩和策に関するブログからご確認ください。

SnortやSuricataを利用しているユーザーに向けて以下のルールがリリースされています。

• 2034647
• 2034648
• 2034648
• 2034649
• 2034650
• 2034651
• 2034652

Apache log4jを利用しているアプリケーションをお使いのお客様は、最新バージョンにアップグレードしてください。

最初のパッチ 2.15.0-rc1 はバイパス可能であることが判明しているため、この脆弱性に対してできる限りの保護機能を実装するために、以下の緩和策も推奨されます。

• パロアルトネットワークスのファイアウォールが保護するサーバー上でのLDAPやRMIなどの不審なアウトバウンドトラフィックを無効にする。
• JNDI Lookupを無効にする。
  • log4j2.formatMsgNoLookups=trueに設定する。
  • log4j-coreのJndiLookupファイルを削除してサービスを再起動する。
• JNDIの無効化
  • spring.jndi.ignore=trueに設定する。

パロアルトネットワークスは引き続き状況を監視し、新たな発見や情報があればこの文書を更新します。侵害の懸念があり弊社Unit 42インシデントレスポンスチームにインシデントレスポンスに関するご相談をなさりたい場合は、infojapan@paloaltonetworks.comまで電子メールにてご連絡いただくか、+81(50)1790-0200までお電話にてご連絡ください(ご相談は弊社製品のお客様には限定されません)。

追加リソース

Log4j リソースセンター
Apache Log4j Threat Update Briefing (オンデマンド)
Log4jの脆弱性「CVE-2021-44228 (Log4Shell)」に対するエクスプロイト活動の脅威ハンティング
弊社NGFWとクラウドセキュリティサービスでApache Log4jの脆弱性に対応する方法のまとめ
How Cortex XDR Blocks Log4Shell Exploits with Java Deserialization Exploit Protection
Shining a Light on Log4j Exploit Payloads

謝辞

本稿とその調査にご協力いただいたJen Miller-Osborn氏、Laura Novak氏、Joseph Opacki氏に感謝いたします。

2021-12-13 10:14 JST 英語版更新日 2021年12月12日 11:50 PST の内容を反映
2021-12-13 14:56 JST 英語版更新日 2021年12月12日 20:45 PST の内容を反映
2021-12-14 08:51 JST 英語版更新日 2021年12月13日 14:15 PST の内容を反映
2021-12-15 09:40 JST 英語版更新日 2021年12月14日 15:45 PST の内容を反映
2021-12-16 11:15 JST 英語版更新日 2021年12月15日 09:53 PST の内容を反映
2021-12-16 08:27 JST 英語版更新日 2021年12月16日 08:47 PST の内容を反映
2021-12-20 21:30 JST 英語版更新日 2021年12月18日 07:45 PST の内容を反映
2021-12-21 22:00 JST 英語版更新日 2021年12月20日 09:00 PST の内容を反映
2021-12-27 15:25 JST 英語版更新日 2021年12月23日 10:35 PST の内容を反映
2021-12-29 18:10 JST 英語版更新日 2021年12月28日 12:15 PST の内容を反映
2021-12-31 20:30 JST 英語版更新日 2021年12月30日 09:25 PST の内容を反映
2022-05-26 11:30 JST 英語版更新日 2022年03月31日 10:00 PDT の内容を反映