Log4j脆弱性への対応を支援、ラックが提供する製品・サービスを一挙紹介

2021年12月9日に公開されたJavaのログ出力ライブラリ「Apache Log4j」に存在する、リモートから悪用可能な脆弱性（CVE-2021-44228）について、ラックが運営するブログであるLAC WATCHの記事「【注意喚起】Log4jの脆弱性を狙う攻撃を多数検知、至急対策を！」で紹介した通り、注意喚起情報を掲載しています。

ラックが運営するセキュリティ監視サービスセンターJSOCのユーザーには、既に本件に関するオリジナルシグネチャを緊急配信するなどリスク緩和策を提供しています。本記事では、そのほかラックで扱っている各種製品・サービス等の中で、Log4jの脆弱性へ対策の一助になり得る機能に関して情報をまとめています。

また、本記事後半では、今回のように緊急性の高い脆弱性が見つかった場合の定常的な備えについてもまとめています。今回の脆弱性および今後のセキュリティ対策を検討する際に活用ください。

※ 本記事に記載の内容はラックのエンジニアによる独自調査の結果、および各ソリューション・製品開発元情報を参考としたものです。本記事記載の内容のみで、今回の脆弱性の対応が完結するものではありません。

※ このLAC WATCHで紹介している情報は2021年12月16日現在のものです。

Taniumによる対応

Taniumは、企業が利用するサーバ群・PC端末などのエンドポイントへモジュールを導入することで、平時のIT衛生管理（サイバーハイジーン）を実現できるソリューションです。

エンドポイント数が数万台の規模でも数分で現在の状況を可視化することができる上に、対象の端末に任意のコマンドを一括で実行できるのでリスク緩和策も集中的に効率良く実行することができます。ここでは、タニウム社のサイトで公開されている「Apache Log4j」の記事を引用しながら、対応内容を紹介します。

※ Taniumを活用してCVE-2021-44228 "Log4Shell"に対応する | Tanium

記事では、以下のモジュールを使用した具体的な手順やコマンドが掲載されています。

• Interact with Index（Threat ResponseまたはRevealに含まれるIndexを有効にしていることが前提です）
• Comply
• Reveal
• Threat Response

これにより、ユーザーは下記の一連の脆弱性への対処をTaniumで実行可能となります。

• 潜在的な影響範囲の調査
• 侵害の兆候の調査
• 脆弱性の緩和策の実行

続けて幾つかの具体例を紹介します。

Taniumでの調査は容易で、Log4jパッケージの有無とそのバージョン情報を取得する場合であれば、以下のようにコマンドを入力して数分待つだけで、すぐに結果が返ってきます。（サンプル画像はLog4jパッケージを保有するエンドポイントはなかったケース）

ほかにも、EDRモジュールThreat Responseを用いれば、公開されているYARAルールをインポートすることで、Apache Log4jの脆弱性を悪用しようとする振る舞いを検知できます。
脆弱性評価モジュールComplyを用いれば、24時間ごとに定義が更新される最新の脆弱性情報に基づいて自動でエンドポイントの脆弱性の状態を可視化できます。

今回のように緊急性の高い脆弱性が公開された場合は、影響を正確かつリアルタイムに把握できる手段が求められます。また早く適切に対処するためには、日頃からの非管理端末や情報資産などの可視化が不可欠です。Taniumはそれらの課題を1つの製品で解決できる有用な手段の1つと言えるでしょう。

Prisma Cloudによる対応

パロアルトネットワークス社のPrisma Cloudには、監視対象ホストやコンテナイメージにDefenderエージェントを導入することで、既知の脆弱性が含まれるコンポーネントが、そのサーバ上で利用されているかを確認できる機能があります。
この機能の利用により、Log4jshell脆弱性を含むLog4jパッケージもしくはJARファイルを保持しているかどうかを確認できます。

また、WAAS（Web-Application and API Security）機能を有効化することで、脆弱性を攻撃しようとする通信のペイロードを検出し、ブロックできます。

