Log4J-緩和策-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

Apache Log4j チームがさらに多くの CVE を開示し、セキュリティ問題を非常に迅速に修正しているため、このページに注目してください。

更新 - 2021年12月28日

CVE-2021-44832: Apache Log4j2 は、攻撃者が構成を制御した場合に JDBC Appender を介して RCE に対して脆弱です。

Log4j 2.17.1 (Java 8)、2.12.4 (Java 7)、2.3.2 (Java 6) で修正済み

更新 - 2021年12月17日

一夜のうちに、Log4j バージョン 2.16 も サービス拒否攻撃 に対して脆弱であり、影響は アプリケーションの完全なクラッシュ であることが Apache によって開示されました。この深刻度は 高 (7.5) に分類され、CVE-2021-45105 が発行されました。Apache は新しい修正版 (2.17) を公開しており、アップグレードが推奨されています。

背景:

インターネット上では、Java 向けの Apache の一般的な Log4J ロギングライブラリにおける 0-day 脆弱性（リモートコード実行につながる可能性があるもの）についての議論が活発に行われていました。この特定の脆弱性は、CVE-2021-44228 として追跡され、CVSS スコアは最大の「critical」である 10 で、Log4J のルックアップ機能と JNDI（Java Naming and Directory Interface）を組み合わせた部分に存在します。多くの開発者が、Log4J がフィルタリングされていない入力と一緒に使用すると危険であることを認識していなかったため、この問題は広範囲に及びます。

最も重大な影響は、攻撃者がロガーに文字列を到達させ、それが Log4J によって処理されると任意のコードが実行されることです。この最初の例では ${jndi:ldap} パスが使用され、リモート URL から任意のコードがロードされる可能性がありました。このパスは、デフォルトで URL ベースのクラスローダーをブロックする新しい Java ランタイムを使用することで部分的に緩和されます。残念ながら、アプリケーション自体が任意のコードを実行するために使用できるクラスを公開する可能性があるため、最新の Java バージョンだけでは悪用を防ぐのに十分でない場合があります。

JNDI アーキテクチャ:

jndiarch

さまざまな環境向けの緩和策:

更新 - 2021年12月17日

セキュリティ脆弱性 CVE-2021-45105

詳細:

Apache Log4j2 バージョン 2.0-alpha1 から 2.16.0 は、自己参照ルックアップによる無制御の再帰から保護していませんでした。ロギング構成が Context Lookup を伴う非デフォルトの Pattern Layout（例: $${ctx:loginId}）を使用する場合、Thread Context Map（MDC）入力データを制御できる攻撃者は、再帰ルックアップを含む悪意のある入力データを作成でき、その結果プロセスを終了させる StackOverflowError が発生します。これは DOS（Denial of Service）攻撃としても知られています。

緩和策:

バージョン 2.17.0（Java 8 用）以降では、構成内のルックアップ文字列のみが再帰的に展開されます。その他の使用方法では、トップレベルのルックアップのみが解決され、ネストされたルックアップは解決されません。

以前のリリースでは、ロギング構成が次のように設定されていることを確認することで、この問題を緩和できます:

ロギング構成の PatternLayout で、${ctx:loginId} や $${ctx:loginId} などの Context Lookup を Thread Context Map パターン（%X、%mdc、または %MDC）に置き換えてください。
それ以外の場合は、構成内で、HTTP ヘッダーやユーザー入力などアプリケーション外部のソースから取得される ${ctx:loginId} や $${ctx:loginId} などの Context Lookup への参照を削除してください。

更新 - 2021年12月13日

** Log4j（リリース 2.16.0 – 2021-12-13）には 2 つの改善された機能があります:**

---------------!!メッセージルックアップがデフォルトで無効になっているため、利用可能な最新バージョンへのアップグレードを強くお勧めします。!!------------

https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

デフォルトで JNDI を無効化。JNDI を許可するには log4j2.enableJndi を true に設定する必要があります。

Message Lookups のサポートを完全に削除

新しい更新:

------------------CVE-2021-45046-----------------

Apache Log4j2 の Thread Context Message Pattern と Context Lookup Pattern は、サービス拒否攻撃に対して脆弱です。

緩和策:

Log4j 1.x の緩和策: Log4j 1.x はこの脆弱性の影響を受けません。

Log4j 2.x の緩和策: 以下の緩和手法のいずれかを実施してください。

Java 8（またはそれ以降）のユーザーはリリース 2.16.0 にアップグレードしてください。

