macOS でプロセスとカーネル拡張機能を保護する方法

こんにちは、ハブル！ 今日は、macOS で攻撃者による攻撃からプロセスを保護する方法について話したいと思います。 たとえば、特に macOS ではプロセスを「強制終了」する方法がいくつかあるため、これはウイルス対策システムやバックアップ システムに役立ちます。 これとカット中の保護方法についてお読みください。

プロセスを「強制終了」する古典的な方法

プロセスを「強制終了」するよく知られた方法は、プロセスに SIGKILL シグナルを送信することです。 bash を使用すると、標準の「kill -SIGKILL PID」または「pkill -9 NAME」を呼び出して kill できます。 「kill」コマンドは UNIX の時代から知られており、macOS だけでなく他の UNIX 系システムでも使用できます。

UNIX 系システムと同様に、macOS では SIGKILL と SIGSTOP の XNUMX つを除くプロセスへのシグナルをインターセプトできます。 この記事では、プロセスを強制終了させるシグナルとしての SIGKILL シグナルに主に焦点を当てます。

macOSの仕様

macOS では、XNU カーネルの kill システム コールは pssignal(SIGKILL,...) 関数を呼び出します。 ユーザー空間内の他のユーザー アクションが pssignal 関数によって呼び出せるかどうかを見てみましょう。 カーネルの内部メカニズムにある pssignal 関数への呼び出しを取り除きましょう (重要ではないかもしれませんが、それらは別の記事に残しておきます 🙂 - 署名検証、メモリ エラー、終了/終了処理、ファイル保護違反など) 。

関数と対応するシステムコールからレビューを始めましょう ペイロード付き終了。 従来の Kill コールに加えて、BSD にはない macOS オペレーティング システムに固有の代替アプローチがあることがわかります。 両方のシステム コールの動作原理も同様です。 これらはカーネル関数 psignal への直接呼び出しです。 また、プロセスを強制終了する前に、プロセスが別のプロセスにシグナルを送信できるかどうかの「cansignal」チェックが実行されることにも注意してください。システムは、たとえば、アプリケーションがシステム プロセスを強制終了することを許可しません。

