macOS xpc_connection_get_audit_token Attack

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

• Ako želite da vidite svoju kompaniju reklamiranu na HackTricks-u ili da preuzmete HackTricks u PDF formatu proverite PLANOVE ZA PRIJAVU!

• Nabavite zvanični PEASS & HackTricks swag

• Otkrijte Porodicu PEASS, našu kolekciju ekskluzivnih NFT-ova

• Pridružite se 💬 Discord grupi ili telegram grupi ili nas pratite na Twitteru 🐦 @carlospolopm.

• Podelite svoje hakovanje trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.

Za dodatne informacije pogledajte originalni post: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Ovo je sažetak:

Osnovne informacije o Mach porukama

Ako ne znate šta su Mach poruke, počnite sa proverom ove stranice:

pagemacOS IPC - Inter Process Communication

Za sada zapamtite da (definicija sa ovog mesta): Mach poruke se šalju preko mach porta, koji je kanal komunikacije sa jednim primaocem, više pošiljalaca ugrađen u mach kernel. Više procesa može slati poruke ka mach portu, ali u bilo kom trenutku samo jedan proces može čitati iz njega. Baš kao i deskriptori fajlova 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 njihovih mach portova žele da koriste.

XPC Veza

Ako ne znate kako se uspostavlja XPC veza, proverite:

pagemacOS XPC

Sumiranje ranjivosti

Ono što je za vas zanimljivo da znate je da je apstrakcija XPC-a jedna-na-jedan veza, ali se zasniva na tehnologiji koja može imati više pošiljalaca, tako da:

• Mach portovi su jedan primaoc, više pošiljalaca.

• Audit token XPC veze je audit token kopiran iz najskorije primljene poruke.

• Dobijanje audit tokena XPC veze je ključno za mnoge bezbednosne provere.

Iako prethodna situacija zvuči obećavajuće, postoje neki scenariji gde to neće izazvati probleme (sa ovog mesta):

• Audit tokeni se često koriste za proveru autorizacije kako bi se odlučilo da li prihvatiti vezu. Pošto se ovo dešava korišćenjem poruke ka servis portu, veza još uvek nije uspostavljena. Više poruka na ovom portu će biti tretirano kao dodatni zahtevi za vezu. Dakle, bilo kakve provere pre prihvatanja veze nisu ranjive (ovo takođe znači da je unutar -listener:shouldAcceptNewConnection: audit token siguran). Mi stoga tražimo XPC veze koje verifikuju specifične akcije.

• XPC event handleri se obrađuju sinhrono. Ovo znači da event handler 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 event handlera audit token ne može biti prepisan od strane drugih normalnih (ne-reply!) poruka.

Dva različita načina na koje ovo može biti iskorišćeno:

1. Varijanta 1:

• Eksploit se povezuje sa servisom A i servisom B

• Servis B može pozvati privilegovanu funkcionalnost u servisu A koju korisnik ne može

• Servis A poziva xpc_connection_get_audit_token dok nije unutar event handlera za vezu u dispatch_async.

• Tako da različita poruka može prepisati Audit Token jer se šalje asinhrono van event handlera.

• Eksploit prosleđuje servisu B SEND pravo ka servisu A.

• Dakle, svc B će zapravo slati poruke servisu A.

• Eksploit pokušava da pozove privilegovanu akciju. U RC svc A proverava autorizaciju ove akcije dok je svc B prepisao Audit token (dajući eksploatatoru pristup da pozove privilegovanu akciju).

2. Varijanta 2:

• Servis B može pozvati privilegovanu funkcionalnost u servisu A koju korisnik ne može

• Eksploit se povezuje sa servisom A koji šalje eksploatatoru poruku očekujući odgovor na određenom replay portu.

• Eksploit šalje servisu B poruku prosleđujući taj replay port.

• Kada servis B odgovori, on šalje poruku servisu A, dok eksploit šalje drugu poruku servisu A pokušavajući da dostigne privilegovanu funkcionalnost i očekujući da će odgovor od servisa B prepisati Audit token u savršenom trenutku (Race Condition).

Varijanta 1: pozivanje xpc_connection_get_audit_token van event handlera

Scenario:

• Dva mach servisa A i B sa kojima možemo oboje da se povežemo (bazirano na profilu peska i autorizacionim proverama pre prihvatanja veze).

• A mora imati autorizacionu proveru za specifičnu akciju koju B može proslediti (ali naša aplikacija ne može).

• Na primer, ako B ima neka ovlašćenja ili se izvršava kao root, to bi mu moglo dozvoliti da zatraži od A da izvrši privilegovanu akciju.

• Za ovu autorizacionu proveru, A asinhrono dobija audit token, na primer pozivajući xpc_connection_get_audit_token iz dispatch_async.

U ovom slučaju napadač bi mogao da pokrene Race Condition praveći eksploit koji traži od A da izvrši akciju više puta dok B šalje poruke ka A. Kada RC bude uspešan, audit token B će biti kopiran u memoriju dok zahtev našeg eksploita bude obrađen od strane A, dajući mu pristup privilegovanoj akciji koju je samo B mogao zatražiti.

Ovo se desilo sa A kao smd i B kao diagnosticd. Funkcija SMJobBless iz smb može se koristiti za instaliranje novog privilegovanog pomoćnog alata (kao root). Ako proces koji se izvršava kao root kontaktira smd, neće biti izvršene druge provere.