今回のLog4j脆弱性についても、12月13日時点でパロアルトネットワークス社からこの脆弱性を突く攻撃を検知、ブロックするためのロジックが配信済みです。そのため、WAAS機能を利用しているシステムでは、ロジックを活性化させるだけで、単純なLog4j攻撃からシステムを保護できるようになっています。

Prisma Cloudの活用については、この情報に関するパロアルトネットワークス社のページも参照ください。

※ 脅威に関する情報: Apache Log4jに新たな脆弱性(CVE-2021-44228) 実際の悪用も確認

ラックでは、Prisma Cloudを効果的に活用するためにPoC（概念実証）、本格導入、運用まで一貫して支援する「クラウドセキュリティ統制支援サービス」を提供しています。
このサービスでは、ラック独自のポリシー群や運用サービスを活用することで、ユーザーの負担を抑えながら、クラウド環境のセキュリティ対策を実現します。

AeyeScan（Quick WATCH）による対応

エーアイセキュリティラボ社が開発するSaaS型Web診断プラットフォーム「AeyeScan」では、Webアプリケーションが稼働するシステムを診断対象として、外部から検査通信を送受信することで、Webアプリケーション診断を提供しています。

今回のLog4jの脆弱性に対しても緊急のアップデートとして診断機能が追加されており、Log4jの脆弱性を内包するシステムでは下図のように検出できます。AeyeScanを活用することで、Webアプリケーション診断の実施に加えて、Log4jの脆弱性対策を施した後の「疑似攻撃による対策状況の確認」や「対策漏れの発見」など、対策後の点検を継続的に実施することが可能です。

当該脆弱性におけるAeyeScanの活用例として、「修正対応をしたが、脆弱性が本当に残存していないか診断（検査・調査）したい」といった要望に対応できることが挙げられます。

RiskIQ、Rapid7、Qualys Guardによる対応

RiskIQ社の「RiskIQ Digital Footprint」は、インターネットに公開する自社資産の発見、資産上のオープンポートや稼働中のコンポーネント情報を収集し、管理機能を提供するツールです。

公開資産の発見機能により、組織内の台帳等で管理しているシステム一覧に不安があり、「そもそも管理が行き届いていないシステム」のリスクを懸念している企業や組織に効果的です。

今回のLog4jの脆弱性自体の有無の確認はできないものの、利用コンポーネント情報からJavaフレームワークを利用するシステムや、Apacheサーバなど、脆弱となる可能性があるシステム一覧を洗い出すことができます。

RiskIQの活用例として、組織内のシステム調査～対策のフェーズに導入することで、「管理が行き届いていないシステムを含め、影響を受ける可能性のあるシステム一覧の洗い出しに有効である」ことなどが挙げられます。

Rapid7社が開発する「InsightVM」は、プラットフォーム診断（OS/ソフトウェアに対する脆弱性診断）を実施し、脆弱性の検出、管理機能を提供するツールです。今回のLog4jについても診断項目として実装済みです。エージェント形式やリモートから通信を送信してその応答で確認するリモート形式（リモートスキャン）でも検出可能です。

SambaやSSH等の認証を登録したリモートスキャン（クルデンシャルスキャン）では、rpm等のパッケージ情報を収集できますので、パッケージ情報を検索することで利用有無が確認できます。エージェントでは、jarファイル検索ができますのでファイルの存在有無が確認できます。リモートスキャンでは特定ポートの接続から、その挙動（13456ポートへのエンジン接続通信）を確認して、脆弱性の有無を確認します。リモートスキャン（認証なし）では検出精度が劣るため、パッケージが実装されているかを確認するためには、エージェントやクルデンシャルスキャンを推奨します。

※ Using InsightVM to Find Apache Log4j CVE-2021-44228

Qualys社が開発する、「Qualys Guard」は、プラットフォーム診断（OS/ソフトウェアに対する脆弱性診断）やクラウド設定診断、コンテナ診断など多数のセキュリティ製品を提供しています。今回のLog4jについてもプラットフォーム診断の製品であるVM（Vulnerability Management）/VMDR（Vulnerability Management, Detection and Response）で診断項目として実装済みです。エージェント形式やリモートから通信を送信してその応答で確認するリモート形式（リモートスキャン）でも検出可能です。

