IT セキュリティの専門家は、BSI が危険警告レベルを宣言した log4j のセキュリティ ギャップについてコメントしています。 Barracuda Networks、Radar Cyber Security、ForeNova の専門家が状況の評価を提供します。
Jonathan Tanner 氏、Barracuda Networks 上級セキュリティ研究者
バラクーダネットワークスの上級セキュリティ研究員であるジョナサン・タナー氏: 「この脆弱性によりリモートでコードが実行されるため、リスクは非常に高くなります。」 (画像: バラクーダネットワークス)。
企業は自社のテクノロジーのこの脆弱性をどのように特定すればよいのでしょうか?また、修正されなかった場合のリスクは何でしょうか?
「まず、依存関係にもある 4 より前のバージョンの log2.15.0j が使用されているかどうかを確認する必要があります。 Maven と Gradle (どちらも Java ベースのビルド管理ツール) は、プロジェクトの依存関係ツリー全体を出力する機能を提供します。 このようにして、log4j の脆弱なバージョンが使用されているかどうかを判断できます。 バージョン 2.15.0 以降でも、formatMsgNoLookups システム プロパティが「true」に設定されていないことを確認してください。
このバージョンに脆弱性がない唯一の理由は、デフォルト値が true から false に設定されているためです。 log4j の一部のバージョンでは、このプロパティを手動で簡単に false に設定して、脆弱性を軽減できます。 アプリケーションが正当な使用の一部として LDAP を必要としない場合は、ファイアウォールまたは Web アプリケーション フィルターを使用してすべての LDAP トラフィックをブロックし、脆弱性が悪用された場合にリモート コードにアクセスできないようにすることもできます。
ただし、これらは log4j がこの RCE 脆弱性を悪用できるかどうかをチェックするだけです。 システムが攻撃に対して本当に脆弱かどうかは、HeartBleed のような脆弱性のような XNUMX 回のテストがなければ、はるかに複雑な問題になります。 この脆弱性を悪用するには、攻撃者はログインジェクション攻撃を実行する必要があります。 これらを見つけるのは非常に複雑なプロセスですが、基本的に、ユーザー (または潜在的な攻撃者) の入力が記録されている場所はすべて、この攻撃に対して脆弱になる可能性があります。
そのため、実際の RCE をテストするには、ユーザー コンテキスト自体からのログ内で JNDI LDAP リクエストを作成する方法を見つける必要があります (たとえば、影響を受ける可能性のあるアプリケーションが Web アプリケーションの場合は、Web サイトまたは API 経由)。 この脆弱性によりリモートでコードが実行されるため、リスクは非常に高くなります。 攻撃者がネットワークに侵入し、そこから重要なリソースやデータにアクセスしようとする可能性があります。」
この脆弱性においてオープンソースはどのような役割を果たしましたか?また、log4j などのツールを使用する組織にとってセキュリティに関する最優先の考慮事項は何ですか?
「log4j は非常に人気のあるオープンソース ライブラリであるため、脆弱なアプリケーションの数は確かに多かったです。 一般に、どのソフトウェアも攻撃に対して脆弱である可能性があり、人気のあるオープンソース ソフトウェアには、セキュリティ上の脅威を探して修正する大規模なエコシステムが組み込まれていることがよくあります。 重大な脆弱性が見つかったとき、オープンソース ソフトウェアが見出しのほとんどを占めますが、それは比例して安全性が低いという意味ではありません (実際、おそらく独自のコードやあまり人気のないライブラリよりもはるかに安全です)。 広範囲に配布すると、脆弱性が見つかる可能性が高まるだけであり、必ずしも脆弱性が存在する可能性が高まるわけではありません。
オープンソース ライブラリを探す場合、企業は上記の理由から、log4j のような大規模で評判が良く、よく管理されているプロジェクトを選択する必要があります。 もちろん依然として脆弱性が存在する可能性はありますが、小規模なプロジェクトに比べて、コミュニティはそれらの脆弱性を見つけてパッチを適用する可能性が高く、そもそも脆弱性の原因となる可能性のあるバグがコードにないことも検証します。
アプリケーションが CVE-2021-44228 に対して脆弱ではない人、またはログ記録に log4j をまったく使用していない人にとっても、この脆弱性は間違いなく、ログ インジェクションが攻撃者に使用される可能性がある方法であるという警鐘です。 どのようなログ システムやプログラミング言語が使用されているかに関係なく、ログに記録されるすべてのユーザー入力が各アプリケーションで適切にサニタイズされていることを確認することは価値があります。 他の形式のインジェクションの方がはるかに一般的であり、注目を集めていますが、ログ インジェクションは依然としてインジェクション攻撃の一形式であるため、OWASP トップ 10 の脆弱性に該当します。」
企業は自社のテクノロジーのこの脆弱性をどのように特定すればよいのでしょうか?また、修正されなかった場合のリスクは何でしょうか?
「まず、依存関係でも 4 より前のバージョンの log2.15.0j が使用されているかどうかを確認する必要があります。 Maven と Gradle (どちらも Java ベースのビルド管理ツール) は、プロジェクトの依存関係ツリー全体を出力する機能を提供します。 このようにして、log4j の脆弱なバージョンが使用されているかどうかを判断できます。 バージョン 2.15.0 以降でも、formatMsgNoLookups システム プロパティが「true」に設定されていないことを確認してください。 このバージョンに脆弱性がない唯一の理由は、デフォルト値が true から false に設定されているためです。
log4j の一部のバージョンでは、このプロパティを手動で簡単に false に設定して、脆弱性を軽減できます。 アプリケーションが正当な使用の一部として LDAP を必要としない場合は、ファイアウォールまたは Web アプリケーション フィルターを使用してすべての LDAP トラフィックをブロックし、脆弱性が悪用された場合にリモート コードにアクセスできないようにすることもできます。 ただし、これらは log4j がこの RCE 脆弱性を悪用できるかどうかをチェックするだけです。 システムが攻撃に対して本当に脆弱かどうかは、HeartBleed のような脆弱性のような XNUMX 回のテストがなければ、はるかに複雑な問題になります。
この脆弱性を悪用するには、攻撃者はログインジェクション攻撃を実行する必要があります。 これらを見つけるのは非常に複雑なプロセスですが、基本的に、ユーザー (または潜在的な攻撃者) の入力が記録されている場所はすべて、この攻撃に対して脆弱になる可能性があります。 そのため、実際の RCE をテストするには、ユーザー コンテキスト自体からのログ内で JNDI LDAP リクエストを作成する方法を見つける必要があります (たとえば、影響を受ける可能性のあるアプリケーションが Web アプリケーションの場合は、Web サイトまたは API 経由)。
この脆弱性によりリモートでコードが実行される可能性があるため、脆弱性が発生した場合のリスクは非常に高くなります。 攻撃者がネットワークに侵入し、そこから重要なリソースやデータにアクセスしようとする可能性があります。」
詳細は Barracuda.com をご覧ください
Lothar Haensler 氏、Radar Cyber Security 最高執行責任者（COO）
Radar Cyber Security の COO、ローター・ヘンスラー氏: 「この脆弱性は比較的簡単に悪用でき、攻撃は簡単に隠蔽できます。」 (画像: Radar Cyber Security)。
とにかく何が起こったのか
「先週末、Apache.org の log4j2 モジュールの脆弱性が発見され、すぐに最高の重大度レベルである CVSS スコア 10 が割り当てられました。 連邦情報セキュリティ局（BSI）などの当局は、当初オレンジ色だったリスク評価をすぐに赤に引き上げた。」
この脆弱性はなぜ特別なのでしょうか?
「この脆弱性は比較的簡単に悪用でき、攻撃は簡単に隠蔽（難読化）できます。 さらに、防御策を実行するのは簡単ではありません。 その理由の XNUMX つは、すべての緩和戦略が、脆弱性の影響を受けるアプリケーションにリスクと副作用をもたらす可能性があることです。 「しかし、専門家グループの評価は非常に動的です。その結果、緩和戦略についても異なる視点が存在します。」
Radar Cyber Security は具体的に何を行ったのでしょうか?
「週末にかけて、私たちはまずインシデント対応でデータ状況を分析し、その影響を推定し、コンピューター緊急対応チーム (CERT) などの国際プラットフォームからのさまざまな情報源を利用して、この脅威に対処するための戦略を設計しました。 最後に、月曜日の朝、すべてのお客様にセキュリティ勧告を送信しました。 当社のサイバー防御センター (CDC) は厳戒モードに設定されています。
現在は、全体的なセキュリティ体制を無視することなく、log4j2 モジュールでの脆弱性の発生に特別な注意を払っています。 この脆弱性の悪用を検証し、お客様に報告するために、検出モジュールを更新しました。 これは、脆弱性管理から従来の SIEM サービス、個々のネットワーク分析ツールに至るまで多岐にわたります。 同時に、自社システムの分析も開始しました。 最初の顧客での最初のスキャン後、非常に短い時間内に XNUMX つの重大なインシデントが特定されました。 他の特別なサービスでは、顧客がこの脆弱性によって具体的に影響を受けるかどうかを分析します。 極端な場合には、システムをシャットダウンする必要があるかもしれません。」
詳細は RadarCS.com をご覧ください
Paul Smith 氏、ForeNova プロフェッショナル サービス ディレクター
ForeNova のプロフェッショナル サービス ディレクター、Paul Smit 氏: 「log4j のゼロデイ脆弱性は、悪意のあるコードを明示的にリロードせずに直接悪用できるため、非常に危険です。」 (画像: ForeNova)。
「広く使用されている log4j Java ライブラリのゼロデイ脆弱性は、悪意のあるコードを明示的にリロードすることなく直接悪用される可能性があるため、非常に危険です。 ただし、それがすぐに起こるかどうかは、手遅れになって初めてわかります。 エンドポイントが侵害される可能性がありますが、まだハッカーの目には入っていません。 現在、中小企業はネットワークの検知と対応、エンドポイントの検知と対応を総合的な防御戦略として一緒に考える必要性が顕在化しつつあります。 EDR はマルウェアがインストールされているかどうかを確認し、エンドポイントでの防御を組織します。
NDR で過去を見る
NDR を使用すると、ハッカーが外部からどのシステムにアクセスしようとしたかをログ データで遡って確認することもできます。 NDR では、C2C サーバーとの通信、ポート スキャン、特定のトラフィックなど、そのようなアクセス試行から生じる一般的なトラフィックも認識します。 NDR では、ネットワークのブロックとセグメント化、またはシステムの隔離も可能です。これは、疑わしい場合に講じる必要がある措置です。 NovaComand のような NDR ソリューションは、エンドポイントからのテレメトリ データも分析します。 NovaCommand はパッチをリリースし、そのような攻撃を検出するためのルールを更新しました。 NovaCommand は、他のサードパーティ ソリューションもトリガーして、影響を受けるシステムとネットワーク セクションをブロックしてセグメント化します。」
詳しくは ForeNova.com をご覧ください
トピックに関連する記事