Google Cloud の推奨する Apache「Log4j 2」の脆弱性の調査と対応

編集者注: この記事は、2021 年 12 月 28 日午後 4 時 23 分（太平洋標準時）に更新されました。

この投稿では、Google サイバーセキュリティ対応チームからの提言と、Apache の「Log4j 2」脆弱性 （CVE-2021-44228、CVE-2021-45046）のリスクを管理するために、セキュリティ チームが利用できる Google Cloud および Chronicle のソリューションについて説明します。

この脆弱性による Google Cloud の製品およびサービスに対する影響についての最新情報は、Google Cloud のセキュリティ アドバイザリ ページをご覧ください。

背景

Apache Log4j 2 ユーティリティは、オープンソースの Apache フレームワークで、リクエストのロギングによく使われるコンポーネントです。2021 年 12 月 9 日に、Apache Log4j のバージョン 2.15 以下を実行しているシステムに脆弱性があり、攻撃者が脆弱なサーバー上で任意のコードを実行できる可能性があることが報告されました。2021 年 12 月 10 日、NIST は、これを CVE-2021-44228 とする重要な CVE を National Vulnerability Database に公開しました。公式の CVSS ベースの重大度スコアは、重大度 10 と決定されました。Log4j 2 を含む環境を管理しているお客様には、最新のバージョンにアップデートするか、この投稿に記載されている緩和対策を講じることを強くおすすめします。サイバーセキュリティ インフラストラクチャ セキュリティ庁（CISA）はこの脆弱性に関して、すぐに対応するための追加の推奨事項を発表しました。

詳細な技術情報

「Log4j 2 の脆弱性」は、特別に細工したログメッセージを Log4j 2 に送信することで悪用される可能性があります。これは、Java アプリケーションがディレクトリ サービス（LDAP など）からデータを取得できるようにするために、Java SE Platform にデフォルトで搭載されている Java の抽象化レイヤである Java Naming and Directory Interface（JNDI）を利用して行います。JNDI は、特定のディレクトリ サービスに解決するために HTTP URI を使用します。必要に応じて URI を調整し、正しいディレクトリの場所で解決できます。Log4j 2 を使用している場合、特別に細工された URI でログ メッセージを送信する攻撃者は、アプリケーションに任意のコードを実行できます（パスに Base64 でエンコードされたスクリプトを提供するなど）。

これは、ログに変数データの入力を可能にする Log4j 2 の特定の動作によるものです（ルックアップと呼ばれます）。ルックアップでは、ログに入力するためにリファレンスを照会し、評価します。この機能を悪用すると、攻撃者は、入力された URI を使用して、入力されたオブジェクト（エンコードされたスクリプトなど）を解決するように Log4j 2 に指示します。この問題は、Log4j 2 の最新バージョンで解決されました。

識別、検出、保護のための最新情報と推奨事項

お客様におかれましては、できるだけ早く Log4j 2 の最新バージョンへのアップグレードをお願いいたします。この行動をとること（および Apache Foundation からの追加アドバイスに従うこと）が、当面の最善の行動です。

Google Cloud Marketplace と Google Workspace をご利用のお客様は、お客様のデータにアクセスするサードパーティのアプリケーションおよびソリューションをすべて確認し、各ベンダーとともにそれらのアプリケーションおよびソリューションのセキュリティの状態を検証することを強くおすすめします。

Log4j 2 のアップデートに加えて、いくつかの Google Cloud Security のプロダクトでは、パッチが適用されるまでの間、悪用を検出して一時的に緩和できます。また、Google Cloud にサードパーティの WAF、IDS/IPS、NDR ソリューションを導入している場合は、この脆弱性に関する詳細なガイダンスをベンダーに問い合わせてください。

影響を受ける可能性のあるシステムを特定するためには、脆弱性スキャナの使用を推奨します。これらのツールは、National Vulnerability Database（NVD）で参照されている脆弱性を特定することが報告されており、影響を受けるシステムを特定するのに役立ちます。