SambaやSSH等の認証を登録したリモートスキャン（クルデンシャルスキャン）では、rpm等のパッケージ情報を収集できますので、パッケージ情報を検索することで利用有無が確認できます。また、回避策がとられているかを調べるために、LOG4J_FORMAT_MSG_NO_LOOKUPS等の確認もできます。リモートスキャン（認証なし）では検出精度が劣るため、パッケージが実装されているかを確認するためには、エージェントやクルデンシャルスキャンを推奨します。

※ CVE-2021-44228: Apache Log4j2 Zero-Day Exploited in the Wild (Log4Shell)

ラックでは、上記のQualys、Rapid7のツールを「セキュリティ診断内製化支援サービス」として提供しております。

Splunkによる対応

Splunkは、多数の情報システムから出力されるログを取り込み、高度な分析や調査を行うためのマシンデータ統合プラットフォームです。
Splunkを使用すると以下のことができます。

• A）Log4j リモートコード実行攻撃の特徴から、自環境への攻撃有無を判別
• B）Microsoft Defender for EndpointやCrowdStrikeのログから、Log4jに関するプロセスを実行しているホストを検出
• C）Sysmonのログから、Log4jに関するプロセスを実行しているホストを検出
• D）GitHubのプロジェクトの内、CVE-2021-44228用のセキュリティパッチをあてる必要があるものを特定

A）Log4j リモートコード実行攻撃の特徴から、自環境への攻撃有無を判別

