כיצד להגן על תהליכים והרחבות ליבה ב-macOS

שלום, הבר! היום אני רוצה לדבר על איך אתה יכול להגן על תהליכים מפני התקפות של תוקפים ב-macOS. לדוגמה, זה שימושי עבור אנטי וירוס או מערכת גיבוי, במיוחד מכיוון שתחת macOS ישנן מספר דרכים "להרוג" תהליך. קראו על זה ועל שיטות הגנה מתחת לחתוך.

הדרך הקלאסית "להרוג" תהליך

דרך ידועה "להרוג" תהליך היא לשלוח אות SIGKILL לתהליך. דרך bash אתה יכול לקרוא ל"kill -SIGKILL PID" הסטנדרטי או "pkill -9 NAME" כדי להרוג. הפקודה "הרוג" ידועה עוד מימי UNIX והיא זמינה לא רק ב-macOS, אלא גם במערכות אחרות דמויות UNIX.

בדיוק כמו במערכות דמויות UNIX, macOS מאפשר ליירט כל אותות לתהליך מלבד שניים - SIGKILL ו-SIGSTOP. מאמר זה יתמקד בעיקר באות SIGKILL כאות הגורם לתהליך להרוג.

פרטי macOS

ב-macOS, קריאת מערכת ההרוג בקרנל של XNU קוראת לפונקציה psignal(SIGKILL,...). בואו ננסה לראות אילו פעולות משתמש אחרות במרחב המשתמש יכולות להיקרא על ידי פונקציית psignal. בוא נשכה את הקריאות לפונקציית psignal במנגנונים הפנימיים של הקרנל (אם כי הם עשויים להיות לא טריוויאליים, אבל נשאיר אותם למאמר אחר 🙂 - אימות חתימה, שגיאות זיכרון, טיפול ביציאה/סיום, הפרות של הגנה על קבצים, וכו '

נתחיל את הסקירה עם הפונקציה וקריאת המערכת המתאימה terminate_with_payload. ניתן לראות שבנוסף ל-kill call הקלאסית, ישנה גישה חלופית הספציפית למערכת ההפעלה macOS ואינה נמצאת ב-BSD. עקרונות הפעולה של שתי שיחות המערכת דומות אף הן. הן קריאות ישירות לפונקציית הקרנל 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);
	}
...
}

השיקה

הדרך הסטנדרטית ליצור דמונים בעת הפעלת המערכת ולשלוט בחייהם מושקת. שים לב שהמקורות הם עבור הגרסה הישנה של launchctl עד macOS 10.10, דוגמאות קוד מסופקות למטרות המחשה. Launchctl מודרני שולח אותות שיגור באמצעות XPC, לוגיקת launchctl הועברה אליו.

בואו נסתכל איך בדיוק עוצרים יישומים. לפני שליחת האות 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, למרות שמו, יכול לשלוח לא רק psignal עם SIGTERM, אלא גם SIGKILL.

הרג עקיף - מגבלת משאבים

מקרה מעניין יותר ניתן לראות בשיחת מערכת אחרת process_policy. שימוש נפוץ בקריאה למערכת זו הוא להגביל משאבי יישומים, כגון אינדקס כדי להגביל את זמן ה-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, אפל מספקת API חדש לעבודה עם תהליכים. ה-API של Endpoint Security מאפשר ללקוחות לאשר בקשות רבות לתהליכים אחרים. לפיכך, אתה יכול לחסום כל אותות לתהליכים, כולל אות SIGKILL, באמצעות ה-API הנ"ל.

#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;
}

באופן דומה, ניתן לרשום מדיניות MAC בליבה, המספקת שיטת הגנה על אותות (policy proc_check_signal), אך ה-API אינו נתמך רשמית.

הגנה על הרחבת ליבה

בנוסף להגנה על תהליכים במערכת, יש צורך גם בהגנה על תוסף הקרנל עצמו (kext). macOS מספקת מסגרת למפתחים לפתח בקלות מנהלי התקנים של IOKit. בנוסף לאספקת כלים לעבודה עם מכשירים, IOKit מספקת שיטות לערימת מנהלי התקנים באמצעות מופעים של מחלקות C++. אפליקציה במרחב המשתמש תוכל "למצוא" מופע רשום של המחלקה כדי ליצור קשר ליבה-userspace.

כדי לזהות את מספר מופעי המחלקה במערכת, יש את כלי השירות ioclasscount.

my_kext_ioservice = 1
my_kext_iouserclient = 1

כל סיומת ליבה שרוצה להירשם בערימת הדרייבר חייבת להכריז על מחלקה שיורשת מ-IOService, למשל my_kext_ioservice במקרה זה. חיבור יישומי משתמש גורם ליצירת מופע חדש של המחלקה שיורשת מ-IOUserClient, בדוגמה my_kext_iouserclient.

