macOS Launch/Environment Constraints & Trust Cache
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Kikomo cha uzinduzi katika macOS kilianzishwa ili kuboresha usalama kwa kudhibiti jinsi, nani, na kutoka wapi mchakato unaweza kuanzishwa. Kilianza katika macOS Ventura, kinatoa mfumo ambao unagawanya kila binary ya mfumo katika makundi tofauti ya vizuizi, ambavyo vimefafanuliwa ndani ya cache ya kuaminika, orodha inayojumuisha binaries za mfumo na hash zao husika. Vizuizi hivi vinapanuka kwa kila binary inayoweza kutekelezwa ndani ya mfumo, ikihusisha seti ya kanuni zinazofafanua mahitaji ya kuanzisha binary fulani. Kanuni hizo zinajumuisha vizuizi vya ndani ambavyo binary lazima ikidhi, vizuizi vya mzazi vinavyohitajika kukidhi na mchakato wake wa mzazi, na vizuizi vya kuwajibika vinavyopaswa kufuatwa na vyombo vingine vinavyohusiana.
Mekaniki hii inapanuka kwa programu za upande wa tatu kupitia Vizuizi vya Mazingira, kuanzia macOS Sonoma, ikiruhusu wabunifu kulinda programu zao kwa kubainisha seti ya funguo na thamani za vizuizi vya mazingira.
Unafafanua vizuizi vya mazingira na maktaba ya uzinduzi katika kamusi za vizuizi ambazo unaziokoa katika faili za orodha ya mali ya launchd, au katika faili za orodha ya mali tofauti ambazo unazitumia katika saini ya msimbo.
Kuna aina 4 za vizuizi:
Vizuizi vya Ndani: Vizuizi vinavyotumika kwa binary inayotembea.
Mchakato wa Mzazi: Vizuizi vinavyotumika kwa mzazi wa mchakato (kwa mfano launchd inayoendesha huduma ya XP)
Vizuizi vya Kuwajibika: Vizuizi vinavyotumika kwa mchakato unaoitisha huduma katika mawasiliano ya XPC
Vizuizi vya kupakia maktaba: Tumia vizuizi vya kupakia maktaba kuelezea kwa kuchagua msimbo ambao unaweza kupakiwa
Hivyo wakati mchakato unajaribu kuanzisha mchakato mwingine — kwa kuita execve(_:_:_:) au posix_spawn(_:_:_:_:_:_:) — mfumo wa uendeshaji unakagua kwamba faili inayoweza kutekelezwa inakidhi vizuizi vyake vya ndani. Pia inakagua kwamba mzazi wa mchakato inayoweza kutekelezwa inakidhi vizuizi vya mzazi vya executable, na kwamba mchakato wa kuwajibika inayoweza kutekelezwa inakidhi vizuizi vya mchakato wa kuwajibika. Ikiwa yoyote ya vizuizi hivi vya uzinduzi havikidhi, mfumo wa uendeshaji hauendeshi programu hiyo.
Ikiwa wakati wa kupakia maktaba sehemu yoyote ya vizuizi vya maktaba haviko sahihi, mchakato wako haupaki maktaba hiyo.
LC inaundwa na fact na operesheni za mantiki (na, au..) zinazounganisha ukweli.
Ukweli ambao LC inaweza kutumia umeandikwa. Kwa mfano:
is-init-proc: Thamani ya Boolean inayonyesha ikiwa executable lazima iwe mchakato wa kuanzisha wa mfumo wa uendeshaji (launchd).
is-sip-protected: Thamani ya Boolean inayonyesha ikiwa executable lazima iwe faili iliyopewa ulinzi na Mfumo wa Uthibitisho wa Usalama (SIP).
on-authorized-authapfs-volume: Thamani ya Boolean inayonyesha ikiwa mfumo wa uendeshaji ulipakia executable kutoka kwenye kiasi cha APFS kilichothibitishwa, kilichothibitishwa.
on-authorized-authapfs-volume: Thamani ya Boolean inayonyesha ikiwa mfumo wa uendeshaji ulipakia executable kutoka kwenye kiasi cha APFS kilichothibitishwa, kilichothibitishwa.
Kiasi cha Cryptexes
on-system-volume: Thamani ya Boolean inayonyesha ikiwa mfumo wa uendeshaji ulipakia executable kutoka kwenye kiasi cha mfumo kilichozinduliwa kwa sasa.
Ndani ya /System...
...
Wakati binary ya Apple imesainiwa in itapewa LC category ndani ya cache ya kuaminika.
iOS 16 LC categories zilirejelewa na kuandikwa hapa hapa.
LC categories za sasa (macOS 14 - Somona) zimejulikana na maelezo yao yanaweza kupatikana hapa.
Kwa mfano, Kategoria 1 ni:
(on-authorized-authapfs-volume || on-system-volume): Lazima iwe kwenye System au Cryptexes volume.
launch-type == 1: Lazima iwe huduma ya mfumo (plist katika LaunchDaemons).
validation-category == 1: Kifaa cha mfumo wa uendeshaji.
is-init-proc: Launchd
Una maelezo zaidi kuhusu hii hapa, lakini kimsingi, Zimefafanuliwa katika AMFI (AppleMobileFileIntegrity), hivyo unahitaji kupakua Kernel Development Kit ili kupata KEXT. Alama zinazohusiana na kConstraintCategory ndizo za kuvutia. Ukizitoa utapata mstream wa DER (ASN.1) uliokodishwa ambao utahitaji kufasiri kwa kutumia ASN.1 Decoder au maktaba ya python-asn1 na skripti yake ya dump.py, andrivet/python-asn1 ambayo itakupa mfuatano wa maneno unaoeleweka zaidi.
Hizi ni Mipaka za Uzinduzi zilizowekwa katika programu za upande wa tatu. Mwandishi anaweza kuchagua ukweli na operands za kimantiki kutumia katika programu yake ili kuzuia ufikiaji kwake mwenyewe.
Inawezekana kuhesabu Mipaka ya Mazingira ya programu kwa:
Katika macOS kuna baadhi ya hifadhi za kuaminika:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
Na katika iOS inaonekana kama iko katika /usr/standalone/firmware/FUD/StaticTrustCache.img4.
Katika macOS inayotembea kwenye vifaa vya Apple Silicon, ikiwa binary iliyosainiwa na Apple haipo katika hifadhi ya kuaminika, AMFI itakataa kuipakia.
Faili za awali za hifadhi za kuaminika ziko katika muundo IMG4 na IM4P, ambapo IM4P ni sehemu ya mzigo ya muundo wa IMG4.
Unaweza kutumia pyimg4 kutoa mzigo wa hifadhidata:
(Chaguo kingine kinaweza kuwa kutumia chombo img4tool, ambacho kitaendesha hata kwenye M1 hata kama toleo ni la zamani na kwa x86_64 ikiwa utaweka katika maeneo sahihi).
Sasa unaweza kutumia chombo trustcache kupata habari katika muundo unaoweza kusomeka:
The trust cache follows the following structure, so The LC category is the 4th column
Kikundi cha kuaminika kinafuata muundo ufuatao, hivyo LC category ni safu ya 4
Then, you could use a script such as this one to extract data.
From that data you can check the Apps with a launch constraints value of 0, which are the ones that aren't constrained (check here for what each value is).
Launch Constrains ingekuwa imepunguza mashambulizi kadhaa ya zamani kwa kuthibitisha kwamba mchakato hautatekelezwa katika hali zisizotarajiwa: Kwa mfano kutoka maeneo yasiyotarajiwa au kuanzishwa na mchakato wa mzazi asiyejulikana (ikiwa tu launchd inapaswa kuanzisha).
Zaidi ya hayo, Launch Constraints pia inapunguza mashambulizi ya kudhalilisha.
Hata hivyo, hazipunguzi matumizi ya kawaida ya XPC, Electron kuingiza msimbo au kuingiza dylib bila uthibitisho wa maktaba (isipokuwa vitambulisho vya timu vinavyoweza kupakia maktaba vinajulikana).
Katika toleo la Sonoma, jambo muhimu ni mipangilio ya wajibu ya huduma ya XPC daemon. Huduma ya XPC inawajibika kwa ajili yake mwenyewe, tofauti na mteja anayounganisha kuwa na wajibu. Hii imeandikwa katika ripoti ya maoni FB13206884. Mpangilio huu unaweza kuonekana kuwa na kasoro, kwani unaruhusu mwingiliano fulani na huduma ya XPC:
Kuanzisha Huduma ya XPC: Ikiwa inachukuliwa kuwa hitilafu, mpangilio huu haukuruhusu kuanzisha huduma ya XPC kupitia msimbo wa mshambuliaji.
Kuungana na Huduma Inayoendelea: Ikiwa huduma ya XPC tayari inaendesha (inaweza kuwa imewezeshwa na programu yake ya asili), hakuna vizuizi vya kuungana nayo.
Wakati wa kutekeleza vizuizi kwenye huduma ya XPC kunaweza kuwa na manufaa kwa kupunguza dirisha la mashambulizi yanayoweza kutokea, haishughuliki wasiwasi wa msingi. Kuthibitisha usalama wa huduma ya XPC kimsingi kunahitaji kuthibitisha mteja anayounganisha kwa ufanisi. Hii inabaki kuwa njia pekee ya kuimarisha usalama wa huduma hiyo. Pia, inafaa kutaja kwamba mpangilio wa wajibu ulioelezwa kwa sasa unafanya kazi, ambayo inaweza kutokubaliana na muundo ulio kusudiwa.
Hata kama inahitajika kwamba programu lazima ifunguliwe na LaunchService (katika vizuizi vya wazazi). Hii inaweza kufikiwa kwa kutumia open (ambayo inaweza kuweka mabadiliko ya mazingira) au kutumia Launch Services API (ambapo mabadiliko ya mazingira yanaweza kuonyeshwa).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