攻撃有無の判別は1つのステップで構成されます。ステップ1では、攻撃用のスキャンの有無を検出します。
攻撃用のスキャンは、全てではありませんがその多くが、user agentフィールドに「${jndi:」を含む痕跡が残ります。

ステップ1のSPL（コマンド）例

index=* source=* sourcetype=* http_user_agent=${jndi:*}
| stats sparkline values(http_user_agent) by dest_ip

SPL例の補足

• index、source、sourcetypeは汎用的に全て(*)と指定していますが、検索効率を向上のために「Log4j」に関係したログに絞ることを推奨します。
• 検知漏れを防ぐことを優先する場合は、「http_user_agent=${jndi:*}」を「${jndi:*}」に変更してください。非構造化データに対してワイルドカードを使用した検索を行う場合、Splunkのサーバリソースを通常よりも多く消費することに注意してください。

ステップ2では、ステップ1で抽出したログの一部をデコードして、実行されたコマンドからスキャンのみであったか、攻撃が実行されたかを判別します。

ステップ2のSPL（コマンド）例

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

SPL例の補足

• XXXには、ステップ1で抽出した「values(http_user_agent)」の値を設定してください。
• cyberchefコマンドを使用するためには、「CyberChef for Splunk App」をインストールする必要があります。
• 例では「/Base64/」の後の文字列をデコード対象にしていますが、攻撃が巧妙化した場合、rexコマンドをチューニングする必要があります。

B）Microsoft Defender for EndpointやCrowdStrikeのログから、Log4jに関するプロセスを実行しているホストを検出

SPL（コマンド）例

| 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

SPL例の補足

• Endpointデータモデルの高速化を有効にしていない場合は、「summariesonly=t」を「summariesonly=f」に変更してください。
• Microsoft Defender for EndpointやCrowdStrikeは、Common Information Model（CIM）に準拠しているため、上記SPLを1度実行すれば、それぞれの検出が可能です。

C）Sysmonのログから、Log4jに関するプロセスを実行しているホストを検出

SPL（コマンド）例

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

SPL例の補足

• indexは汎用的に全て(*)と指定していますが、検索効率を向上のために適切に絞ることを推奨します。

D）GitHubのプロジェクトの内、CVE-2021-44228用のセキュリティパッチをあてる必要があるものを特定

SPL（コマンド）例

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

SPL例の補足

• indexは汎用的に全て(*)と指定していますが、検索効率を向上のために適切に絞ることを推奨します。
• 当コマンドを実行するには、GitHubのauditログを収集／正規化するため、「GitHub Audit Log Monitoring Add-On for Splunk」と「GitHub App for Splunk」をインストールする必要があります。

Snyk OSSによる対応

Snyk Open Source（以下、Snyk OSS）はSnyk社が開発している、オープンソースのコンポーネントのセキュリティ管理を自動化するツールです。Snyk OSSを使うと、以下の事ができるようになります。

※ Snyk | Developer security | Develop fast. Stay secure.

• アプリケーションが利用しているコンポーネントとバージョンの把握
• コンポーネントの脆弱性情報を把握し、対応の優先順位を付ける
• コンポーネントをアップデートするプルリクエストを作成し対応を効率化
• これらのコンポーネントの運用管理（モニタリング）を自動化

SnykにはSnyk OSSの他にも、開発中のコードの脆弱性を指摘してくれる「Snyk Code」、コンテナイメージの脆弱性管理の「Snyk Container」、TerraformなどのInfrastructure as Codeの設定ファイルの問題点を指摘してくれる「Snyk IaC」などがあります。これらのWebアプリケーション開発・運用局面で気を付けておきたいセキュリティ問題にオールインワンで対応できるのもSnykの魅力の一つです。またVisualStudioCodeやGitHubなど開発者に馴染みのあるツールとの連携もスムーズで、とても開発者フレンドリーなプロダクトになっています。

Snyk OSSでWebアプリケーションのプロジェクトを登録・検査することで、脆弱性のあるコンポーネントの検出から修正までを効率よく行うことができます。Snyk OSSでLog4jの脆弱性（CVE-2021-44228）のあるアプリケーションを検査すると、以下のように検出されます。

「脆弱で古くなったコンポーネント」の脅威は、OWASP Top10 2021年版で第6位にランクインしています。Webアプリケーションが利用している多数のコンポーネントを把握して、脆弱性情報を収集し、適切なタイミングでパッチを適用したりバージョンアップしたりすることはとても大変ですが、Snyk OSSを使うことで省力化することができます。

緊急性の高い脆弱性に柔軟に対応できる強固な企業へ

今回のLog4j脆弱性のように緊急性の高い脆弱性情報に直面した時、CIOやCISOが経営としての的確な判断を下すためには、以下の観点が必要です。

1. 正確かつリアルタイム性のある情報資産とアプリケーション利用状況、そして脆弱性情報の可視化
2. 脆弱性を検知した際の攻撃状況・被害状況の把握
3. 脆弱性を潰しこむための対策と対策結果の確認

1.については、脆弱性が発表された際に自組織の情報資産への影響範囲の調査には多くのリソースと時間を費やすケースが多いのではないでしょうか。影響調査の時間を短縮し調査の漏れを防止するために、正確かつリアルタイム性のある情報資産の可視化、そしてその状況を踏まえた平時のリスク管理を行うことが望ましいと考えます。

2.については、自組織の情報資産・アプリケーションに脆弱性があった場合に、攻撃を受けていないか、攻撃による被害が生じていないかを早期に明らかにするための仕組み・手法を保持しておくことが必要です。考えられる攻撃パターンに対して、各種ログから攻撃状況を明らかにし、アプリケーションへの影響を確認するなどの対応が有効です。

3.については、脆弱性に対し早期に暫定的あるいは恒久的に対策を行ったのちに、対策が有効に働いているかを確認する仕組みが必要です。ラックでも提供している各種診断サービスを活用するほか、自組織内で診断機能を内製対応できるよう「診断内製化」に取り組んでおくことも有効策となります。

本記事にて紹介している各種製品・サービスをはじめとして、ラックではさまざまな製品・サービスによりこれらの課題への対策を提供することが可能です。

今回のような緊急性の高い脆弱性に柔軟に対応できる企業になるため、ぜひラックにお声掛けください。