כאשר מנסים לפרוק מנהל התקן מהמערכת (פקודה kextunload), הפונקציה הוירטואלית "bool terminate (IOOptionBits options)" נקראת. זה מספיק כדי להחזיר false על השיחה כדי לסיים כאשר מנסים לפרוק כדי להשבית kextunload.

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);". אתה יכול להחזיר false בעת קריאה לפקודה "terminate" עד שיישום מרחב המשתמש "מת", כלומר, הפונקציה "clientDied" לא תיקרא.

הגנה על קבצים

כדי להגן על קבצים, מספיק להשתמש ב-Kauth API, המאפשר להגביל את הגישה לקבצים. אפל מספקת למפתחים הודעות על אירועים שונים בהיקף; עבורנו, הפעולות KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ו-KAUTH_VNODE_DELETE_CHILD חשובות. הדרך הקלה ביותר להגביל את הגישה לקבצים היא באמצעות נתיב - אנו משתמשים ב-API "vn_getpath" כדי לקבל את הנתיב לקובץ ולהשוות את קידומת הנתיב. שימו לב שכדי לייעל את שמות הנתיבים של תיקיות הקבצים, המערכת לא מאשרת גישה לכל קובץ, אלא רק לתיקיה עצמה ששמה שונה. יש צורך להשוות את נתיב האב ולהגביל את KAUTH_VNODE_DELETE עבורו.

החיסרון של גישה זו עשוי להיות ביצועים נמוכים ככל שמספר הקידומות גדל. כדי להבטיח שההשוואה לא תהיה שווה ל-O(קידומת*אורך), כאשר קידומת היא מספר הקידומות, אורך הוא אורך המחרוזת, ניתן להשתמש באוטומט סופי דטרמיניסטי (DFA) שנבנה על ידי קידומות.

הבה נשקול שיטה לבניית DFA עבור קבוצה נתונה של קידומות. אנו מאתחלים את הסמנים בתחילת כל קידומת. אם כל הסמנים מצביעים על אותו תו, הגדל כל סמן בתו אחד וזכור שאורך אותה שורה גדול יותר באחד. אם יש שני סמנים עם סמלים שונים, חלקו את הסמנים לקבוצות לפי הסמל שהם מצביעים עליו וחזרו על האלגוריתם עבור כל קבוצה.

במקרה הראשון (כל התווים מתחת לסמנים זהים), נקבל מצב DFA שיש לו רק מעבר אחד באותו קו. במקרה השני, נקבל טבלת מעברים בגודל 256 (מספר תווים ומספר מקסימלי של קבוצות) למצבים הבאים המתקבלים על ידי קריאה רקורסיבית לפונקציה.

בואו נסתכל על דוגמה. עבור קבוצה של קידומות ("/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 terminator) - הנתיב הוא אב, יש צורך להגביל את KAUTH_VNODE_DELETE. שימו לב שאם vnode היא תיקיה, עליכם להוסיף '/' בסוף, אחרת זה עלול להגביל אותו לקובץ "/foor/bar/t", שהוא שגוי.
3. המצב הסופי לא הושג, הדרך לא הסתיימה. אף אחת מהקידומות לא תואמת את זה, אנחנו לא מציגים הגבלות.

מסקנה

מטרת פתרונות האבטחה המפותחים היא להגביר את רמת האבטחה של המשתמש והנתונים שלו. מצד אחד, מטרה זו מושגת על ידי פיתוח מוצר התוכנה Acronis, שסוגר את אותן נקודות תורפה שבהן מערכת ההפעלה עצמה "חלשה". מצד שני, אל לנו להזניח את חיזוק היבטי האבטחה הניתנים לשיפור בצד מערכת ההפעלה, במיוחד מאחר שסגירת נקודות תורפה כאלה מגבירה את היציבות שלנו כמוצר. הפגיעות דווחה לצוות אבטחת המוצר של Apple והיא תוקנה ב-macOS 10.14.5 (https://support.apple.com/en-gb/HT210119).

כל זה יכול להיעשות רק אם כלי השירות שלך הותקן רשמית בליבה. כלומר, אין פרצות כאלה לתוכנות חיצוניות ולא רצויות. עם זאת, כפי שאתה יכול לראות, אפילו הגנה על תוכנות לגיטימיות כגון אנטי וירוס ומערכות גיבוי דורשת עבודה. אך כעת למוצרי Acronis החדשים עבור macOS תהיה הגנה נוספת מפני פריקה מהמערכת.

מקור: www.habr.com