macOS のセキュリティ | Endpoint Security Framework (ESF)

この記事では、ESFがどのように機能するか、それが検知と対応を行うチームにもたらすメリット、そしてデータの過負荷を避けるためのエンドポイントフィルタリングの設定方法など、ESFの使用に関する一般的な問題を明らかにします。

ESFは、セキュリティニーズに対するカーネルベースソリューションとして、Appleによって開発されたMacOSのコンポーネントであり、リアルタイムのイベントに対するプロアクティブな検知と対応を提供します。その機能はWindows イベント トレーシング（ETW）とよく似ており、元々Sun Microsystemsが開発した前身のOpenBSMと比較すると、はるかに効果的なセキュリティフレームワークです。

図１：ESF検知の仕組み

図１の右上にあるダイヤグラムは、ESFの動作の概要を示しています。ESFアプリケーションはカーネル空間（緑の枠内）に位置し、ユーザーの検知目的に応じてテレメトリやイベントタイプを収集します。カーネル空間からのメッセージは、アプリケーションのユーザー空間に戻され、ユーザーの検知スタックを通じて実行されることで検知プロセスが開始されます。

左側の端末ウインドウの大きな図はイベント出力の例です。ここには、環境変数、user ID、parent process ID（PPID）、process ID、さらにバイナリが開発者の署名を確認するためCD-Hashなど、各イベントタイプにおけるさまざまなデータポイント（検知基準）が含まれています。

アップデートの後、ppleはMacOS KEXT（サードパーティベンダーからのカーネル拡張）を非推奨にし、システム拡張に置き換えることを発表しました。これ以前は、セキュリティベンダーはカーネル拡張をインストールして、監視したいテレメトリを取得し、それを検知目的で検知スタックに出力していました。カーネル拡張に替わるソリューションとしてシステム拡張を導入することで、Appleは効果的なメンテナンスとアップデートを継続することが可能なマネージドソフトウェアを提供できるようになりました。

OpenBSMに欠けていたいくつかの領域に対処する際に、AppleがESFを極めて簡単にユーザーの検知スタックに統合できるようにしたことで、当社が以前のホワイトペーパーで説明したOpenBSMに関するいくつかの問題が効果的に解決できるようになりました

図２：OpenBSMの監視の仕組み

サードパーティベンダーがカーネル拡張をカーネル空間にインストールすると、監視プログラムは、カーネル拡張にテレメトリを生成し検知スタックを通じて実行するよう要求します。OpenBSMはさまざまなログファイルをフックすることで動作し、ログファイルが読み込まれると、データはフックを介して送信され、監査するために検知システムに戻されます。

図3：新たな監視方法（ESF）

新たに改善されたプロセスでは、システム拡張はユーザー空間で動作します。AppleがKEXTを非推奨にした結果、新たに特定のフレームワークが３つ開発されました: 

• The network extension framework 

• The endpoint security framework (ESF) 

• The driver kit framework. 

Appleがカーネル空間へのアクセスを取り除く決断を促したのは、安定性とセキュリティ向上を高めるためです。サードパーティによるカーネル空間へのアクセスがセキュリティ上の懸念を引き起こすため、Appleはそのアクセスをほぼ完全に排除することでリスクを軽減したのです。また、サードパーティベンダーが不正確なメモリ割り当てをしたときによく起こる「死の黒い画面」（BSOD）も防げるので、システムの安定性が向上しました。

注：カーネル拡張は非推奨になりましたが、最新のMacシステムではまだ使用できます。ただし、システムのセキュリティプロファイルを著しく劣化させることがあるので注意が必要です。これを防ぐことは非常に難しいため、通常は開発目的のみで使われています。KEXTをシステム拡張に置き換えないベンダーは、顧客のシステムのセキュリティを脅かすことになりかねないのです。

Endpoint Security Frameworkを試行してみると、以下のような問題が発生しました: 

• メッセージキューのボトルネック問題 － 出力されたデータに一貫性がないことが実証されました。さらに分析していくと、これはカーネルのメッセージキュー内のボトルネックに起因していることが判明しました。キューが過負荷になると、ユーザーに警告することもなくデータパケットが密かに廃棄されていたのです」 

• 解決策：このボトルネックの問題に対しては、マルチクライアントシステムまたはイベントミューティングの2つの解決策が考えられます。イベントミューティングを用いると、カーネルレベルでイベントタイプをサブスクライブする際に、特定の識別子に基づいて省略するデータパケットを指定することができます。しかし、イベントミューティングは柔軟性が欠けているため、データ負荷を減らすには効果的ですが、持続可能な解決策にするために微調整することはできません。

