CVE-2021-44228 Apache Log4j 2に対するマイクロソフトの対応

概要

マイクロソフトは、2021年12月9日に公開されたApache Log4j（多くのJavaベースのアプリケーションで使用されるログツール）に関連するリモートでコードが実行される脆弱性の分析を継続しています。現在、マイクロソフトは、Minecraft: Java Editionに関する最初の開示以外で、エンタープライズサービスのセキュリティに対する影響は確認されていません。また、この脆弱性に起因するサービスの可用性低下は確認されていません。

マイクロソフトのセキュリティチームは、Apache Log4j 2のCVE-2021-4428およびCVE-2021-45046のインスタンスを特定し緩和するために、マイクロソフト製品およびサービスの分析を実施しています。

お客様にて作業が必要な影響を受けるMicrosoft製品は、セキュリティ更新プログラムガイドCVE-2021-44228で公開しています。早期に必要な更新を適用することを推奨しています。CVEに明記されているサービス以外のMicrosoftサービスを使用している場合は、現時点で必要な作業はありません。調査を継続し、お客様のデータへの影響を特定した場合は、影響を受ける当事者に通知します。

お客様が自組織を保護し、セキュリティ能勢（セキュリティポスチャー）を向上させるために役立てていただけるよう、製品固有のガイダンスも提供しています。

回避策

より完全なセキュリティ更新プログラムを適用できるようになるまでの間、Log4j2.xの脆弱性のリスクを軽減するには、すべてのリリースのLog4j 2.x（リリース2.16.0以降および2.12.2を除く）は、次の緩和策の手順を検討する必要があります。これらの回避策は、これらの脆弱性を解決するための完全な解決策とは見なされません。

2.16.0より前のすべてのリリースのLog4j 2.xでは、セキュリティ更新プログラム以外にも最も効果的な緩和策は、アプリケーションのクラスパスにJndiLookup.classファイルが読み込まれないようにすることです。

お客様は、影響を受けるJARファイルからクラスを削除することでこれを行うことができます。例えば：

1

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

Log4jは、バンドルまたは網掛けライブラリとして他のファイルに存在する場合もあります。マイクロソフトは、log4j-core-*.jarファイル以外の広範な検索を実行することをお勧めします。

Log4j 2の脆弱なコンポーネントを更新できない場合、Log4J 2バージョン2.10から2.14.1では、パラメーターlog4j2.formatMsgNoLookupsを’true’に設定して脆弱な機能を無効にできます。Java仮想マシンのスタートアップスクリプトでこのパラメーターが構成されていることを確認します。

1

-Dlog4j2.formatMsgNoLookups=true

または、Log4j 2.10から2.14.1を使用しているお客様は、LOG4J_FORMAT_MSG_NO_LOOKUPS=“true"環境変数を設定してこの変更を強制することもできます。

Kubernetes管理者は、“kubectl set env"を使用してLOG4J_FORMAT_MSG_NO_LOOKUPS=“true"環境変数を設定して、JavaアプリケーションがLog4j 2.10から2.14.1を実行しているKubernetesクラスター全体に緩和策を適用できます。この場合、すべてのポッドとコンテナーに効果的に反映されます。

これらの変更を有効にするには、アプリケーションの再起動が必要です。

Log4jの背景

これらのCVE-2021-44228およびCVE-2021-45046として追跡されている脆弱性は、「Log4Shell」とも呼ばれ、Log4jバージョン2.0から2.15.0を使用するJavaベースのアプリケーションに影響します。Log4j 2は、ビジネスシステム開発で広く使用され、さまざまなオープンソースライブラリに含まれ、主要なソフトウェアアプリケーションに直接埋め込まれているJavaベースのログライブラリです。影響の範囲は、数千もの製品とデバイスにまで拡大しています。これには、Struts 2, Solr, Druid, Flink, Swift, KarafなどのApacheが含まれます。これらの脆弱性はJavaライブラリ内に存在するため、Javaのクロスプラットフォームの性質は、Windows, macOS, Linuxを含む多くのプラットフォームでこれらの脆弱性が悪用可能であることを意味します。多くのJavaベースのアプリケーションがLog4j 2を、直接的または間接的に利用できるため、組織はアプリケーションベンダーに問い合わせるか、Javaアプリケーションが最新バージョンを実行していることを確認する必要があります。Log4j 2を使用する開発者は、ユーザーと組織を保護するために、できるだけ早く最新バージョンのLog4jをアプリケーションに組み込む必要があります。

脆弱性の分析