Stoga, servis B je diagnosticd jer se izvršava kao root i može se koristiti za monitorisanje procesa, tako da kada se monitorisanje pokrene, šaljeće više poruka u sekundi.

Za izvođenje napada:

1. Inicirajte vezu sa servisom nazvanim smd koristeći standardni XPC protokol.

2. Formirajte sekundarnu vezu sa diagnosticd. Suprotno normalnom postupku, umesto kreiranja i slanja dva nova mach porta, pravo slanja klijenta se zamenjuje sa duplikatom send righta povezanog sa vezom smd.

3. Kao rezultat, XPC poruke mogu biti prosleđene diagnosticd, ali odgovori od diagnosticd se preusmeravaju na smd. Za smd, izgleda kao da poruke od korisnika i diagnosticd potiču od iste veze.

Slika koja prikazuje proces eksploatacije

4. Sledeći korak uključuje instrukciju diagnosticd-u da pokrene praćenje izabranog procesa (potencijalno korisnikovog). Istovremeno, šalje se poplava rutinskih 1004 poruka smd. Cilj ovde je instalirati alat sa povišenim privilegijama.

5. Ova radnja pokreće trku za stanje unutar funkcije handle_bless. Vreme je ključno: poziv funkcije xpc_connection_get_pid mora vratiti PID procesa korisnika (jer privilegovani alat se nalazi u korisnikovom paketu aplikacije). Međutim, funkcija xpc_connection_get_audit_token, posebno unutar podrutine connection_is_authorized, mora se odnositi na audit token koji pripada diagnosticd.

Varijanta 2: prosleđivanje odgovora

U XPC (Cross-Process Communication) okruženju, iako rukovaoci događajima ne izvršavaju istovremeno, obrada odgovora poruka ima jedinstveno ponašanje. Konkretno, postoje dva različita metoda za slanje poruka koje očekuju odgovor:

1. xpc_connection_send_message_with_reply: Ovde se XPC poruka prima i obrađuje na određenom redu.

2. xpc_connection_send_message_with_reply_sync: Nasuprot tome, u ovom metodu, XPC poruka se prima i obrađuje na trenutnom redu dispečovanja.

Ova razlika je ključna jer omogućava mogućnost paralelnog parsiranja odgovarajućih paketa sa izvršavanjem rukovaoca događajima XPC. Važno je napomenuti da, iako _xpc_connection_set_creds implementira zaključavanje radi zaštite od delimičnog prepisivanja audit tokena, ova zaštita se ne proširuje na ceo objekat veze. Kao rezultat, stvara se ranjivost gde audit token može biti zamenjen tokom intervala između parsiranja paketa i izvršavanja njegovog rukovaoca događajima.

Da bi se iskoristila ova ranjivost, potrebno je sledeće podešavanje:

• Dve mach usluge, nazvane A i B, obe koje mogu uspostaviti vezu.

• Usluga A treba da uključi proveru autorizacije za određenu radnju koju samo B može izvršiti (aplikacija korisnika ne može).

• Usluga A treba da pošalje poruku koja očekuje odgovor.

• Korisnik može poslati poruku B na koju će odgovoriti.

Proces iskorišćavanja ove ranjivosti uključuje sledeće korake:

1. Sačekati da usluga A pošalje poruku koja očekuje odgovor.

2. Umesto direktnog odgovora na A, priključuje se i koristi se port za slanje poruke usluzi B.

3. Zatim se šalje poruka koja uključuje zabranjenu radnju, sa očekivanjem da će biti obrađena istovremeno sa odgovorom od B.

Ispod je vizuelna reprezentacija opisanog scenarija napada:

 (1) (1) (1) (1) (1) (1).png)

Problemi sa otkrivanjem

• Teškoće u Lociranju Instanci: Pretraga instanci korišćenja xpc_connection_get_audit_token bila je izazovna, kako statički tako i dinamički.

• Metodologija: Frida je korišćena za hakovanje funkcije xpc_connection_get_audit_token, filtrirajući pozive koji ne potiču od rukovaoca događajima. Međutim, ovaj metod je bio ograničen na hakovan proces i zahtevao je aktivnu upotrebu.

• Alati za Analizu: Alati poput IDA/Ghidra korišćeni su za ispitivanje dostupnih mach usluga, ali je proces bio dugotrajan, otežan pozivima koji uključuju dyld deljeni keš.

• Ograničenja Skriptovanja: Pokušaji skriptovanja analize poziva xpc_connection_get_audit_token iz dispatch_async blokova bili su ometani složenostima u parsiranju blokova i interakcijama sa dyld deljenim kešom.

Popravka

• Prijavljene Probleme: Izveštaj je dostavljen Apple-u detaljno opisujući opšte i specifične probleme pronađene unutar smd.

• Odgovor Apple-a: Apple je adresirao problem u smd zamenivši xpc_connection_get_audit_token sa xpc_dictionary_get_audit_token.

• Priroda Popravke: Funkcija xpc_dictionary_get_audit_token smatra se sigurnom jer direktno dobavlja 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.

• Odsustvo Šire Popravke: Ostaje nejasno zašto Apple nije implementirao sveobuhvatniju popravku, poput odbacivanja poruka koje se ne podudaraju sa sačuvanim audit tokenom veze. Moguće je da je faktor mogućnost legitimnih promena audit tokena u određenim scenarijima (npr. korišćenje setuid).

• Trenutni Status: Problem i dalje postoji u iOS 17 i macOS 14, predstavljajući izazov za one koji pokušavaju da ga identifikuju i razumeju.