macOS xpc_connection_get_audit_token Attack

Reading time: 9 minutes

Za više informacija pogledajte originalni post: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Ovo je sažetak:

Mach Messages Basic Info

Ako ne znate šta su Mach Messages, počnite da proveravate ovu stranicu:

macOS IPC - Inter Process Communication

Za sada zapamtite da (definicija odavde):
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 sa 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.

XPC Connection

Ako ne znate kako se uspostavlja XPC veza, proverite:

macOS XPC

Vuln Summary

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

• Mach portovi su jedini prijemnik, više pošiljalaca.
• Audit token XPC veze je audit token kopiran iz najnovije primljene poruke.
• Dobijanje audit token-a XPC veze je ključno za mnoge provere bezbednosti.

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

• Audit tokeni se često koriste za proveru autorizacije da bi se odlučilo da li da se prihvati veza. Kako se to dešava korišćenjem poruke 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 je unutar -listener:shouldAcceptNewConnection: audit token siguran). Stoga tražimo XPC veze koje verifikuju specifične akcije.
• XPC rukovaoci događaja se obrađuju sinhrono. To znači da rukovalac događaja 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đaja audit token ne može biti prepisan drugim normalnim (ne-odgovor!) porukama.

Dve različite metode koje bi mogle biti iskoristive:

1. 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đaja za vezu u dispatch_async.
• Tako bi druga poruka mogla prepisati Audit Token jer se šalje asinhrono van rukovaoca događaja.
• 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).

2. 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).

Variant 1: calling xpc_connection_get_audit_token outside of an event handler

Scenario:

• Dva mach servisa A i B na koje se možemo povezati (na osnovu sandbox profila 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.

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 je servis B 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:

1. Inicirajte vezu sa servisom nazvanim smd koristeći standardni XPC protokol.
2. Formirajte sekundarnu vezu sa diagnosticd. Suprotno normalnoj proceduri, umesto da kreirate i šaljete dva nova mach porta, pravo slanja klijentskog porta se zamenjuje duplikatom prava slanja povezanog sa smd vezom.
3. Kao rezultat, XPC poruke mogu biti poslati diagnosticd, ali odgovori od diagnosticd se preusmeravaju na smd. Za smd, izgleda kao da poruke od korisnika i diagnosticd potiču iz iste veze.

4. Sledeći korak uključuje davanje instrukcija diagnosticd da započne praćenje odabranog procesa (potencijalno korisnikovog). Paralelno, poplava rutinskih 1004 poruka se šalje smd. Cilj ovde je instalirati alat sa povišenim privilegijama.
5. Ova akcija pokreće trku 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.

Variant 2: reply forwarding

U XPC (Međuprocesna komunikacija) okruženju, iako rukovaoci događaja ne izvršavaju se konkurentno, obrada odgovarajućih poruka ima jedinstveno ponašanje. Konkretno, postoje dve različite metode za slanje poruka koje očekuju odgovor:

1. xpc_connection_send_message_with_reply: Ovde se XPC poruka prima i obrađuje na određenoj redi.
2. 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đaja. 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, to stvara ranjivost gde audit token može biti zamenjen tokom intervala između obrade paketa i izvršenja njegovog rukovaoca događaja.

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:

1. Sačekajte da servis A pošalje poruku koja očekuje odgovor.
2. Umesto da direktno odgovara A, port za odgovor se otima i koristi za slanje poruke servisu B.
3. Zatim se šalje poruka koja uključuje zabranjenu akciju, sa očekivanjem da će biti obrađena konkurentno sa odgovorom od B.

Ispod je vizuelna reprezentacija opisane napadačke situacije:

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

Discovery Problems

• Teškoće u pronalaženju 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 povezivanje funkcije xpc_connection_get_audit_token, filtrirajući pozive koji ne potiču iz rukovaoca događaja. Međutim, ova metoda je bila ograničena na povezani proces i zahtevala je aktivnu upotrebu.
• Analitički alati: 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.
• Ograničenja skriptiranja: Pokušaji skriptiranja analize za pozive xpc_connection_get_audit_token iz dispatch_async blokova bili su ometeni složenošću u analizi blokova i interakcijama sa dyld deljenom keš memorijom.

The fix

• Prijavljeni problemi: Izveštaj je dostavljen Apple-u koji detaljno opisuje opšte i specifične probleme pronađene unutar smd.
• Apple-ov odgovor: Apple je rešio problem u smd zamenom xpc_connection_get_audit_token sa xpc_dictionary_get_audit_token.
• Priroda rešenja: 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.
• Odsustvo šireg rešenja: 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.
• Trenutni status: Problem i dalje postoji u iOS 17 i macOS 14, predstavljajući izazov za one koji žele da ga identifikuju i razumeju.