これらの脆弱性はリモートでコードが実行される脆弱性で、認証されていない攻撃者が標的のシステムに完全にアクセスできる可能性があります。これらの脆弱性は、特別に細工された文字列が脆弱なLog4j 2コンポーネントによって解析および処理される際に、トリガーされる可能性があります。これは、ユーザーが提供するあらゆる入力によって発生する可能性があります。

悪用に成功すると、標的のアプリケーションで任意のコードが実行される可能性があります。攻撃者は、文字列を記録するためにシステムに事前にアクセスする必要はありません。また、標的のシステムに対してcurlなどのコマンドを使用してアプリケーションログに悪意のある文字列を記録することで、ログイベントをリモートで引き起こす可能性があります。ログを処理する際、脆弱なシステムが文字列を読み込んで実行します。現在の攻撃では、悪意のあるドメインからコードを実行するために使用されます。これが実行されると、影響を受けるアプリケーションに対するフルアクセスと制御が攻撃者に付与される可能性があります。

アプリケーションおよびサービスのロギングコードと機能は、通常、上位層からくる様々な外部入力データや、多くの可能なベクターからくるデータを処理するように設計されていることを考えると、この脆弱性の最大のリスク要因は、不正な悪用文字列が脆弱なLog4j 2のコードに到達して攻撃をトリガーするような攻撃ベクターのパスを、アプリケーションが持っているかどうかを予測することです。

悪用リスクの一般的なパターンは、例えば、ログ内のユーザー名、リファラー、またはユーザーエージェントの文字列を処理するように設計されたコードを持つWebアプリケーションです。これらの文字列は、外部入力として提供されます（例：Apache Strutsを使用して構築されたWebアプリケーションなど）。攻撃者は、この外部入力が脆弱なLog4j 2コードによってある時点で処理され、コードの実行がトリガーされることを期待して，不正な形式のユーザー名を送信したり、細工された悪用文字列を設定したユーザーエージェントを設定したりする可能性があります。

Microsoftサービスの緩和策ガイダンス

マイクロソフトのサービスと製品について詳細に分析した結果、さまざまなMicrosoftサービスで提供しているいくつかの緩和策を以下に示します。

システムプロパティlog4j2.formatMsgNoLookupsまたは環境変数LOG4J_FORMAT_MSG_NO_LOOKUPSを有効にすることで、メッセージ検索機能を無効にすることに基づく緩和策は、これらの脆弱性に関連するすべてのリスクをカバーするわけではありません。お客様は、引き続き最新のセキュリティ更新プログラムを適用するか、アプリケーションクラスパスからJndiLookup.classファイルを削除するなど、記載されている他の軽減手順を適用する必要があります。

Azure Bot Service

Azure Bot Serviceはlog4jを使用していないため、影響はありません。ただし、Java Bot Framework SDKをご利用のお客様は、Botプロジェクトで依存関係を4.14.2に更新する必要があります。また、BotプロジェクトでLog4jに明示的に依存している場合は、2.17.1に更新する必要があります。

Azure Arc-enabled Data Services

SQL Arc対応データサービスには、Log4jを使用するElasticsearchが含まれています。すべてのお客様は、Log4Jライブラリを2.16.0に更新した2021年12月のリリースにアップグレードすることをお勧めします。Azure Arc対応データサービスは、この脆弱性の影響を受けない、CVEK 11上のElasticsearchバージョン7.9.1を提供しています。詳細については、Elasticセキュリティ情報を参照してください。Apache Log4j2 Remote Code Execution (RCE) Vulnerability – CVE–2021–44228 – ESA–2021–31 – Announcements / Security Announcements – Discuss the Elastic Stack.

多層防御策として、Microsoftはlogsdb statefulset/elasticsearchコンテナーを変更して、次の環境変数をtrueに設定することをお勧めします。

1

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Azure App Service (Windows, Linux, およびContainers)

Azure App Service and Functionsは、Log4Jを、Java SE, JBoss EAP, Functions Runtimeなどのマネージランタイムに配布しません。ただし、お客様のアプリケーションがLog4Jを使用しておりこれらの脆弱性の影響を受ける可能性があります。

最新のLog4jセキュリティ更新プログラムを適用し、アプリケーションを再展開することをお勧めします。

新しいバージョンのLog4jでアプリケーションを再パッケージ化できず、Log4jバージョン2.10から2.14を使用している場合は、次のようにAzure CLIで値がtrueの環境変数LOG4J_FORMAT_MSG_NO_LOOKUPSのアプリケーション設定を作成することで、緩和できます。

1
2
3
4