static int
terminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,
				uint64_t reason_code, user_addr_t payload, uint32_t payload_size,
				user_addr_t reason_string, uint64_t reason_flags)
{
...
	target_proc = proc_find(target_pid);
...
	if (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {
		proc_rele(target_proc);
		return EPERM;
	}
...
	if (target_pid == cur_proc->p_pid) {
		/*
		 * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or
		 * return if the thread and/or task are already terminating. Either way, the
		 * current thread won't return to userspace.
		 */
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

打ち上げ

システム起動時にデーモンを作成し、その有効期間を制御する標準的な方法は launchd です。 ソースは macOS 10.10 までの古いバージョンの launchctl 用であり、コード例は説明のために提供されていることに注意してください。 最新の launchctl は XPC 経由で launchd シグナルを送信し、launchctl ロジックは XPC に移動されました。

アプリケーションがどのように正確に停止されるかを見てみましょう。 SIGTERM シグナルを送信する前に、「proc_terminate」システム コールを使用してアプリケーションの停止が試行されます。

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Could not terminate job: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Using fallback option to terminate job...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Could not signal job: %d: %s", error, strerror(error));
		} 
...
<>

内部では、proc_terminate はその名前に反して、SIGTERM を使用して psignal だけでなく SIGKILL も送信できます。

間接キル - リソース制限

さらに興味深いケースは、別のシステム コールで見ることができます。 プロセスポリシー。 このシステム コールの一般的な用途は、ファイル キャッシュ アクティビティによってシステムの速度が大幅に低下しないように、インデクサーが CPU 時間とメモリ クォータを制限するなど、アプリケーション リソースを制限することです。 proc_apply_resource_actions 関数からわかるように、アプリケーションがリソース制限に達すると、SIGKILL シグナルがプロセスに送信されます。

このシステム コールはプロセスを強制終了する可能性がありますが、システムはシステム コールを呼び出すプロセスの権限を適切にチェックしませんでした。 実際に確認してみる 存在したただし、この条件を回避するには代替フラグ PROC_POLICY_ACTION_SET を使用するだけで十分です。

したがって、アプリケーションの CPU 使用量クォータを「制限」すると (たとえば、1 ns のみの実行を許可するなど)、システム内の任意のプロセスを強制終了できます。 したがって、マルウェアはウイルス対策プロセスを含むシステム上のあらゆるプロセスを強制終了する可能性があります。 また、興味深いのは、pid 1 のプロセス (launchctl) を強制終了したときに発生する影響です。つまり、SIGKILL シグナルを処理しようとするとカーネル パニックが発生します:)

問題を解決する方法は？

プロセスが強制終了されるのを防ぐ最も簡単な方法は、システム コール テーブル内の関数ポインタを置き換えることです。 残念ながら、この方法は多くの理由から簡単ではありません。

まず、sysent のメモリ位置を制御するシンボルは XNU カーネル シンボルにプライベートであるだけでなく、カーネル シンボル内では見つけることができません。 関数を動的に逆アセンブルして関数内のポインターを検索するなど、ヒューリスティックな検索方法を使用する必要があります。

次に、テーブル内のエントリの構造は、カーネルのコンパイルに使用されたフラグに依存します。 CONFIG_REQUIRES_U32_MUNGING フラグが宣言されている場合、構造体のサイズが変更され、追加フィールドが追加されます。 sy_arg_munge32。 追加のチェックを実行してカーネルがどのフラグを使用してコンパイルされたかを判断するか、関数ポインタを既知のフラグと比較してチェックする必要があります。

struct sysent {         /* system call table */
        sy_call_t       *sy_call;       /* implementing function */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* system call arguments munger for 32-bit process */
#endif
        int32_t         sy_return_type; /* system call return types */
        int16_t         sy_narg;        /* number of args */
        uint16_t        sy_arg_bytes;   /* Total size of arguments in bytes for
                                         * 32-bit system calls
                                         */
};

幸いなことに、macOS の最新バージョンでは、Apple がプロセスを操作するための新しい API を提供しています。 Endpoint Security API を使用すると、クライアントは他のプロセスへの多くのリクエストを承認できます。 したがって、上記の API を使用して、SIGKILL シグナルを含むプロセスへのシグナルをブロックできます。

#include <bsm/libbsm.h>
#include <EndpointSecurity/EndpointSecurity.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
    es_client_t* cli = nullptr;
    {
        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {
            switch (message->event_type) {
                case ES_EVENT_TYPE_AUTH_SIGNAL:
                {
                    auto& msg = message->event.signal;
                    auto target = msg.target;
                    auto& token = target->audit_token;
                    auto pid = audit_token_to_pid(token);
                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);
                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);
                }
                    break;
                default:
                    break;
            }
        });
    }

    {
        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };
        es_subscribe(cli, evs, sizeof(evs) / sizeof(*evs));
    }

    printf("%dn", getpid());
    sleep(60); // could be replaced with other waiting primitive

    es_unsubscribe_all(cli);
    es_delete_client(cli);

    return 0;
}

同様に、シグナル保護メソッド (ポリシー proc_check_signal) を提供する MAC ポリシーをカーネルに登録できますが、API は正式にサポートされていません。

カーネル拡張機能の保護

システム内のプロセスを保護することに加えて、カーネル拡張機能自体 (kext) を保護することも必要です。 macOS は、開発者が IOKit デバイス ドライバーを簡単に開発できるフレームワークを提供します。 IOKit は、デバイスを操作するためのツールを提供するだけでなく、C++ クラスのインスタンスを使用してドライバーをスタッキングするためのメソッドも提供します。 ユーザー空間内のアプリケーションは、クラスの登録済みインスタンスを「検索」して、カーネルとユーザー空間の関係を確立できます。

システム内のクラス インスタンスの数を検出するには、ioclasscount ユーティリティがあります。

my_kext_ioservice = 1
my_kext_iouserclient = 1

ドライバー スタックに登録するカーネル拡張機能は、IOService から継承するクラスを宣言する必要があります (この場合は my_kext_ioservice など)。ユーザー アプリケーションに接続すると、IOUserClient (例では my_kext_iouserclient) から継承するクラスの新しいインスタンスが作成されます。

システムからドライバーをアンロードしようとすると (kextunload コマンド)、仮想関数「bool terminate(IOOptionBits options)」が呼び出されます。 kextunload を無効にするためにアンロードしようとするときに終了するには、呼び出しで false を返すだけで十分です。

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Unload is not allowed, returning false
    return false;
  }

  return super::terminate(options);
}

