Log4jの脆弱性（「Log4Shell」）は、過去最悪のソフトウェアの欠陥の一つと考えられています。Apache社は、2021年12月にこの欠陥にパッチを適用しましたが、セキュリティーチームにとっては、依然として懸念事項となっています。実際に、未だに最も悪用されているセキュリティ脆弱性の一つです。
Log4Shellが永続化されているのは、それが影響するApache Log4j 2 ソフトウェア・パッケージが世界で最も広く使用されているロギングライブラリーの1つであるためです。米国国土安全保障省によると、Log4Shellのすべてのインスタンスを発見して修正するには10年かかると予想されています。
その間、セキュリティー担当チームは、ネットワーク内のLog4Shellの緩和と修復を加速するためのいくつかの措置を講じることができます。
Log4Shellの検知とパッチ適用の方法を詳しく掘り下げる前に、脆弱性の性質を理解することが重要です。
Log4j は、プログラム内の情報とイベントを記録するオープンソースのロガー（Apache Software Foundation が管理）です。Log4jはスタンドアロン・ソフトウェアではなく、開発者が独自のJavaアプリにプラグインできるコードのパッケージです。Apache Log4j フレームワークは、Amazon Web Services（AWS）やCiscoソリューションなどのネットワーク・インフラストラクチャーからTwitterやMinecraftのような人気アプリに至るまで、Web上のいくつかの大手サービスで使用されています。
Log4jの一部のバージョン（特に Log4j 2.17.0以前）には重大な脆弱性が存在します。これらの中で最も危険なのは、Log4jバージョン2.14.1 以前に発見されたリモート・コード実行（RCE）の ゼロデイ脆弱性 である Log4Shell（CVE-2021-44228、CVSS 評価：10）です。
外部サーバーにホストされているリソースへJavaアプリがアクセスする際に使用するAPI、Java Naming and Directory Interface (JNDI) を、脆弱なバージョンのLog4jが処理する際の方法を悪用したのがLog4Shellです。脅威アクターは、Log4jを通じて悪意のあるJNDIルックアップ・コマンドを送信することで、脆弱なシステムをほぼ完全に制御できるようになります。これらのコマンドは、アプリを騙して任意のコードを実行させ、データの盗難、ランサムウェアのインストール、デバイスのオフライン化など、ほぼあらゆる操作を実行させることができます。
典型的な Log4Shellサイバー攻撃の仕組みは以下の通りです。
ApacheがLog4Shellのパッチ適用に取り組んでいたとき、セキュリティー研究者はLog4jの一部のバージョンに関連するいくつかの欠陥を特定しました。以下にその例を挙げます。
ネットワーク内にあるLog4jの脆弱なインスタンスをすべて見つけ出すのは、場合によっては困難です。Log4jは推定で数百万件のアプリに使用されているため、セキュリティ・チームは大量のアセットを検査しなければなりません。
さらに、Log4jはしばしば間接的な依存関係として存在します。つまり、アセットのソースコードに直接含まれているのではなく、アセットが依存しているソフトウェア・パッケージ、または統合の依存関係として出現します。Google の報告によると、最も脆弱な Log4j インスタンスは依存関係のチェーン内で1レベル以上の深さにあり、中には9レベルもの深さに存在するものもあります。
とはいえ、セキュリティーチームは適切な施策とツールでLog4jの脆弱性を検知できます。
2.0-beta9から2.17まで、Log4j 2のすべてのバージョンは、Log4Shellまたは関連する欠陥に対して脆弱です。つまり、セキュリティー・チームは2.17.1より以前のバージョンのLog4jを探し出して対処する必要があります。
Log4Shellとそれに関連する欠陥は、Log4jの中核機能を提供する「Log4j-core」ファイルにのみ存在します。この欠陥は、アプリとLog4jロガー間のインターフェイスを制御する「Log4j-api」ファイルには存在しません。
Log4jは、会社が管理する資産、会社が使用するサード・パーティー資産（クラウド・サービスなど）、および企業ネットワークにアクセスするサービス・プロバイダーが使用する資産に表示される場合があります。Log4jが出現する可能性が最も高いのはJavaベースのアプリですが、依存関係と統合を通じてJava以外のアプリに存在することもあります。
Javaアプリ内では、Log4jなどのライブラリーはしばしばJavaアーカイブ・ファイル（「JARファイル」）にパッケージ化されています。JARファイルには他のJARファイルを含めることができ、そこに独自のJARファイルを含めることもできます。脆弱なバージョンのLog4jをすべて検出するには、セキュリティー・チームは最上位のファイルだけでなく、すべてのレベルのJARファイルを検査する必要があります。
専門家は、Log4jの脆弱性を見つけるために、さまざまな手法を組み合わせることを推奨しています。
手動検索。 セキュリティ・チームはLog4jの欠陥を手動で検索することができます。Apache Mavenなどの開発ツールを使用して、アプリ内のすべての依存関係をマップする依存関係ツリーを生成したり、外部の脅威インテリジェンスを使用して影響を受けるアセットを特定することもできます。たとえば、Cybersecurity and Infrastructure Security Agency（CISA）は、Log4Shellの影響を受けることが知られているソフトウェアのリストをまとめています。このリストはGitHub で入手できます。
Linux、Microsoft Windows、およびmacOSオペレーティング・システムでは、セキュリティー・チームは、コマンド・ライン・インターフェースを使用して、Log4jのインスタンスのファイル・ディレクトリーを検索できます。
脆弱性スキャンツール。 Log4Shellの発見を受けて、一部の組織はLog4jの脆弱性を発見するために設計された無料ツールをリリースしています。例としては、 Palantir の Log4j-snifferやCERT Coordination Center の scanner などが挙げられます。
専用のスキャナーはまだ利用可能ですが、脆弱性スキャナー、攻撃対象領域管理(ASM) プラットフォーム、EDR（エンドポイントの検知と対応）(EDR) ソリューションなどの多くの標準的なセキュリティ・ソリューションで Log4j の脆弱性を検知できるようになっています。
Log4Shellは依存関係チェーンの奥深くに隠れている可能性があるため、セキュリティ・チームは自動スキャンに加えて、ペネトレーション・テストなどのより実践的な方法も使用できます。
脅威ハンティング。CISAによると、攻撃者はLog4Shellを使用してネットワークに侵入し、侵入したアセットにパッチを適用して痕跡を隠蔽することが知られています。そのため、セキュリティ・チームは侵害がすでに発生していると想定し、Log4Shellのエクスプロイテーションの兆候を積極的に探すことが推奨されます。
セキュリティ情報およびイベント管理（SIEM）ソリューションや拡張検知および対応（XDR）プラットフォームなどのサイバーセキュリティー・ツールは、Log4Shellに関連する異常なアクティビティの検知に役立ちます。攻撃が深刻な結果を引き起こしうることを踏まえ、セキュリティ・チームは、Log4Shell のあらゆる兆候に対して完全なインシデント対応と調査手順を開始する必要があります。
Log4jの脆弱性に対処する際、セキュリティー・チームにはいくつかの選択肢があります。
Log4Shellおよび関連する欠陥を完全に修復するには、組織はネットワーク内のLog4jのすべてのインスタンスを最新バージョン（または少なくともバージョン2.17.1）に更新する必要があります。Log4jの最新バージョンでは、攻撃者がエクスプロイトできる機能が削除され、LDAPなど一般的にエクスプロイトされるプロトコルのサポートが削除されています。
システム全体で利用可能な単一のパッチはなく、Java自体の更新では、この問題の所在地は解決されません。セキュリティー・チームは、影響を受ける全アセット内の、すべてのLog4jのインスタンスを更新する必要があります。
セキュリティー研究者も、パッチ適用が理想的なソリューションであることに同意しています。パッチ適用が現実的でない場合、組織は他の緩和手順を使用して攻撃の可能性を最小限に抑えることができます。
脆弱なアプリでのメッセージ・ルックアップの禁止。攻撃者は、「メッセージ・ルックアップ置換」と呼ばれるLog4jの主要な機能を使用して、脆弱なアプリに悪意のあるコマンドを送信します。「log4j2.formatMsgnoLookups」システムプロパティを「true」に設定するか、「LOG4J_FORMAT_MSG_NO_LOOKUPS」環境変数の値を「true」に設定することができます。
メッセージ・ルックアップ置換機能を削除すると攻撃者による攻撃が困難になりますが、絶対確実というわけではありません。悪意のある攻撃者は引き続きCVE-2021-45046を使用して、デフォルト以外の設定を持つアプリに悪意のあるJNDIルックアップを送信できます。
脆弱なアプリからのJNDIlookupクラスの削除Log4jでは、JNDIlookupクラスによって、ロガーが JNDI ルックアップを処理する方法を制御します。このクラスがLog4jのクラス・ディレクトリから削除されると、JNDIルックアップを実行できなくなります。
Apache は、次のコマンドを使用して、脆弱なアプリから JNDIlookup クラスを削除できると述べています。
zip -q -d ログ4jコア-*.jarorg/apache/ロギング/Log4j/core/lookup/JndiLookup.class
この方法はメッセージ・ルックアップを禁止するよりも効果的ですが、攻撃者が再帰ルックアップを通じてサービス拒否攻撃を引き起こすなど、他のエクスプロイテーション攻撃を仕掛けるのを阻止することはできません。
潜在的なLog4Shell攻撃トラフィックをブロックする。 セキュリティ・チームは、 アプリケーション・ファイアウォール（WAF）、侵入検知および防止システム（IDPS）、EDR、その他のサイバーセキュリティー・ツールを使用して、LDAPや RMIなど一般的に使用されるプロトコルをブロックし、攻撃者が制御するサーバーとの間のトラフィックに介入できます。セキュリティ・チームは攻撃に関連付けられたIPアドレスや、攻撃者が悪意のあるリクエストでよく使用する「jndi」、「ldap」、「rmi」などの文字列をブロックすることもできます。
しかし、攻撃者は、新しいプロトコルやIPアドレスを使用したり、悪意のある文字列を難読化したりすることで、これらの防御を回避する場合があります。
影響を受けるアセットを隔離する。他の全ての対策が失敗した場合、セキュリティー・チームはパッチ適応までの間に影響を受けたアセットを隔離することができます。その1つの方法は、インターネットからは直接アクセスできない隔離されたネットワーク・セグメントに脆弱な資産を配置することです。保護を強化するために、このネットワーク・セグメントの周囲にWAFを配置できます。
Log4Shellの修復における難しい点の1つは、常にパッチが適用された状態を維持できるとは限らないことです。2022年11月、 Tenableは、Log4Shellに対して依然として脆弱なアセットの29%が「再発」であり、パッチが適用されたにもかかわらず欠陥が再び現れたと報告しました。こうした脆弱性の再発は、パッチが適用されていないバージョンのLog4jを含むソフトウェア・ライブラリを誤って使用してアプリを構築・更新することで起こります。
開発者は使用するフレームワークをより詳細に調べることができますが、JARファイルに数レベルの深層学習があると、脆弱なバージョンのLog4jを見逃しやすくなります。
正式な脆弱性管理およびパッチ管理プログラムを実装すると、セキュリティ・チームは、アセットを監視してLog4jの脆弱性が再発するかどうかをより効果的に監視できるようになります。定期的な脆弱性スキャンとペネトレーション・テストは、Log4Shellなどの新たな脆弱性を迅速に発見するのに役立ちます。パッチ管理を行うことで、ベンダーが修正プログラムをリリースするとすぐに、新たな脆弱性を確実に解決することができます。