🥇Kuidas kaitsta protsesse ja juhtme extensioone macOS-is

Tere, Habr! Täna sooviksin rääkida sellest, kuidas saab kaitsta protsesse kurjategijate sissetungi eest macOS-is. Näiteks on see kasulik viirusetõrje või backup-süsteemi jaoks, eriti arvestades, et macOS-is on mitmeid viise protsessi "tappa". Loe edasi selle ja kaitsemeetodite kohta allpool.

Klassikaline viis protsessi "tapmiseks"

Kõigile tuntud viis protsessi "tapmiseks" on saata SIGKILL signaal protsessile. Bash'is saab tavaliste käskudega "kill -SIGKILL PID" või "pkill -9 NAME" protsessi tappa. Käsk "kill" on tuntud juba UNIXi aegadest ja on saadaval mitte ainult macOS-is, vaid ka teistes UNIX-i sarnastes süsteemides.

Nagu UNIX-i sarnastes süsteemides, võimaldab macOS ka protsessile saata mis tahes signaale, välja arvatud kaks — SIGKILL ja SIGSTOP. Selles artiklis käsitleme esmajoones SIGKILL signaali, mis on signaal, mis põhjustab protsessi tapmise.

macOS-i omadused

macOS-is kutsub süsteemikõne kill XNU tuumas esile funktsiooni psignal(SIGKILL,…). Proovime vaadata, milliseid muid kasutaja toiminguid kasutajaruumis võib psignal funktsiooni esile kutsuda. Jätame kõrvale psignali funktsiooni kutsed tuuma sisemiste mehhanismide tõttu (kuigi need võivad olla mittetriviaalsed, kuid jätame need teise artikli jaoks 🙂 — allkirja kontroll, mälu vead, exit/terminate töötlemine, failikaitse rikkumise jne.

Alustame ülevaadet funktsiooni ja vastava süsteemikõne kohta terminate_with_payload. On näha, et lisaks klassikalisele kill-kutsumisele on olemas alternatiivne lähenemine, mis on spetsiifiline macOS operatsioonisüsteemile ja mida ei leidu BSD-s. Mõlema süsteemikõne tööpõhimõtted on samuti sarnased. Need on otsesed kõned tuuma funktsioonile psignal. Jätame tähelepanuta, et enne protsessi tapmist toimub kontroll "cansignal" — kas protsess võib saata signaali teisele protsessile, süsteem ei luba ükskõik millisel rakendusel tappa süsteemiprotsesse näiteks.

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

Tavaliselt kasutatakse süsteemi käivitamiseks ja deemonite eluea kontrollimiseks launchd. Tahan märkida, et alltoodud originaalid viitavad vanale versioonile launchctl enne macOS 10.10, koodinäited on esitatud illustreerimiseks. Kaasaegne launchctl saadab signaalid launchd-le läbi XPC, launchctl-i loogika on sinna üle viidud.

Vaadakem, kuidas täpselt rakendusi peatada. Enne SIGTERM signaali saatmist proovib rakendusi peatada süsteemi kõne “proc_terminate” kaudu.

...
	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));
		}
...

Kuigi proc_terminate võib oma nime järgi saata mitte ainult psignali koos SIGTERM'iga, vaid ka SIGKILL'iga.

Kaudne tapmine — ressursipiirangud

Huvitavam juhtum võib ilmneda teises süsteemi kõnes process_policy. Tavaotstarbel kasutatakse seda süsteemi kõnet rakenduste ressursipiirangute jaoks, näiteks indekseerijale seatakse piirang protsessori aja ja mälu kvoodi peale, et süsteem ei aeglustuks oluliselt failide vahemälu toimingute tõttu. Kui rakendus saavutab ressursipiirangu, nagu võib näha funktsioonis proc_apply_resource_actions, saadetakse protsessile signaal SIGKILL.

Kuigi see süsteemi kõne võib potentsiaalselt tappa protsessi, ei kontrollinud süsteem piisavalt selle protsessi õigusi, kes süsteemi kõnet tegi. Tegelikult toimus kontroll eksisteeris, kuid piisab alternatiivse lipu PROC_POLICY_ACTION_SET kasutamisest selle tingimuse vältimiseks.