この観点からすると、マルチクライアントシステムのほうが、はるかに現実的な解決策になります。マルチクライアントシステムでは、1つのプログラムで複数のESFクライアントが1つまたは複数のイベントタイプをサブスクライブできるからです。したがって、各クライアントは独自のメッセージキューを持つことができるので、過負荷になる可能性が非常に低くなります。

もう１つの解決策は、AppleによってMacOS 10.15（Catalina）とMacOS 10.15.4の間でSDK（ソフトウェア開発キット）が更新されたときに、es_message_tの中に“seq_num”（シーケンス番号）値が導入されたことで浮上しました。 これにより、カーネル空間からユーザー空間に発行されるメッセージに、シーケンス番号が付けられるようになりました。したがって、アナリストはシーケンス番号の食い違いに気づき、データパケットが密かに廃棄されたことを知ることができます。ユーザーに警告は発信しませんが、ユーザーは状況を監視し、それに応じて動的リバランシングを行うことで、データ過負荷を回避することができるようになります。

• システムの冗長性 － ESFを使用して新しいデータセットを処理することの難しさの1つは、システム全体のすべてのアクティビティ（一般的なメンテナンス操作）を取り込む傾向があることです。これによりデータが膨大な量に膨れ上がり、通常のシステムとプロセスにとって必須のシステムとの選別が非常に困難になります。

• 解決策：ESFユーザーが生み出すさまざまなタイプのデータをふるいにかけるため（イベントミューティングが効果的に適用されていない場合）、取得前と取得後のフィルターが適切に設定されていることを確認してください。取得前にフィルターをかける場合、ユーザーはイベントミューティングを使用する必要があります。それがカーネル側にフィルターを置く唯一の方法だからです。しかし、イベントミューティングはあまりにも広範囲に働く傾向があるため、ユーザーは一般のシステムレベルのプロセスか、個々のプロセスインスタンスのいずれかを省略しなければなりません。これはあまりにも特殊な状況で、システムレベルの全アクティビティをブロックしてしまう可能性があります。エンドポイントでシステムユーザーが侵害された場合、その侵害が見逃され、結果として重大なセキュリティリスクを引き起こす可能性があります。

• PPID実行プロセスに関連したReal Parent Process IDの問題 － MacOS環境でのクロスプロセス通信（XPC）の動作の仕方によって、Parent Process IDは通常3つのプロセス、即ち“Launchd”、 “runningboardd”（どちらもデーモン）、あるいはXPC Proxyのうちの１つに帰属します。これはMacOSに関連する評判の悪い制約だったので、“launchd” real parent ID（RPID）問題を解決しようと多くの方法が採り入れられました。しかし“runningboardd”が導入されたことで、この問題が未だに続いていることは明らかです。したがって、ESFデータを利用する場合は、PPIDデータを適切なシステムでフィルタリングしてRPIDを生成する必要が有ります。

• 解決策：どのような解決策も定期的な更新によってすぐに無効になってしまうので、これに対する持続可能な解決策はありません。それでも現時点では次のような注目すべき解決策があります。Jaron BradleyによるTrueTreeと、Patrick WardleによるlaunchdXPCです。これら２つの技術は、“launchd”とXPC Proxyに対して非常に有効であることが実証されています。ただしAppleがシステムを“runningboardd”に移行したことで、その効力は少し下がっています。

コードネームESFangは、WithSecureのシニアリサーチャーで、元脅威ハンターのConnor Morleyが開発したソリューションです。これはMacOSのEndpoint Security Frameworkに関連するいくつかの問題に対処するために設計されました。また、2019年後半のPatrick Wardle、Chris Ross、Omark-IkramによるESFの初期検知機能とデータ取り込みに関する基礎開発の成果を合わせて採り入れています。

ESFangが開発されたのは2021年初頭です（現在Countercept GitHubで公開中）プロセスイベント、FILEイベント、FILEメタデータイベント、プロセス間通信（IPC）ポート割り当てなどを始めとする52種類のイベントタイプを動的に処理できます。ESFangの主な特徴は、実行時にいつでもユーザーがどのイベントを取り込むかを選択できることで、前述のボトルネック問題を回避するのに役立ちます。

さらに、POCをマルチスレッドシステムに変更することで、ユーザーはマルチクライアントシステムを個別の取り込みとして設定することが可能になります。

ESFangには、JSON（JavaScriptのオブジェクト表記）の出力も備わっているので、利用可能なあらゆるデータベースを追加の検知スタックにシームレスに送信することができます。

