This post is also available in: English (英語)
概要
2021年12月9日、Apache Log4j ライブラリに潜む重大なリモートコード実行(RCE)脆弱性が実際に悪用されていることが判明しました。Log4Shellという名称で知られるこの脆弱性を悪用すると、影響を受けるサーバーで任意のコードをリモート実行されてしまいます。
Cortex XDRエージェントは、Log4Shell攻撃などのエンドポイントへの攻撃に対する包括的な保護を提供します。Windows、Linux、Macいずれのシステムでも、Behavioral Threat Protection、AIを活用したローカル分析、クラウドベースのマルウェア分析、その他のセキュリティエンジンを利用して、Log4Shellエクスプロイト後の活動を阻止することが可能です。
また、Cortex XDRは初期段階の偵察とエクスプロイトの兆候から、攻撃プロセスが開始した後に現れる挙動まで、攻撃ライフサイクルのステップを最大限ブロックできるように設計されています。ですが、Cortex XDRは攻撃ライフサイクルの早期段階(エクスプロイト段階など)で攻撃をブロックし、その後の感染による被害を防ぐことに重点を置いたソリューションです。たとえばLog4Shellの場合、Cortex XDRエージェントはWindows、Linux、Macシステムでエクスプロイト後の活動を阻止できますが、Linuxシステムでは先手を打ってエクスプロイトそのものをブロックすることが可能です。
本記事では、Cortex XDRとJava Deserialization Exploit Protectionモジュールを利用して、Linux環境でLog4Shellのエクスプロイトを阻止する方法を詳しく解説していきます。Windows、Linux、MacエンドポイントでのLog4Shell対策にCortex XDRがどう役立つかは、脅威インテリジェンスチーム「Unit 42」が公開したApache Log4jに関するブログ記事をご参照ください。
デシリアライズ機能のエクスプロイトとLog4Shell
Log4Shell脆弱性の発見を受け、Cortex XDRのリサーチチームはLog4Shellエクスプロイトの緩和に役立つ緊急のコンテンツ更新をエクスプロイトの発覚から48時間未満で実施しました。この記事では、Javaのエクスプロイト、Log4Shellエクスプロイトの仕組み、Cortex XDRとJava Deserializationモジュールを利用したLinuxシステムでのエクスプロイト攻撃の阻止について詳しく解説します。
シリアライズ/デシリアライズとは? RCEエクスプロイトとの関係は?
シリアライズとは、何らかのオブジェクトを後で復元可能なデータ形式に変換するプロセスを指します。しばしば、保管やデータ送信を目的とした保存の際にオブジェクトのシリアライズが行われます。
デシリアライズとはシリアライゼーションの逆のプロセスで、何らかの形式で構造化されたデータから元のオブジェクトを再構築するプロセスを指します。現在、データのシリアライズに使用される最も一般的なフォーマットはJSONです。かつてはXMLがよく使用されていました。
ただし、多くのプログラミング言語にはオブジェクトをシリアライズする機能が標準で備わっています。JSONやXMLと比べて、このような標準フォーマットはカスタマイズ性やシリアライズプロセスの面で機能が優れているのが普通です。
しかし残念ながら、信頼できないデータを操作した場合、標準のデシリアライズメカニズムの特徴を悪意ある目的に利用される可能性があります。デシリアライズ機能を悪用することで、サービス拒否(DoS)攻撃、アクセス制御、リモートコード実行(RCE)攻撃を行えることが確認されています。標準のメカニズムを利用したデシリアライズに成功すると、多くの場合攻撃者はコードを実行できるようになります。
Log4Shellエクスプロイトの仕組み
Log4Shellエクスプロイトは、ログが発行されるたびにLog4jのコードが「JNDI:[protocol]//[ip]/uri」という特定のURLパターンを探すというLog4jのログ記録フレームワークのロジックを悪用したものです。このパターンがログに記録されると、Log4jのコードがJNDIフレームワークを利用して攻撃者が管理するIPアドレス/ドメインとポートからJavaコードを読み込んでしまいます。この際、DNS、RMI、IIOP、LDAP/Sなどのプロトコルが使用されます。
このエクスプロイトは次のように進行します。
- 攻撃者が、Log4jを用いてロギングされているユーザー管理入力を探す。(これは非常に巨大な攻撃対象領域であり、事実上すべてのユーザー入力フィールドで発見できます)
- 攻撃者が悪意のあるJNDI URLを送信する。これには、ホストからルーティング可能で、攻撃者が管理するIPアドレスが記載されている。
- 指定されたプロトコルとポートを用いて攻撃者のIPアドレスにホストがリクエストを送信する。
- 読み込んで実行するJavaクラスを攻撃者のサーバーが返送する。
- Java仮想マシン(JVM)がJavaクラスを読み込み、クラスに含まれるコードを実行する。たいていの場合、リモートホスト上でプロセスが起動する。
Log4Shellエクスプロイトは、Javaのデシリアライズ機能のエクスプロイト?
厳密に言えば、Log4ShellエクスプロイトはJavaのデシリアライズ機能のエクスプロイトではありません。ただし、Javaのデシリアライズ機能のエクスプロイトで使用されるコード実行の最終段階と同じ特徴があります。最終段階で攻撃者が制御するコードをJVMに読み込んでコードを実行することから、このエクスプロイトにもJavaのデシリアライズ機能のエクスプロイトと同じメカニズムが当てはまり、同じ緩和策を適用できます。
Cortex XDRはどのようにJavaのデシリアライズ機能のエクスプロイトを阻止するか
保護対象のLinuxデバイスで新しいプロセスが作成されるたびに、JVMを使用するプロセスかどうかをCortex XDRエージェントが判定し、プロセスにJava Deserialization Exploit Protection Module (EPM)を挿入します。このモジュールはJavaランタイムのフック機能を利用してJavaの実行ランタイムを改変し、疑わしい実行パターンが無いか一部のメソッドを検査します。疑わしいメソッドが実行された場合、EPMは実行スタックトレースを調査し、実行スタックにデシリアライズされたオブジェクトのコンテキストが含まれるかどうかを確認します。含まれる場合は、モジュールが活動をブロックしてリモートコード実行を阻止します。
Java Deserialization EPM
Cortex XDR vs Javaのデシリアライズ機能のエクスプロイト
Javaのデシリアライズ機能のエクスプロイトは、典型的なパターンを満たすのが普通です。すなわち、攻撃者が送信した入力によりコードパスがメモリ上のオブジェクトのデシリアライズで終わる場合、そのコードパスはリモートコード実行のエクスプロイトに使用されている可能性があります。この場合、次の2つの動作が確実に発生します。
- デシリアライズ機能またはクラスが必ず呼び出されます。
- デシリアライズ機能により、クラスの読み込み、プロセスの実行、ファイル(通常はWebシェル)の投下のいずれかが実施されます。
Cortex XDRエージェントは実行前のデシリアライズ コード パスをフックし、その後コード実行が行われないか検証することで、リモートコード実行(RCE)につながるデシリアライズ機能のエクスプロイトを阻止します。
Cortex XDR vs Log4Shell
Log4Shellはエクスプロイトの同じ基本要素を利用します。つまり、クラスを読み込むか、ファイルを投下するか、プロセスを実行するため、この活動をブロックする上でJava Deserialization EPMが有効に働きます。
典型的なJavaのデシリアライズ機能のエクスプロイトを阻止する場合と同様、Log4Shellのエクスプロイト活動が発生すると、Java Deserialization EPMモジュールがスタックを検査します。そして、JNDI機能がスタックに存在するなら、モジュールが作動して活動をブロックします。ブロックする活動の例としては、RCEのほか、資格情報の盗難や列挙につながりかねない環境変数の漏えいがあります。
Java Deserialization EPMにより、活動中のエクスプロイトをブロックした事例を確認しています。この事例で、攻撃者はリモートホスト上で仮想通貨マイナーと探索コマンドを実行した可能性があります。しかし、ホストが最新バージョンのエージェントとコンテンツに更新されていたため、この試みはブロックされました。
まとめ
このエクスプロイトを利用する巧妙な攻撃者が増加していることから、最新バージョンのエージェントとコンテンツに更新するとともに、Log4jShellに関するUnit 42のブログ記事で紹介している緩和策を活用することを強くおすすめします。
その他の資料
Unit 42の報告: Apache Log4j脅威の最新情報
Log4j CVE-2021-44228 (Log4Shell) エクスプロイト活動の脅威ハンティング
NGFWとクラウド利用のセキュリティサービスを利用した、Apache Log4j脆弱性への対策