Log4Shell: 2 つの検出技術

エンドポイント検出応答 (EDR) では、Log4j のインスタンスを特定することしかできません。Log4j の脆弱なバージョンを発見するためには動的チェックが必要です。

Log4j における脆弱性が 2021 年年末に報告され、年末の仕事納めをしていたはずの IT チームはその緊急対応に奔走されました。この新たに開示された脆弱性を理解することは、Log4j インスタンスの正確なインベントリを取得するよりもはるかに困難な問題で、休日を返上して作業をしたチームは、Log4j のライブラリがプレイステーション 5 よりも追跡が難しく厄介なことを身をもって経験するはめになりました。

エンドポイントエージェント (エンドポイント検出および応答 (EDR) など) や資格情報のスキャンができるのは、Log4j のインスタンスを特定することだけです。多くの Java ライブラリと同様に、Log4j は「Fat Jars」 (すべての外部依存関係を含む Jar ファイル) にバンドルされるか、ライブラリバージョンをシェーディングして競合の可能性を減らすためにソースコードに直接挿入されることがよくあります。Log4j をインストールしているかどうかを確認するだけでは脆弱な場所は明確に把握できません。

「EDR が Log4j が悪用の試みを検出して阻止してくれる」と軽視されているかもしれませんが、攻撃者は、EDR プロセスモニタに監視されないように、Java 仮想マシン (JVM) 内にとどまる可能性があります。そのため、サーバーからのアウトバウンドコールをブロックしても効果的ではありません。Java 仮想マシン内に不正なアクティビティを隠すという考えは新しいものではないのに、大手 EDR ベンダーは、今でもこの問題に十分に対処していません。Java ベースでない限り、EDR は侵害を阻止できます。

Log4j 検出の問題に対処するために、Tenable は、この脆弱性が発表されてから数時間以内に、評価に対するまったく新しいアプローチをリリースしました。簡単に説明すると、動的チェックにより、Java Naming and Directory Interface (JNDI) クエリがターゲットに送信され、Tenable がホストするシステムに一意のトークンを送信するように、Log4j に対して脆弱なシステムに指示します。そして、スキャナがメッセージが受信されたかどうかを確認します。この方法では、問題のあるシステム (スタックまたはアプリケーションコード内のどこかに脆弱性のあるライブラリが存在するシステム) からのみトークンが送信されるため、多数のポートとプロトコルの中から脆弱なバージョンの Log4j をより簡単に発見できます。

その結果、脆弱性公表から数日後、毎秒、数多くの一意のトークンが Tenable に送信されました (計 1,400以上)。Tenable によって評価された資産の 10 分の 1 が脆弱でした。

Log4j の場合、偽陰性による検出漏れは、評価が不十分なためにシステムが脆弱なままになっていることを意味する可能性があります。エンドポイント検出応答に依存するだけでは防衛は不十分です。巧妙な攻撃者はこの脆弱性を悪用して攻撃の足がかりを作ります。脆弱なアプリケーションやプロトコルは増え続けていますが、Tenable はこれらから Log4Shell を検出するソリューションで引き続き市場をリードするために多大な努力を続けていきます。

もっと詳しく

• 動的プラグインを介して Log4j を特定する新しいアプローチの詳細については、テクニカルホワイトペーパーをご覧ください。
• Log4j に関する最新情報についてはこちらのランディングページから
• ブログ記事: Tenable の動的検出を使用して攻撃者のように Log4Shell の脆弱性を検出もご覧ください。