Java 7 が必要なユーザーは、リリース 2.12.2 が利用可能になり次第アップグレードしてください（作業中であり、間もなく利用可能になる見込みです）。

それ以外の場合は、クラスパスから JndiLookup クラスを削除してください: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

この脆弱性の影響を受けるのは log4j-core JAR ファイルのみであることに注意してください。log4j-core JAR ファイルなしで log4j-api JAR ファイルのみを使用するアプリケーションは、この脆弱性の影響を受けません。

------------------CVE-2021-44228-------------------

緩和策

Log4j 1.x の緩和策: Log4j 1.x には Lookups がないため、リスクは低くなります。Log4j 1.x を使用するアプリケーションは、構成で JNDI を使用する場合にのみこの攻撃に対して脆弱です。この脆弱性については、別の CVE（CVE-2021-4104）が発行されています。緩和するには: JMSAppender が構成されていないことを確認するために、ロギング構成を監査してください。

JMSAppender がない Log4j 1.x 構成は、この脆弱性の影響を受けません。

Log4j 2.x の緩和策: 以下の緩和手法のいずれかを実施してください。

Java 8（またはそれ以降）のユーザーはリリース 2.16.0 にアップグレードしてください。

それ以外の場合は、クラスパスから JndiLookup クラスを削除してください: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

 1. Apache Log4j:
        リリース >=2.10** および
        リリース >=2.0-beta9 かつ <=2.10.0 の場合

2. pom.xml の修正:

3. Azure App Service（Windows および Linux）:

4. コンテナ化されたアプリケーション全般:

5. Azure Functions:

6. Apache Log4j 用ホットパッチ:

7. Defender for Cloud が Log4j の脆弱性の影響を受けるマシンを検出する方法:

8. Azure Sentinel および Azure WAF ログでの検出:

9.Maven プラグイン構成（将来のビルドで脆弱な log4j2 バージョンを禁止）:

1. Apache Log4j:

CVE-2021-44228: Apache Log4j2 の JNDI 機能は、攻撃者が制御する LDAP およびその他の JNDI 関連エンドポイントから保護しません。

影響を受けるバージョン: すべての log4j-core バージョン >=2.0-beta9 かつ <=2.14.1

Apache Log4j <=2.14.1 の構成、ログメッセージ、およびパラメータで使用される JNDI 機能は、攻撃者が制御する LDAP およびその他の JNDI 関連エンドポイントから保護しません。メッセージルックアップ置換が有効な場合、ログメッセージまたはログメッセージパラメータを制御できる攻撃者は、LDAP サーバーからロードされた任意のコードを実行できます。log4j 2.15.0 以降、この動作はデフォルトで無効になっています。

リリース >=2.10** では、システムプロパティ log4j2.formatMsgNoLookups または environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true を設定することで、この動作を緩和できます。リリース >=2.7 かつ <=2.14.1 の場合、すべての PatternLayout パターンを変更して、メッセージコンバーターを単なる %m ではなく %m{nolookups} として指定できます。

リリース >=2.0-beta9 かつ <=2.10.0 の場合、緩和策はクラスパスから JndiLookup クラスを削除することです: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。

2.pom.xml の修正:

pom.xml の依存関係を更新し、dependencies セクションで利用可能な最新バージョンと置き換えてください: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom

<dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->            
<!--         <version>2.17.0</version>-->
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->       
<!--         <version>2.17.0</version>-->
        </dependency>
    </dependencies>

参照: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18

3.Azure App Service（Windows および Linux）:

可能であれば、顧客は Log4j をバージョン v2.15.0 にアップグレードし、アプリケーションを再デプロイしてください。これが主に推奨される緩和策です。アプリケーションを再デプロイできない場合は、Log4j バージョン 2.10 以降で、システムプロパティ “-Dlog4j2.formatMsgNoLookups=true” を設定することでこの動作を緩和できます。App Service では、値が “-Dlog4j2.formatMsgNoLookups=true” の JAVA_OPTS という名前のアプリ設定を作成することで、このプロパティを設定できます。JAVA_OPTS アプリ設定は、アプリケーションの起動時に Java アプリケーションに渡されます。すでに JAVA_OPTS アプリ設定が設定されている場合は、既存の値に “-Dlog4j2.formatMsgNoLookups=true” を追加するだけです。Log4J バージョン 2.9 以前を使用している場合、このシステムプロパティによる緩和策は機能しないため、v2.15.0 にアップグレードする必要があります。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"