Siit, kui "piirata" CPU kasutamise kvooti rakendusele (näiteks lubada töötada ainult ühel ns-l), siis saab igasüsteemi protsessi tappa. Nii saab pahavara tappa igasuguseid protsesse süsteemis, sealhulgas ka viirusevastase protsessi. Samuti on huvitav efekt, mis tekib protsessi tapmisel pid 1 (launchctl) – kernel panic, kui proovida töödelda SIGKILL signaali 🙂

Kuidas probleemi lahendada?

Kõige otsesem viis protsessi tapmise keelamiseks on süsteem kutsumise tabelis funktsiooni osutaja asendamine. Kahjuks on see meetod paljuski mittetavaline.

Esiteks, sümbol, mis vastutab sysent'i asukoha eest mälus, on mitte ainult XNU tuuma privaatne sümbol, vaid seda ei saa leida ka tuuma sümbolitest. Peame kasutama heuristikameetodeid, näiteks funktsiooni dünaamilist disassembliimist ja osutaja otsimist selles.

Teiseks, tabeli kirje struktuur sõltub lippudest, millega tuuma on kokku pandud. Kui on kuulutatud lipp CONFIG_REQUIRES_U32_MUNGING, siis struktuuri suurus muutub – lisatakse täiendav väli. sy_arg_munge32. Peame tegema täiendava kontrolli selle üle, millise lipuga tuum on kompileeritud, näiteks kontrollida osutajaid funktsioonidele tuntud osutajate vahel.

struct sysent {         
        /* süsteemikutsumise tabel */
        sy_call_t       *sy_call;       /* teostava funktsiooni osutaja */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* süsteemikutsumise argumendi muudatus 32-bitise protsessi jaoks */
#endif
        int32_t         sy_return_type; /* süsteemikutsumise tagastusliigid */
        int16_t         sy_narg;        /* argumendide arv */
        uint16_t        sy_arg_bytes;   /* Argumendide kogusuurus baitidena 32-bitistes süsteemikutsumistes */
};

Õnneks pakub Apple kaasaegsetes macOS'i versioonides uut API-d protsesside haldamiseks. Endpoint Security API võimaldab klientidel autoriseerida mitmeid päringuid teistele protsessidele. Nii on võimalik blokeerida kõik signaalid protsessidele, sealhulgas SIGKILL signaali ülaltoodud API abil.

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

Sarnaselt on tuumas võimalik registreerida MAC Policy, mis pakub meetodi signaalide kaitsmiseks (policy proc_check_signal), kuid API-d ei toetata ametlikult.

Tuuma laiendi kaitse

Lisaks süsteemi protsesside kaitsmisele on vajalik ka tuumalaienemise (kext) enda kaitse. macOS pakub arendajatele IOKit seadme draiverite mugavaks arendamiseks raamistikku. IOKit mitte ainult ei paku vahendeid seadmete haldamiseks, vaid tagab ka draiverite virnastamise meetodid C++ klasside eksemplaride abil. Userspace'i rakendus suudab "leida" registreeritud klassi eksemplari, et luua side kernel-user space'iga.

Klasside eksemplaride arvu leidmiseks süsteemis on saadaval utiliit ioclasscount.

my_kext_ioservice = 1
my_kext_iouserclient = 1

Iga tuumalaienemine, mis soovib registreerida end draiverite virnas, peab kuulutama klassi, mis on pärandatud IOService'ist, näiteks my_kext_ioservice antud juhul. Kohandatud rakenduste ühendamine kutsub esile uue klassi eksemplari loomise, mis on pärandatud IOUserClient'ist, näites my_kext_iouserclient.

Draiveri süsteemist väljakandmise katse (käsk kextunload) kutsub esile virtuaalse funktsiooni "bool terminate(IOOptionBits options)". Piisab, kui tagastada false terminate-funktsiooni kutsumise kaudu, et keelata kextunload.

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Välja laadimine ei ole lubatud, tagastame false
    return false;
  }

  return super::terminate(options);
}

IsUnloadAllowed lipp võib olla seadistatud IOUserClient'i poolt laadimise ajal. Kui laadimine on piiratud, tagastab käsk kextunload järgmise väljundi:

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Parool:
(kernel) Ei saa eemaldada kext my.kext.test; teenused ei suutnud lõpetada - 0xe00002c7.
Ebaõnnestus my.kext.test väljaloadimine - (iokit/common) toetamata funktsioon.