IsUnloadAllowed フラグは、ロード時に IOUserClient によって設定できます。 ダウンロード制限がある場合、kextunload コマンドは次の出力を返します。

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Password:
(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.
Failed to unload my.kext.test - (iokit/common) unsupported function.

IOUserClient に対しても同様の保護を行う必要があります。 クラスのインスタンスは、IOKitLib ユーザー空間関数「IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);」を使用してアンロードできます。 ユーザー空間アプリケーションが「終了」するまで、つまり「clientDied」関数が呼び出されなくなるまでは、「terminate」コマンドを呼び出すときに false を返すことができます。

ファイル保護

ファイルを保護するには、ファイルへのアクセスを制限できる Kauth API を使用するだけで十分です。 Apple はスコープ内のさまざまなイベントに関する通知を開発者に提供します。私たちにとって、KAUTH_VNODE_DELETE、KAUTH_VNODE_WRITE_DATA、および KAUTH_VNODE_DELETE_CHILD の操作は重要です。 ファイルへのアクセスを制限する最も簡単な方法はパスによってです。「vn_getpath」API を使用してファイルへのパスを取得し、パスのプレフィックスを比較します。 ファイル フォルダー パスの名前変更を最適化するために、システムは各ファイルへのアクセスを許可せず、名前が変更されたフォルダー自体へのアクセスのみを許可することに注意してください。 親パスを比較し、KAUTH_VNODE_DELETEを制限する必要があります。

このアプローチの欠点は、プレフィックスの数が増えるとパフォーマンスが低下する可能性があることです。 比較が O(prefix*length) (prefix はプレフィックスの数、length は文字列の長さ) と等しくないことを確認するには、プレフィックスによって構築された決定論的有限オートマトン (DFA) を使用できます。

与えられたプレフィックスのセットに対して DFA を構築する方法を考えてみましょう。 各プレフィックスの先頭でカーソルを初期化します。 すべてのカーソルが同じ文字を指している場合は、各カーソルを XNUMX 文字ずつ増やし、同じ行の長さが XNUMX つ増えることに注意してください。 異なるシンボルを持つ XNUMX つのカーソルがある場合は、カーソルが指すシンボルに従ってカーソルをグループに分割し、グループごとにアルゴリズムを繰り返します。

最初のケース (カーソルの下にあるすべての文字が同じ) では、同じ行に沿った遷移が 256 つだけある DFA 状態が得られます。 XNUMX 番目のケースでは、関数を再帰的に呼び出すことによって取得される、後続の状態へのサイズ XNUMX (文字数とグループの最大数) の遷移テーブルを取得します。

例を見てみましょう。 プレフィックスのセット (「/foo/bar/tmp/」、「/var/db/foo/」、「/foo/bar/aba/」、「foo/bar/aac/」) については、次のように取得できます。 DFA。 この図は、他の状態に至る遷移のみを示しており、他の遷移は最終的なものではありません。

DKA 州を通過する場合、3 つのケースが考えられます。

1. 最終状態に達しました - パスは保護されており、操作 KAUTH_VNODE_DELETE、KAUTH_VNODE_WRITE_DATA、および KAUTH_VNODE_DELETE_CHILD が制限されています。
2. 最終状態には到達しませんでしたが、パスは「終了」しました (null ターミネータに到達しました) - パスは親であるため、KAUTH_VNODE_DELETE を制限する必要があります。 vnode がフォルダーの場合は、最後に「/」を追加する必要があることに注意してください。そうしないと、ファイル「/foor/bar/t」に制限される可能性がありますが、これは正しくありません。
3. 最終状態に到達せず、パスが終了しませんでした。 どのプレフィックスもこれに一致しないため、制限は導入しません。

まとめ

開発中のセキュリティ ソリューションの目標は、ユーザーとそのデータのセキュリティ レベルを高めることです。 一方で、この目標は、オペレーティング システム自体が「弱い」脆弱性を解決する Acronis ソフトウェア製品の開発によって達成されます。 一方で、OS側で改善できるセキュリティ面の強化も怠ってはいけません。特に脆弱性を解消することで製品としての安定性が高まります。 この脆弱性は Apple 製品セキュリティ チームに報告され、macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) で修正されました。

これらすべては、ユーティリティがカーネルに正式にインストールされている場合にのみ実行できます。 つまり、外部の望ましくないソフトウェアに対するそのような抜け穴はありません。 ただし、ご覧のとおり、ウイルス対策システムやバックアップ システムなどの正規のプログラムを保護する場合でも作業が必要です。 しかし、macOS 用の新しい Acronis 製品には、システムからのアンロードに対する追加の保護機能が追加されました。

出所： habr.com