アイデンティティーベースのセグメンテーションによるApache Log4jエクスプロイトの無力化

ZscalerのTheatLabzは12月11日に、野放しの状態になっているLog4jによる攻撃の試みを観察し、脆弱性を分析したうえで、推奨される保護戦略を提唱しました。こちらとこちら(英語)のブログ記事も併せてご覧ください。この脆弱性の影響を軽減するための推奨事項の1つは、アイデンティティーを使用したアプリ間のマイクロセグメンテーションを適用することです。この記事では、初期の侵害を食い止め、侵害されたワークロードからの脅威の水平移動を阻止する上で、アイデンティティーベースのセグメンテーションが従来のファイアウォールベースのセグメンテーションよりも優れている理由を説明します。

従来のアドレスベースのセグメンテーションは、L3/L4ベースのホスト ファイアウォールのルールを使用し、通信の内容を制御しますが、通信を行うソフトウェアをIPアドレスから判断できないため、このアプローチは有効ではありません。プロトコル情報を監視するL7ファイアウォールであっても、通信を行うソフトウェアのアイデンティティーを確実に判断することはできません。例えば、Log4jサーバーが侵害されて不正コードがリモートで実行された場合、不正コードは承認されたファイアウォール ポリシーを用いてピギーバック(共連れ)を行い、環境内で水平移動を実施できるようになります。以下の攻撃シナリオでは、Phase 2(第2段階)で最終ペイロードが送信された後に、侵害されたLog4jサーバーにより、脅威の水平移動が可能となります。

画像：Fastly

アイデンティティーベースのセグメンテーションのソリューションは、エクスプロイトの防止や、その影響の抑制に役立ちます。まずは、アイデンティティーベースのセグメンテーションの仕組みについて見ていきましょう。詳細は、Zscalerのブログ記事「クラウド セキュリティの基盤であるアイデンティティーベースのマイクロセグメンテーション：スプーフィング対策」(英語)で解説されており、ここでは該当する部分を以下に抜粋します。

「アイデンティティーベースのマイクロセグメンテーションを可能にするため、デバイスやソフトウェアの各資産には、バイナリーのSHA-256ハッシュやBIOSのUUIDなどの資産そのものの数十のプロパティに基づく、不変で一意のアイデンティティーが割り当てられます。アイデンティティーはサブプロセス レベルにまで拡張されるため、個々のJava JARやPythonスクリプトも一意に識別できます。また、アイデンティティーの作成と管理は完全に自動化されているため、運用が簡素化されます。

Zscalerは、通信を行うソフトウェアのアイデンティティーをリアルタイムで検証します。このゼロトラストのアプローチにより、承認されていない不正ソフトウェアの通信を防止できます。これにより、承認されたファイアウォール ルールを使用したピギーバック攻撃は不可能となります。アイデンティティーこそが、従来のネットワーク セキュリティ管理よりもシンプルな運用と強力な保護を実現できる秘策なのです。」

上記の画像のエクスプロイトの例では、アイデンティティベースのセグメンテーションと最小権限の適用が行われていた場合、複数の防御レイヤーによって攻撃のリスクを低減することができました。仕組みは以下のとおりです。

1. 攻撃者のIPは許可されたポリシーに含まれないため、最初のインバウンド接続も許可されることはありません。インバウンド接続を受け取ったホストは、ソフトウェア アイデンティティーによって保護され、システムへの無差別なアクセスは許可されません。
2. 脆弱なサーバーから未知の外部エンティティーへのアウトバウンド通信は、ポリシーによって許可されません。これもまた、ソフトウェア アイデンティティー検証による効果です。
3. 最終ペイロードが実行された場合、他のシステムへの通信を試みる前に、通信を行う悪意のあるソフトウェアがフィンガープリンティングされるため、水平移動が許可されることはありません。まず、Zscalerのアイデンティティーベースのセグメンテーション ソリューションが、フィンガープリントをZscalerの脅威フィードと照合し、悪意があるものと報告されていた場合は管理者に通知され、ポリシーで許可されていないソフトウェアは自動的にブロックされます。その後、当該ソフトウェアによるすべての通信がブロックされ、管理者に通知されます。Zscaler ThreatLabzは、こちらの記事(英語)とZscaler Threat Libraryに記載されている、複数のエクスプロイトのシグネチャーを確認しています。ホストで動作する他の承認されたソフトウェアは、ビジネスへの影響を生じさせることなく通信を行えます。
4. 正規あるいは承認されたソフトウェアが攻撃に用いられる「Living off the land」攻撃が使用された場合、Zscalerのセグメンテーション ソリューションによって、承認されたソフトウェアの通信パターンを分析し、環境の他のシステムへの通信が最小権限アクセスのポリシー セットで許可されていない場合、その通信を阻止できます。
5. また、情報流出のいかなる試みも、アウトバウンド通信のセグメンテーション ポリシーで許可されないため、同様に阻止されます。
6. 環境がまだ攻撃されていない場合であっても、Zscaler Workload Segmentationによって、環境内で通信するすべての脆弱なLog4jシステムのインベントリーを作成できます。これは、API経由で取得され、Githubなどの公開されているハッシュと照らし合わせることができる、ソフトウェアのフィンガープリント　ハッシュを用いて行われます。
7. RandoriによるLog4jに関するブログ記事)(英語)は、「Log4jライブラリーに属するJARファイルの存在は、アプリケーションがCVE-2021-44228の影響を受ける可能性があることを示している」と指摘しています。検索する具体的なファイルは、「log4j-core-*.jar」というパターンと一致するでしょう。従来型のアプローチとは異なり、Zscaler Workload SegmentationではJavaなどだけでなく、個々のJARファイルなどのサブプロセスのレベルにまでアイデンティティーを拡張するため、通信を行うソフトウェアのきめ細かい制御が可能になります。Zscalerはさらに、主要なJARファイルのインベントリーを作成するため、管理者が環境やアプリケーションの通信トポロジーをより深く理解できるようになります。
8. そして、管理が過度に複雑であれば、いかなるセキュリティ ソリューションも有効な手段とは言えません。Zscaler Workload Segmentationでは、アイデンティティーベースのポリシーを最大90%削減しつつ、同レベルの対象範囲へのセグメンテーションを可能にすることで、ポリシーを簡素化できます。機械学習により、セグメンテーション ポリシーを自動的に推奨することで、さらなる運用の簡素化を実現します。

つまり、Zscalerのアイデンティティーベースのセグメンテーションは、ソフトウェアのアイデンティティーを検証して最小特権アクセスを適用し、既知かつ害のないアプリケーションのみに承認されたパスでの通信を許可します。アイデンティティーを使用するセグメンテーションは、アプリケーションやネットワークを変更することなく、広範な脅威からの保護を実現するのに極めて有効な手段です。このアプローチにより、ゼロトラスト セキュリティをクラウドやデータ センター環境のワークロードに容易に拡張できます。Zscalerの他のソリューションと組み合わせてゼロトラスト アーキテクチャーを使用することで、リスクと今後の脆弱性の影響を最小限に抑えることが可能となります。

今後に向けて、以下のことを行いましょう。

Workload Segmentationのカスタム デモをリクエストし、トランスフォーメーションへの第一歩を踏み出す。

インターネットの攻撃対象領域に関する無料の分析(英語)を行い、Apacheの使用に伴う外部からの攻撃対象領域を確認。

12月15日(水)開催のウェビナー(英語)で、Apacheの脆弱性の詳細について把握。