可能であれば、以下の項目をすべて実施して、階層構造の多層防御戦略をとることをおすすめします。

Cloud Armor WAF Log4j 2 検出およびブロックルール

Log4j 2 と比較して、Cloud Armor は、外部の HTTP(S) ロードバランサの背後にあるアプリケーションやサービスに対する脅威を軽減します。Cloud Armor を有効にするには、Cloud Console > ネットワーク セキュリティ、または API 経由で行います。Cloud Armor の WAF ルールは、リクエストを検知する、または検知してブロックするように構成できます。Cloud Armor をご利用中のお客様は、事前構成された新しい WAF ルールをデプロイできます。このルールは、お客様がシステムにパッチを適用している間に、CVE-2021-44228 と CVE-2021-45046 の一般的な悪用を検出し、オプションでブロックできます。Cloud Armor による Apache Log4j 2 の脆弱性への対応については、こちらのブログ記事をご覧ください。

オンデマンド スキャンによる、脆弱性のある Log4j 2 の検知

Google Cloud のオンデマンド スキャンに搭載されている Java スキャン機能を使えば、脆弱性の影響を受ける Log4j のバージョンを使用している Linux ベースのコンテナ イメージを特定できます。 Google Cloud をご利用中のお客様は、オンデマンド スキャンを 2022 年 1 月まで無料でご利用いただけます。CI / CD プロセスの早期段階で脆弱性のあるイメージを検知することで、本番環境にデプロイされるのを防ぐことができます。ローカルや Artifact Registry または Google Container Registry に保存されているコンテナ イメージにこの機能を利用するには、Java パッケージの脆弱性のスキャンガイドの指示に従ってください。スキャンの結果が返されると、Grep 機能、テキスト エディタ、独自のスクリプトを使って「CVE-2021-44228」というテキストを検索します。スキャン結果で報告されるスコアは、CVSS バージョン 2.0 に基づいています。結果にこの CVE が一切含まれていなかった場合、オンデマンド スキャンでは、影響を受けるパッケージが見つからなかったということです。

脆弱性のあるイメージを示す出力

オンデマンド スキャンで得られる結果は、オープンソースである Grafeas 標準による形式になっているので、Artifact Registry や Google Container Registry での脆弱性スキャンと同じ方法で解析できます。つまり、Grafeas 形式を利用する既存のあらゆるツールをオンデマンド スキャンと併用できます。

Binary Authorization のデプロイ ルール

Kubernetes Engine、CloudRun、Anthos clusters on VMware をご利用の場合、Binary Authorization（BinAuthz）により、特定の既知の脆弱性（Log4j など）があるパッケージがデプロイされるのを防ぐデプロイ ポリシーを強制的に適用できます。

Google Container Registry や Artifact Registry の脆弱性スキャン機能を使用すれば、CI / CD パイプラインに Log4j の脆弱性を含まないイメージのみに署名するステップを追加できます。そのうえで、適切な署名のないデプロイはすべてブロックするように BinAuthz ポリシーを構成します。脆弱性に基づくデプロイの強制適用を設定する詳しい手順については、こちらをご覧ください。

BinAuthz ポリシーへの違反（このケースでは、脆弱性のあるコードをデプロイしようとしてブロックされる）は、Cloud Audit Logs（ガイド）に記録され、その後の修復に活かすことができます。

Chronicle

脅威の探査ツールや調査ツールは、過去のデータを見て悪用が試みられたかどうかを判断したり、アクティブな悪用をモニタリングするための手段として使用できます。  Chronicle は、クラウドとオンプレミスにまたがる拡張機能イベント コレクション（EDR ログ、ファイアウォール ログなど）を提供する Google の脅威の探査ツールです。Chronicle をログの取り込みと SIEM に使用しており、過去のイベントデータが保存されている場合（Chronicle はデフォルトで 12 か月分のデータを保持します）、過去の悪用の試みを検索できます。お客様は、Log4j 2 を悪用する可能性のあるパターンに対応する、HTTP リクエストから生成された「jndi」とそれに続く「ldap」、「rmi」、「ldaps」、「dns」を含む文字列の組み合わせを含むイベントを検索する必要があります。