4.コンテナ化されたアプリケーション全般

コンテナ化されたアプリケーションの場合、使用している Log4j 2 のバージョンが 2.10.0 以降であれば、安全でない置換動作を無効にするために使用できる環境変数または Java コマンドラインオプションがあります。次の行を追加できます:
```
 ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
```
Dockerfile の参照: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
Dockerfile に追加するか、コンテナ内で実行するコマンドに同等のフラグ "-Dlog4j.formatMsgNoLookups=true" を追加することもできます。例:
```
 CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
```
環境変数を実行時に構成することもでき、その方が簡単な場合があります。たとえば Kubernetes では、次の行を構成に追加できます。
```
 spec:
   containers:
   - name: ...
     image: ...
     env:
     - name: LOG4J_FORMAT_MSG_NO_LOOKUPS
       value: "true"
```

5.Azure Functions:

システムプロパティの構成は、選択したホスティングオプション（dedicated、premium、または consumption）によって異なります。念のため、主に推奨される緩和策は Log4J を 2.15.0 にアップグレードしてアプリケーションを再デプロイすることです。何らかの理由でそれができない場合は、システムプロパティを適用できます。

- Dedicated および Premium Functions:

値が “-Dlog4j2.formatMsgNoLookups=true” の JAVA_OPTS という名前のアプリ設定を作成してください。すでに JAVA_OPTS アプリ設定が設定されている場合は、既存の値に “-Dlog4j2.formatMsgNoLookups=true” を追加するだけです。

- Consumption Functions:

Linux: 値が “-Dlog4j2.formatMsgNoLookups=true” の “languageWorkers__java__arguments” という名前のアプリ設定を作成してください。 Windows: 値が “-Dlog4j2.formatMsgNoLookups=true” の “languageWorkers:java:arguments” という名前のアプリ設定を作成してください。 **アプリ設定を更新すると Web アプリと Function アプリが再起動され、コールドスタートのパフォーマンスに影響する可能性があることに注意してください。Log4J バージョン 2.9 以前を使用している場合、このシステムプロパティによる緩和策は機能しないため、v2.15.0 にアップグレードする必要があります。

6.Apache Log4j 用ホットパッチ

どのように機能しますか? このツールは、実行中の JVM プロセスに Java エージェントを注入します。エージェントは、ロードされたすべての org.apache.logging.log4j.core.lookup.JndiLookup インスタンスの lookup() メソッドをパッチし、無条件に文字列 “Patched JndiLookup::lookup()” を返すように試みます。これは、Java プロセスを再起動せずに Log4j の CVE-2021-44228 リモートコード実行脆弱性に対処するために設計されています。

Java プロセスを再デプロイできる場合は、静的エージェントとして使用することもできます。つまり、サーバーに直接ログインしなくても、このパッチをランタイムに含めることができます。

Github: https://github.com/corretto/hotpatch-for-apache-log4j2

7.Defender for Cloud が Log4j の脆弱性の影響を受けるマシンを検出する方法

インベントリを使用すると、曝露を判断するための 2 つの強力な方法があります:

ソフトウェアインベントリ

脆弱性評価の結果

https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/how-defender-for-cloud-finds-machines-affected-by-log4j/ba-p/3037271

8.Azure Sentinel および WAF ログでの検出:

Azure WAF Log4j CVE-2021-44228 ハンティング

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/WAF_log4j_vulnerability.yaml

Log4j の脆弱性（CVE-2021-44228）に対する Azure WAF マッチング

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AzureDiagnostics/AzureWAFmatching_log4j_vuln.yaml

9.将来のビルドで脆弱な log4j2 バージョンを禁止するための Maven プラグイン構成:

古い log4j2 バージョンの使用を避けるために親 POM に配置する Maven プラグイン構成。これらの一部は RCE CVE-2021-44228（“Log4Shell”）、CVE-2021-45046、および CVE-2021-45105）の影響を受けます。

参照: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

 <!-- plug-in configuration to put into your parent POM for avoiding any usages of
     outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
     ("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
     latest version of log4j2 at
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

コントリビューション:

コミュニティからのコントリビューションを歓迎します。コントリビューションガイドライン:

-->PR を作成してください。

-->より多くの文脈のために、参照ソースを必ず含めてください。

さまざまな環境や他の修正方法があるかもしれません。遠慮なくプルリクエストを開いてください:

参照:

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

https://github.com/justincormack/log4jpoc

https://www.rumble.run/blog/finding-log4j/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay