macOS xpc_connection_get_audit_token Attack
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)
For further information check the original post: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. This is a summary:
If you don't know what Mach Messages are start checking this page:
macOS IPC - Inter Process CommunicationFor the moment remember that (definition from here): Mach poruke se šalju preko mach porta, koji je kanal komunikacije sa jednim prijemnikom i više pošiljalaca ugrađen u mach kernel. Više procesa može slati poruke na mach port, ali u bilo kojem trenutku samo jedan proces može čitati iz njega. Baš kao i deskriptori datoteka i soketi, mach portovi se dodeljuju i upravljaju od strane kernela, a procesi vide samo ceo broj, koji mogu koristiti da označe kernelu koji od svojih mach portova žele da koriste.
If you don't know how a XPC connection is established check:
macOS XPCWhat is interesting for you to know is that XPC’s abstraction is a one-to-one connection, but it is based on top of a technology which can have multiple senders, so:
Mach portovi su jedini prijemnici, više pošiljalaca.
Audit token XPC veze je audit token kopiran iz najnovije primljene poruke.
Dobijanje audit token XPC veze je ključno za mnoge provere bezbednosti.
Although the previous situation sounds promising there are some scenarios where this is not going to cause problems (from here):
Audit tokeni se često koriste za proveru autorizacije da odluče da li da prihvate vezu. Kako se to dešava koristeći poruku na servisnom portu, veza još nije uspostavljena. Više poruka na ovom portu će se samo obraditi kao dodatni zahtevi za vezu. Dakle, sve provere pre prihvatanja veze nisu ranjive (to takođe znači da unutar -listener:shouldAcceptNewConnection: audit token je siguran). Stoga tražimo XPC veze koje verifikuju specifične akcije.
XPC rukovaoci događajima se obrađuju sinhrono. To znači da rukovalac događajem za jednu poruku mora biti završen pre nego što se pozove za sledeću, čak i na konkurentnim redovima za raspodelu. Dakle, unutar XPC rukovaoca događajem audit token ne može biti prepisan drugim normalnim (ne-odgovor!) porukama.
Two different methods this might be exploitable:
Variant1:
Eksploit se povezuje na servis A i servis B
Servis B može pozvati privilegovan funkcionalnost u servisu A koju korisnik ne može
Servis A poziva xpc_connection_get_audit_token dok nije unutar rukovaoca događajem za vezu u dispatch_async.
Tako bi druga poruka mogla prepisati Audit Token jer se šalje asinhrono van rukovaoca događajem.
Eksploit prosleđuje servisu B pravo SLANJA na servis A.
Tako će svc B zapravo slati poruke servisu A.
Eksploit pokušava da pozove privilegovanu akciju. U RC svc A proverava autorizaciju ove akcije dok svc B prepisuje Audit token (dajući eksploitu pristup da pozove privilegovanu akciju).
Variant 2:
Servis B može pozvati privilegovan funkcionalnost u servisu A koju korisnik ne može
Eksploit se povezuje sa servisom A koji šalje eksploitu poruku očekujući odgovor na specifičnom portu za odgovor.
Eksploit šalje servisu B poruku prosleđujući taj port za odgovor.
Kada servis B odgovara, on šalje poruku servisu A, dok eksploit šalje drugačiju poruku servisu A pokušavajući da dođe do privilegovane funkcionalnosti i očekujući da će odgovor servisa B prepisati Audit token u savršenom trenutku (Race Condition).
Scenario:
Dva mach servisa A i B na koja se možemo povezati (na osnovu profila sandboxes i provere autorizacije pre prihvatanja veze).
A mora imati proveru autorizacije za specifičnu akciju koju B može proći (ali naša aplikacija ne može).
Na primer, ako B ima neka prava ili radi kao root, to bi mu moglo omogućiti da zatraži od A da izvrši privilegovanu akciju.
Za ovu proveru autorizacije, A dobija audit token asinhrono, na primer pozivajući xpc_connection_get_audit_token iz dispatch_async.
U ovom slučaju, napadač bi mogao izazvati Race Condition praveći eksploit koji traži od A da izvrši akciju nekoliko puta dok B šalje poruke A. Kada je RC uspešan, audit token B će biti kopiran u memoriji dok se zahtev našeg eksploita obrađuje od strane A, dajući mu pristup privilegovanoj akciji koju je samo B mogao zatražiti.
Ovo se dogodilo sa A kao smd i B kao diagnosticd. Funkcija SMJobBless iz smb može se koristiti za instalaciju novog privilegovanog pomoćnog alata (kao root). Ako proces koji radi kao root kontaktira smd, neće se izvršiti druge provere.
Stoga, servis B je diagnosticd jer radi kao root i može se koristiti za praćenje procesa, tako da kada praćenje počne, on će slati više poruka u sekundi.
Da bi se izvršio napad:
Inicirajte vezu sa servisom nazvanim smd koristeći standardni XPC protokol.
Formirajte sekundarnu vezu sa diagnosticd. Suprotno normalnoj proceduri, umesto da kreira i šalje dva nova mach porta, pravo slanja klijentskog porta se zamenjuje duplikatom prava slanja povezanog sa smd vezom.
Kao rezultat, XPC poruke mogu biti poslati diagnosticd, ali odgovori iz diagnosticd se preusmeravaju na smd. Za smd, izgleda kao da poruke od korisnika i diagnosticd potiču iz iste veze.
Sledeći korak uključuje davanje instrukcija diagnosticd da započne praćenje odabranog procesa (potencijalno korisnikovog). Istovremeno, poplava rutinskih 1004 poruka se šalje smd. Cilj ovde je instalirati alat sa povišenim privilegijama.
Ova akcija pokreće trku uslov unutar funkcije handle_bless. Vreme je ključno: poziv funkcije xpc_connection_get_pid mora vratiti PID korisnikovog procesa (jer se privilegovani alat nalazi u korisničkom paketu aplikacije). Međutim, funkcija xpc_connection_get_audit_token, posebno unutar podrutine connection_is_authorized, mora se pozivati na audit token koji pripada diagnosticd.
U XPC (Međuprocesna komunikacija) okruženju, iako rukovaoci događajima ne izvršavaju se konkurentno, obrada odgovarajućih poruka ima jedinstveno ponašanje. Konkretno, postoje dva različita metoda za slanje poruka koje očekuju odgovor:
xpc_connection_send_message_with_reply: Ovde se XPC poruka prima i obrađuje na određenoj redi.
xpc_connection_send_message_with_reply_sync: Suprotno tome, u ovoj metodi, XPC poruka se prima i obrađuje na trenutnoj redi za raspodelu.
Ova razlika je ključna jer omogućava mogućnost da paketi odgovora budu obrađeni konkurentno sa izvršenjem XPC rukovaoca događajem. Imajte na umu da, iako _xpc_connection_set_creds implementira zaključavanje kako bi se zaštitilo od delimičnog prepisivanja audit tokena, ova zaštita se ne proširuje na ceo objekat veze. Kao rezultat, ovo stvara ranjivost gde audit token može biti zamenjen tokom intervala između obrade paketa i izvršenja njegovog rukovaoca događajem.
Da bi se iskoristila ova ranjivost, potrebna je sledeća postavka:
Dva mach servisa, nazvana A i B, oba od kojih mogu uspostaviti vezu.
Servis A treba da uključuje proveru autorizacije za specifičnu akciju koju samo B može izvršiti (korisnička aplikacija ne može).
Servis A treba da pošalje poruku koja očekuje odgovor.
Korisnik može poslati poruku B na koju će odgovoriti.
Proces eksploatacije uključuje sledeće korake:
Čekajte da servis A pošalje poruku koja očekuje odgovor.
Umesto da direktno odgovara A, port za odgovor se otima i koristi za slanje poruke servisu B.
Zatim se šalje poruka koja uključuje zabranjenu akciju, uz očekivanje da će biti obrađena konkurentno sa odgovorom iz B.
Below is a visual representation of the described attack scenario:
 (1) (1) (1) (1) (1) (1).png)