たとえば、Yara-L のルールでは次のような構文が使われます。

Chronicle をご利用のお客様は、外部通信イベントを見て、影響を受けたシステムがリモートコードを実行しようとしていることを示す可能性のある低頻度の送信先を探すこともできます。詳細は、こちらの Chronicle ドキュメントと、Chronicle に関する詳しいブログ記事をご覧ください。

Cloud IDS のネットワークベースの脅威検知

Cloud IDS がアップデートされ、一般的なタイプの Log4j の悪用の試みを検出できるようになりました。これらの新しい検知機能は、Cloud IDS の既存または新規に追加されたデプロイでは、デフォルトでオンになっています。ポジティブの検出は、Cloud IDS のアラートログに表示され、Cloud Console の Cloud IDS UI では簡潔モードで、Cloud Logging では詳細モードで表示されます。または API によって表示されます。Cloud IDS の有効化と構成は、Cloud Console > ネットワーク セキュリティ、または API 経由で行います。今回問題となっている CVE に関連する IDS について詳しくは、こちらのブログをご覧ください。

Security Command Center Premium

Security Command Center（SCC）Premium をご利用のお客様向けに、Log4j の脆弱性の悪用に関係がある既知の悪意のあるサイトに対する DNS 呼び出しを検知するアクティブ スキャン機能をリリースしました。このアクティブ スキャン機能を利用するには、（1）Web Security Scanner、Event Threat Detection、Cloud DNS のログを有効化し、（2）脆弱性のある可能性のあるリソースをスキャンするのに必要な権限を Web Security Scanner に付与します。Web Security Scanner の構成について詳しくは、こちらをご覧ください。  

また、Event Threat Detection（ETD）で、マルウェア: 不正 IP およびマルウェア: 不正ドメインの一部として、インバウンドの悪用の試みや不正利用の兆候を検出できるようにする受動的な検出ルールをリリースしました。これらのルールは、デフォルトで有効になっています。

GKE をご利用のお客様向けには、SCC の Container Threat Detection モジュールで、追加されたバイナリ、ライブラリ、悪意のある bash スクリプトの実行を検知し、防御側にさらなる分析情報を提供します。組織全体で ETD および Container Threat Detection を有効化することをおすすめします。

Cloud Audit Logs の管理アクティビティ ログは、デフォルトで有効になっており、SCC の脅威検知に利用されます。ETD が異常なネットワーク アクティビティを検知するには、Cloud Load Balancing、Cloud DNS、VPC フローログなど追加のログを有効化する必要があります。こちらのページで、ETD のロギングの構成に関する追加情報をご覧いただけます。

Cloud Logging