Meterpreterエージェントに対するESFテレメトリ分析のユースケースは、MacOSシステム11.2.2上で実施され、イベント出力、検知を含むいくつかの機能面をテストし、ESFの前身や以前のテレメトリシステム（OpenBSMとKEXT）との比較も行いました。ESFang POCをテレメトリ取得の主要ツールとして使用し、1台のホストからの侵害後の段階だけに焦点を当て、エンドポイント上のMeterpreterエージェントの機能についてのみテストしました。

図４：ESFによるMeterpreterテレメトリの生成

４のグラフはESFのテレメトリ取得中に取り込まれたイベントタイプを表しています。実行されたアクティビティによって、ユーザーが得られる情報量は膨大になる場合と少ない場合があり、検知する際に大いに役立ちます。

図５：実施された主なイベントタイプ

Meterpreterエージェントのインストール中に、いくつかのタイプの重要なイベントが実行されました。図５に示すように、メモリ保護とreaderディレクトリが最も増加しています。しかし、悪意のある活動を特定し、適切な検知機能を構築するために必要な特異性に欠けるので、価値の高いデータポイントとは見なされません。

一方で、相互参照時のopenやFCNTL（ファイルコントロール）などのデータポイントは、ユーザーがMeterpreterエージェント専用の検知プロファイルを作成するのに役立つため、十分価値が有ります。

図５のグラフには全部で259のデータポイントがあります。しかし、量は質の指標ではありません。データが多すぎるとシステムは過負荷になり、ユーザーが他の悪意のある行動に気付かなくなるリスクがあります。それでも、高い処理能力に加え十分なデータポイントを維持することは有益です。ユーザーが高忠実度の検知プロファイルを作成するための相互参照が十分にできるからです。

図６：ESイベント通知Open（ファイル操作）

通知イベントのタイプは、ユーザーまたはプログラムによってファイルが開かれた時はいつでも生成され、通常はどのプロセスがどのファイルをいつアクセスしたかを特定します。また、悪意のある行動を検知するための大量のデータをアナリストに提供するので、ESFのファイル監視要素の最も重要な部分にもなります。

ここでは30件のオープンイベントがインストレーションによって生成されました。一方、Webカメラのストリーム（運用上のセキュリティが確保されていない）は、驚異的とも言える478件ものイベントを生成し、249件のプロセスリストがそれに続きました。

図７：ESイベント通知write（ファイル操作）

図７は既存ファイルへの書き込みのイベント操作を表しています。プロセスがファイルに書き込む時はいつでも、それが異常なプロセスまたは編集ではないプロセスからのものならば、異常な振る舞いの存在を強く示唆しています。

編集ファイルには1件だけイベントがありました。いずれにしても同じ量のデータをターゲットファイルに書き込こんでいることが予想されます。アップロードでは226件のイベントがありました。それらはすべて書き込みイベントの繰り返しで、何かをブロックで転送していることを示唆しています。

図８：ESイベント通知IOKIT open

IOKIT（入出力）は、Macシステムのハードウェアまたはドライバへアクセスするために実行されます。このケースでは、ハードウェアを使用してスクリーンシェアとWebカメラストリームの2件だけが反映されていますが、両方とも運用上のセキュリティは確保されていません。

ESFで発見される以下のようなイベントタイプは、現在見られる複数の攻撃フレームワークに対して極めて正確な検知機能を提供することができます。

Endpoint Security Frameworkは、検知および対応を目的とした強力な機能を誇っています。AppleはESFを定期的に更新し、その運用に関連して発生した問題に積極的に取り組んでいます。ユーザーがOpenBSMなどのツールを利用して、独自のカーネル拡張を開発した以前のソリューションに比べると、ESFはかなり簡単に利用することができます。データの取り込みや、そのデータをユーザーのデータ要件に合わせて適切にフォーマットする機能は比較的シンプルです。さらに、低レベルの情報でデータを出力することができるため、高忠実度の検知を可能にし、EFSの高度な検知能力をさらに強化しています。しかし、この記事で紹介したいくつかの問題点により、検知目的のプロセスで必要となるデータ量が多くなるため、カーネル空間かアプリケーション側のどちらかでエンドポイントごとのフィルタリングが不可欠になります。イベントミューティングのような解決策は柔軟性に欠けるため、成果を上げることはやや困難ですが、マルチクライアントシステムを設定すると、ESFangを実行するたびに取り込むイベントを選択できるようになるので、より高い効果が期待できます。

この記事はConnor Morleyの講演から引用しました。講演の全文はこちら.からご覧ください。