Sarnane kaitse tuleb teostada ka IOUserClient'i jaoks. Klasside eksemplaride väljaladimine on võimalik userspace'i funktsiooni IOKitLib abil "IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);". Võib tagastada false käskluse "terminate" kutsumise ajal, kuni userspace'i rakendus ei "sure", st kuni ei kutsuta funktsiooni "clientDied".

Failide kaitse

Failide kaitsmiseks piisab Kauth API kasutamisest, mis võimaldab piirata failidele juurdepääsu. Apple annab arendajatele teateid erinevate sündmuste kohta ulatuses, mille jaoks on meie jaoks olulised toimingud KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ja KAUTH_VNODE_DELETE_CHILD. Failidele juurdepääsu piiramine on kõige lihtsam tee kaudu — kasutame API-d “vn_getpath” faili tee saamiseks ja võrdsustame tee prefiksit. Tuleb märkida, et kaustade ja failide nimede muutmise optimeerimise eesmärgil ei autoriseeri süsteem juurdepääsu igale failile, vaid ainult kaustale, mida muudetakse. On vajalik võrrelda vanema tee ja piirata KAUTH_VNODE_DELETE selle jaoks.

Selle lähenemise puuduseks võib olla madal jõudlus, kui prefiksite arv suureneb. Selleks, et võrreldud ei oleks O(prefix*length), kus prefix — prefiksite arv, length — stringi pikkus, saab kasutada määratletud lõppautomaat (DKA), mis on ehitatud prefiksite põhjal.

Vaatleme DKA ehitamise viisi antud prefiksite kogumile. Algatame kursoreid iga prefiksi alguses. Kui kõik kursored osutavad samale sümbolile, siis tõstame iga kursori ühe sümboli võrra ja mäletame, et sama pikkuse rida on suurem ühesed. Kui on kaks kursorit, mille all olevad sümbolid erinevad, jagame kursoreid gruppideks sümboli järgi, millele nad osutavad, ja kordame algoritmi iga grupi jaoks.

Esimesel juhul (kui kõik sümbolid kursoreid all on samad) saame DKA oleku, millel on ainult üks üleminek sama pika rea juurde. Teisel juhul saame üleminekute tabeli, mille suurus on 256 (sümbolite arv ja maksimaalne gruppide arv) järgmistele olekutele, mis saadakse funktsiooni rekursiivsel kutsel.

Vaatleme näidet. Antud prefiksite kogumi (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) korral saab DKA-d. Joonisel on esitatud ainult üleminekud, mis viivad teistesse olekutesse, teised üleminekud ei ole lõplikud.

DKA olekute läbimise käigus võib esineda 3 juhtumit.

Oleme jõudnud lõppolekusse — tee on kaitstud, piirame toimingute KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ja KAUTH_VNODE_DELETE_CHILD teostamist.
Lõppseisundit ei saavutatud, kuid tee "lõppes" (null-terminaator saavutati) — tee on vanem, KAUTH_VNODE_DELETE tuleb piirata. Oluline on märkida, et kui vnode on kaust, tuleb lõppu lisada ‘/’, sest vastasel juhul võib piirang kehtida failile “/foor/bar/t”, mis ei ole õige.
Lõppseisundit ei saavutatud, tee ei lõpetanud. Ükski eelnevatest ei vasta antud, piiranguid ei kehtestata.

Kokkuvõte

Arendatavate turvaratsete eesmärk on tõsta kasutaja ja tema andmete turvalisuse taset. Ühelt poolt saavutatakse see eesmärk Acronis tarkvara arendamisega, mis katab need haavatavused, kus operatsioonisüsteem ise on “nõrk”. Teiselt poolt ei tohi alahinnata ka OS külje turvaelementide tugevdamist, kuna selliste haavatavuste likvideerimine suurendab meie toote vastupidavust. Haavatavus teavitati Apple'i toote turvameeskonnale ja see parandati macOS 10.14.5 versioonis (https://support.apple.com/en-gb/HT210119).

Seda kõike saab teha ainult siis, kui teie tööriist on ametlikult installitud süsteemi. Ehkki välistel ja soovimatutel tarkvaradel ei ole selliseid tagavee tee. Kuidas aga näha, isegi õigustatud programmide, nagu viirusetõrje ja varundussüsteemide kaitsmiseks peab vaeva nägema. Kuid nüüd on Acronis uued tooted macOS-i jaoks varustatud täiendava kaitsega süsteemist laadimise eest.

Allikas: habr.com