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)
Ograničenja pokretanja u macOS-u su uvedena kako bi se poboljšala sigurnost regulisanjem kako, ko i odakle se proces može pokrenuti. Uvedena u macOS Ventura, pružaju okvir koji kategorizuje svaki sistemski binarni fajl u različite kategorije ograničenja, koje su definisane unutar trust cache, liste koja sadrži sistemske binarne fajlove i njihove odgovarajuće hash-eve. Ova ograničenja se protežu na svaki izvršni binarni fajl unutar sistema, podrazumevajući skup pravila koja definišu zahteve za pokretanje određenog binarnog fajla. Pravila obuhvataju samoprocenjivanja koja binarni fajl mora zadovoljiti, roditeljska ograničenja koja moraju biti ispunjena od strane njegovog roditeljskog procesa, i odgovorna ograničenja koja moraju poštovati druge relevantne entitete.
Mehanizam se proteže na aplikacije trećih strana putem Environment Constraints, počevši od macOS Sonoma, omogućavajući programerima da zaštite svoje aplikacije tako što će odrediti skup ključeva i vrednosti za ograničenja okruženja.
Definišete ograničenja okruženja i biblioteka za pokretanje u rečnicima ograničenja koje ili čuvate u launchd datotekama sa svojstvima, ili u odvojenim datotekama sa svojstvima koje koristite u potpisivanju koda.
Postoje 4 tipa ograničenja:
Samoprocenjivanja: Ograničenja primenjena na izvršni binarni fajl.
Roditeljski proces: Ograničenja primenjena na roditelja procesa (na primer launchd koji pokreće XP servis)
Odgovorna ograničenja: Ograničenja primenjena na proces koji poziva servis u XPC komunikaciji
Ograničenja učitavanja biblioteka: Koristite ograničenja učitavanja biblioteka da selektivno opišete kod koji može biti učitan
Dakle, kada proces pokuša da pokrene drugi proces — pozivajući execve(_:_:_:) ili posix_spawn(_:_:_:_:_:_:) — operativni sistem proverava da li izvršni fajl zadovoljava svoje samoograničenje. Takođe proverava da li izvršni fajl roditeljskog procesa zadovoljava roditeljsko ograničenje izvršnog fajla, i da li izvršni fajl odgovornog procesa zadovoljava odgovorno ograničenje izvršnog fajla. Ako bilo koje od ovih ograničenja pokretanja nije ispunjeno, operativni sistem ne pokreće program.
Ako prilikom učitavanja biblioteke bilo koji deo ograničenja biblioteke nije tačan, vaš proces ne učitava biblioteku.
LC se sastoji od činjenica i logičkih operacija (i, ili..) koje kombinuju činjenice.
Činjenice koje LC može koristiti su dokumentovane. Na primer:
is-init-proc: Boolean vrednost koja označava da li izvršni fajl mora biti proces inicijalizacije operativnog sistema (launchd).
is-sip-protected: Boolean vrednost koja označava da li izvršni fajl mora biti fajl zaštićen Sistemskom integritetnom zaštitom (SIP).
on-authorized-authapfs-volume: Boolean vrednost koja označava da li je operativni sistem učitao izvršni fajl sa autorizovanog, autentifikovanog APFS volumena.
on-authorized-authapfs-volume: Boolean vrednost koja označava da li je operativni sistem učitao izvršni fajl sa autorizovanog, autentifikovanog APFS volumena.
Cryptexes volumen
on-system-volume: Boolean vrednost koja označava da li je operativni sistem učitao izvršni fajl sa trenutno pokrenutog sistemskog volumena.
Unutar /System...
...
Kada je Apple binarni fajl potpisan, dodeljuje ga LC kategoriji unutar trust cache.
iOS 16 LC kategorije su obrnute i dokumentovane ovde.
Trenutne LC kategorije (macOS 14 - Somona) su obrnute i njihove opisne informacije se mogu naći ovde.
Na primer, Kategorija 1 je:
(on-authorized-authapfs-volume || on-system-volume): Mora biti u System ili Cryptexes volumenu.
launch-type == 1: Mora biti sistemska usluga (plist u LaunchDaemons).
validation-category == 1: Izvršna datoteka operativnog sistema.
is-init-proc: Launchd
Imate više informacija ovde, ali u suštini, one su definisane u AMFI (AppleMobileFileIntegrity), tako da treba da preuzmete Kernel Development Kit da biste dobili KEXT. Simboli koji počinju sa kConstraintCategory su zanimljivi. Ekstrakcijom ćete dobiti DER (ASN.1) kodirani tok koji ćete morati da dekodirate pomoću ASN.1 Decoder ili python-asn1 biblioteke i njenog dump.py skripta, andrivet/python-asn1 koji će vam dati razumljiviju string.
Ovo su Launch Ograničenja postavljena u aplikacijama trećih strana. Razvijač može odabrati činjenice i logičke operande koje će koristiti u svojoj aplikaciji da bi ograničio pristup samom sebi.
Moguće je enumerisati Ograničenja Okruženja aplikacije sa:
U macOS postoji nekoliko kešova poverenja:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
A u iOS-u izgleda da se nalazi u /usr/standalone/firmware/FUD/StaticTrustCache.img4.
Na macOS-u koji radi na Apple Silicon uređajima, ako Apple potpisani binarni fajl nije u kešu poverenja, AMFI će odbiti da ga učita.
Prethodni fajlovi keša poverenja su u formatu IMG4 i IM4P, pri čemu je IM4P deo sa payload-om formata IMG4.
Možete koristiti pyimg4 za ekstrakciju payload-a iz baza podataka:
(Druga opcija bi mogla biti korišćenje alata img4tool, koji će raditi čak i na M1, čak i ako je verzija stara, i za x86_64 ako ga instalirate na odgovarajućim mestima).
Sada možete koristiti alat trustcache da dobijete informacije u čitljivom formatu:
Keš poverenja prati sledeću strukturu, tako da je LC kategorija 4. kolona
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 would have mitigated several old attacks by making sure that the process won't be executed in unexpected conditions: For example from unexpected locations or being invoked by an unexpected parent process (if only launchd should be launching it)
Moreover, Launch Constraints also mitigates downgrade attacks.
However, they don't mitigate common XPC abuses, Electron code injections or dylib injections without library validation (unless the team IDs that can load libraries are known).
In the Sonoma release, a notable point is the daemon XPC service's responsibility configuration. The XPC service is accountable for itself, as opposed to the connecting client being responsible. This is documented in the feedback report FB13206884. This setup might seem flawed, as it allows certain interactions with the XPC service:
Launching the XPC Service: If assumed to be a bug, this setup does not permit initiating the XPC service through attacker code.
Connecting to an Active Service: If the XPC service is already running (possibly activated by its original application), there are no barriers to connecting to it.
While implementing constraints on the XPC service might be beneficial by narrowing the window for potential attacks, it doesn't address the primary concern. Ensuring the security of the XPC service fundamentally requires validating the connecting client effectively. This remains the sole method to fortify the service's security. Also, it's worth noting that the mentioned responsibility configuration is currently operational, which might not align with the intended design.
Even if it's required that the application has to be opened by LaunchService (in the parents constraints). This can be achieved using open (which can set env variables) or using the Launch Services API (where env variables can be indicated).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