ログ エクスプローラを使用して、Log4j 2 の脆弱性を悪用したサービスへの潜在的な攻撃を検出できます。Cloud Logging を使ってサービスへのリクエストを記録している場合、ユーザーが生成したコンテンツを含む httpRequest フィールドをチェックして、${jndi:ldap:// のような文字列トークンを持つ潜在的な悪用を探すことができます。  

この脆弱性がどのように利用されているかについては、複数のバリエーションがあり、検出されないように Unicode や Escape を利用する方法もたくさんあります。ここでは、一般的な悪用を検出するために、regex クエリを使用する方法を紹介します。

上記のクエリは、HTTP ロードバランサのリクエストログにある「${jndi:」という文字列の難読化されたバリエーションの多くに一致します。resource.type を変更することで、同様の正規表現を使って他のサービスのリクエストログをスキャンできます。大量のログをスキャンしている場合は、クエリの完了に時間がかかることがあります。クエリの実行を高速化するために、インデックス付きフィールドを利用します。インデックス付きフィールドには resource.type、resource.labels、logName などがあり、特定のサービスやログストリームのセットにクエリを絞り込めます。

一致するログエントリが検出されても、それが不正アクセスが成功したことを示すわけではありません。これは、誰かがお客様のプロジェクトまたはワークロード内の脆弱性を悪用しようと探っていることを示しているかもしれません。また、アプリケーションが HTTP リクエスト フィールドに「${jndi:」のようなパターンを使用している場合、誤検知の可能性があります。

Cloud Logging のクエリの結果には、すでに Cloud Logging に取り込まれていて、ユーザーが指定した保持期限内のログのみが含まれます。ほとんどの Google Cloud サービスでは、デフォルトでログが有効になっていますが、無効になっていたり、除外されているログは、この検索に含まれません。HTTP(S) ロードバランサを使用している場合、Cloud Logging でリクエストログを利用するためには、ロギングを有効にする必要があります。同様に、VM 上で Apache や NGINX などのウェブサーバーを稼働させていても、Logging エージェントをインストールしていなければ、それらのログは Cloud Logging ではアクセスできません。

このようなユースケースでの Cloud Logging の使用方法について詳しくは、こちらをご覧ください。

Apigee

Apigee は、API を介して log4j 2 の悪用の試みを検出してブロックするツールを提供します。潜在的な攻撃を検知するには、API アナリティクスのカスタム レポートを活用します。Edge API Analytics は、API プロキシを通過するトラフィックのメタデータを収集します。レポートを見れば、悪用の試みを示す分析レコードのパターンがわかります。レコードのパターンが一致したからと言って、侵害が成功したことを意味するわけではありませんが、何者かが API を介して脆弱性を悪用しようとしている可能性はあります。このレポートの構成方法についての詳しい説明は、こちらをご覧ください。Apigee が管理する API を介した log4j 2 の悪用の試みをブロックするには、Raise Fault ポリシーと既知の攻撃パターンに一致する適切な正規表現を活用します。正規表現とペイロードのロケーションは構成可能であり、徐々に情報が明らかになっていくのに応じて構成を調整できます。この新しいポリシーの構成方法についての詳しい説明は、こちらをご覧ください。

新規のデプロイに脆弱性のあるコードが含まれるのを防ぐためのその他のオプション

脆弱性のあるコードを検知できれば、本番環境に新たにデプロイされて問題になる前に Log4j の影響を軽減できる可能性があります。Google は、OSS-Fuzz の一環として Log4j 向けのファジングを提供するため、Code Intelligence と提携しています。Code Intelligence はまた、同社のJazzer ファジング エンジン をリモートの JNDI lookup を検知できるように改良しました。詳しくは、こちらのブログをご覧ください。

オープンソースの対処方法

オープンソース コミュニティには、依存関係の自動更新を有効化してセキュリティを向上させ、Log4j の脆弱性の影響を受けるパッケージの修正に取り組み続けるようお願いします。アーティファクトの Log4j への依存は、ほとんどが間接的なものです。脆弱性が依存関係の深いところにあるほど、修正に必要な手順は増えます。依存関係の改善が認められた場合、Secure Open Source Rewards プログラムから報奨金を受け取れることがあります。パッケージの依存関係とその脆弱性については、Open Source Insights を使用して確認できます。エコシステムへの影響に関する Google の分析と、維持者が取りうる措置について詳しくは、こちらのブログをご覧ください。

今後もこのイベントを積極的にモニタリングし、関連する緩和策や検出メカニズムについてこのブログ投稿で述べている内容の最新情報をお伝えしていく予定です。Google Cloud のセキュリティ評価に関する最新情報は、セキュリティ アドバイザリ ページをご覧ください。

- Google サイバーセキュリティ対応チーム