$ az webapp config appsettings set \
 --resource-group <group-name> \
 --name <app-name> \
 --settings LOG4J_FORMAT_MSG_NO_LOOKUPS=true

このコマンドを実行すると、App Serviceも再起動されます。

Azure Databricks

影響を受けるバージョンのLog4jをインストールしたか、影響を受けるバージョンに推移的に依存するサービスをインストールしている場合、インスタンスは脆弱である可能性があります。インストールされている脆弱なLog4j 2インスタンスの確認の詳細については、次のマイクロソフトドキュメントを参照してください。Verify the version of Log4j on your cluster.

Azure Application Gateway、Azure Front Door、Azure WAF

これまでの調査では、これらのサービスが脆弱であるという証拠は見つかりませんでしたが、これらのサービスの背後で実行されているお客様のアプリケーションがこの悪用に対して脆弱である可能性があります。アプリケーションを保護するために、このブログに記載されている緩和策と回避策に従うことを強くお勧めします。Azure WAFの追加ガイダンスについては、こちらを参照してください。

Azure Functions

最新のLog4jセキュリティ更新プログラムを適用し、アプリケーションを再展開することをお勧めします。使用できない場合で、Log4jバージョン2.10から2.14.1を使用している場合は、環境変数またはシステムプロパティを構成する方法は、ホスティングオプション（専用、プレミアム、または使用）の選択によって異なります。

専用プランとPremiumプランのFunctions: 2つのアプリ設定を作成します。
- LOG4J_FORMAT_MSG_NO_LOOKUPS with value =true
- WEBSITE_USE_PLACEHOLDER with value =0

これは、次のAzure CLIコマンドで実行できます。

1
2
3
4
5


$ az functionapp config appsettings set \
–subscription \
–name \
–resource-group \
–settings "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" "WEBSITE_USE_PLACEHOLDER=0"

従量課金プランのFunctions:
- Linux: “-Dlog4j2.formatMsgNoLookups=true"の値を持つ"languageWorkersjavaarguments"という名前のアプリケーション設定を作成します。
- Windows: “-Dlog4j2.formatMsgNoLookups=true"の値を持つ"languageWorkers:java:arguments"という名前のアプリケーション設定を作成します。

これらのアプリケーション設定はFunctionアプリを再起動し、今後のコールドスタートパフォーマンスに影響するウォームワーカーを使用しなくなります。

Azure HDInsights

2021年12月16日の01:15 UTCより前に作成されたすべてのAzure HDInsightクラスターは、お客様の構成により更新プログラムが禁止されていない限り、Microsoft’s Response to CVE-2021-44228 Apache Log4j 2で説明されているように、Log4jの脆弱性を緩和するために修正プログラムが適用され、再起動されました。現在サポートされているコンポーネントのすべてのAzure HDInsight 5.0、4.0、および3.6クラスターに修正プログラムが適用されました。

推奨するアクション

2021年12月16日（米国時間）以降に2021年15月15日UTCに作成されたクラスターの場合、クラスターが作成されてから1時間以内にパッチが自動的に適用されます。ただし、パッチ適用が完了するにはノードを再起動する必要があります（Kafka Managementノードは自動的に再起動されます）。緩和策を完了するために、できるだけ早く再起動をスケジュールすることをお勧めします。

次のノードタイプでは、パッチの適用後に再起動が必要です。

クラスタータイプ	再起動する必要があるノードの種類
Kafka & HBase	Head Nodes
Hadoop, Spark, Interactive Hive/LLAP	Head Nodes & Worker Nodes

クラスターを定期的に削除して再作成する場合、または構成によってMicrosoftがクラスターに更新プログラムを適用できない場合は、クラスター作成プロセスの一部としてhttps://hdiconfigactions.blob.core.windows.net/patch-log4j-cve/patch-log4j-cve-2021-44228-all-rev2.shパッチを永続的なスクリプトアクションとして実行し、上記のノードタイプで再起動を直ちにスケジュールする必要があります。ジョブは、パッチが適用され、影響を受けるノードが再起動され、脆弱性が修正された後にのみ実行する必要があります。

修正プログラムを組み込んだ新しいHDInsightイメージが利用可能になるまで、この更新プログラムは保持スクリプトアクションとして新しいクラスターごとに実行する必要があります。

注: この更新プログラムはリ

微软应对Apache Log4j 2远程代码执行漏洞CVE-2021-44228的技术指南

本文详细介绍了微软针对Apache Log4j 2漏洞CVE-2021-44228的响应措施，包括受影响服务的缓解指南、安全更新建议、漏洞分析以及针对安全运营人员的检测和狩猎信息。