Difficulties in Locating Instances: Pretraga instanci xpc_connection_get_audit_token korišćenja bila je izazovna, kako statički tako i dinamički.
Methodology: Frida je korišćena za povezivanje funkcije xpc_connection_get_audit_token, filtrirajući pozive koji ne potiču iz rukovaoca događajem. Međutim, ova metoda je bila ograničena na povezani proces i zahtevala aktivnu upotrebu.
Analysis Tooling: Alati poput IDA/Ghidra korišćeni su za ispitivanje dostupnih mach servisa, ali je proces bio dugotrajan, otežan pozivima koji uključuju dyld deljenu keš memoriju.
Scripting Limitations: Pokušaji da se skriptuje analiza poziva xpc_connection_get_audit_token iz dispatch_async blokova bili su ometeni složenostima u analizi blokova i interakcijama sa dyld deljenom keš memorijom.
Reported Issues: Izveštaj je podnet Apple-u koji detaljno opisuje opšte i specifične probleme pronađene unutar smd.
Apple's Response: Apple je rešio problem u smd zamenom xpc_connection_get_audit_token sa xpc_dictionary_get_audit_token.
Nature of the Fix: Funkcija xpc_dictionary_get_audit_token se smatra sigurnom jer direktno preuzima audit token iz mach poruke vezane za primljenu XPC poruku. Međutim, nije deo javnog API-ja, slično kao xpc_connection_get_audit_token.
Absence of a Broader Fix: Ostaje nejasno zašto Apple nije implementirao sveobuhvatnije rešenje, kao što je odbacivanje poruka koje se ne poklapaju sa sačuvanim audit tokenom veze. Mogućnost legitimnih promena audit tokena u određenim scenarijima (npr. korišćenje setuid) može biti faktor.
Current Status: Problem i dalje postoji u iOS 17 i macOS 14, predstavljajući izazov za one koji žele da ga identifikuju i razumeju.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
