macOS xpc_connection_get_audit_token Attack
Vir verdere inligting, kyk na die oorspronklike pos: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Dit is 'n opsomming:
Mach Berigte Basiese Inligting
As jy nie weet wat Mach Berigte is nie, begin om hierdie bladsy te kyk:
macOS IPC - Inter Process CommunicationVir die oomblik onthou dat (definisie hier vandaan): Mach berigte word oor 'n mach poort gestuur, wat 'n enkele ontvanger, meerdere sender kommunikasie kanaal is wat in die mach kernel ingebou is. Meerdere prosesse kan berigte na 'n mach poort stuur, maar op enige punt kan slegs 'n enkele proses dit lees. Net soos lêer beskrywings en sokke, word mach poorte toegeken en bestuur deur die kernel en prosesse sien slegs 'n heelgetal, wat hulle kan gebruik om aan die kernel aan te dui watter van hul mach poorte hulle wil gebruik.
XPC Verbinding
As jy nie weet hoe 'n XPC verbinding gevestig word nie, kyk:
macOS XPCKwetsbaarheid Opsomming
Wat interessant is om te weet, is dat XPC se abstraksie 'n een-tot-een verbinding is, maar dit is gebaseer op 'n tegnologie wat meerdere senders kan hê, so:
Mach poorte is enkele ontvanger, meerdere sender.
'n XPC verbinding se audit token is die audit token van gekopieer van die mees onlangs ontvangde boodskap.
Om die audit token van 'n XPC verbinding te verkry, is krities vir baie veiligheidskontroles.
Alhoewel die vorige situasie belowend klink, is daar sommige scenario's waar dit nie probleme gaan veroorsaak nie (hier vandaan):
Audit tokens word dikwels gebruik vir 'n outorisering kontrole om te besluit of 'n verbinding aanvaar moet word. Aangesien dit gebeur deur 'n boodskap na die dienspoort te stuur, is daar nog geen verbinding gevestig nie. Meer boodskappe op hierdie poort sal net hanteer word as addisionele verbindingsversoeke. So enige kontroles voordat 'n verbinding aanvaar word, is nie kwesbaar nie (dit beteken ook dat binne
-listener:shouldAcceptNewConnection:
die audit token veilig is). Ons is dus op soek na XPC verbindings wat spesifieke aksies verifieer.XPC gebeurtenis hanteerders word sinchronies hanteer. Dit beteken dat die gebeurtenis hanteerder vir een boodskap voltooi moet wees voordat dit vir die volgende een aangeroep kan word, selfs op gelyktydige afleweringsqueues. So binne 'n XPC gebeurtenis hanteerder kan die audit token nie oorgeskryf word deur ander normale (nie-antwoorde!) boodskappe nie.
Twee verskillende metodes wat dalk uitgebuit kan word:
Variant1:
Eksploiteer verbinde na diens A en diens B
Diens B kan 'n bevoorregte funksionaliteit in diens A aanroep wat die gebruiker nie kan nie
Diens A roep
xpc_connection_get_audit_token
aan terwyl nie binne die gebeurtenis hanteerder vir 'n verbinding in 'ndispatch_async
.So 'n ander boodskap kan die Audit Token oorgeskryf omdat dit asynchrone gestuur word buite die gebeurtenis hanteerder.
Die eksploiteer gee aan diens B die SEND reg na diens A.
So diens B sal eintlik boodskappe na diens A stuur.
Die eksploiteer probeer om die bevoorregte aksie aan te roep. In 'n RC diens A kontroleer die outorisering van hierdie aksie terwyl diens B die Audit token oorgeskryf het (wat die eksploiteer toegang gee om die bevoorregte aksie aan te roep).
Variant 2:
Diens B kan 'n bevoorregte funksionaliteit in diens A aanroep wat die gebruiker nie kan nie
Eksploiteer verbind met diens A wat stuur die eksploiteer 'n boodskap wat 'n antwoord verwag in 'n spesifieke herhalings poort.
Eksploiteer stuur diens B 'n boodskap wat daardie antwoordpoort oorhandig.
Wanneer diens B antwoord, dit stuur die boodskap na diens A, terwyl die eksploiteer 'n ander boodskap na diens A stuur wat probeer om 'n bevoorregte funksionaliteit te bereik en verwag dat die antwoord van diens B die Audit token op die perfekte oomblik sal oorgeskryf (Race Condition).
Variant 1: aanroep xpc_connection_get_audit_token buite 'n gebeurtenis hanteerder
Scenario:
Twee mach dienste
A
enB
waartoe ons albei kan verbind (gebaseer op die sandbox profiel en die outorisering kontroles voordat die verbinding aanvaar word).A moet 'n outorisering kontrole hê vir 'n spesifieke aksie wat
B
kan oorhandig (maar ons app kan nie).Byvoorbeeld, as B sekere regte het of as root loop, kan dit hom toelaat om A te vra om 'n bevoorregte aksie uit te voer.
Vir hierdie outorisering kontrole,
A
verkry die audit token asynchrone, byvoorbeeld deurxpc_connection_get_audit_token
aan te roep vanafdispatch_async
.
In hierdie geval kan 'n aanvaller 'n Race Condition aktiveer wat 'n eksploiteer maak wat A vra om 'n aksie verskeie kere uit te voer terwyl hy B boodskappe na A
laat stuur. Wanneer die RC suksesvol is, sal die audit token van B in geheue gekopieer word terwyl die versoek van ons eksploiteer deur A hanteer word, wat dit toegang gee tot die bevoorregte aksie wat slegs B kon aanvra.
Dit het gebeur met A
as smd
en B
as diagnosticd
. Die funksie SMJobBless
van smb kan gebruik word om 'n nuwe bevoorregte helper gereedskap te installeer (as root). As 'n proses wat as root loop smd kontak, sal geen ander kontroles uitgevoer word nie.
Daarom is die diens B diagnosticd
omdat dit as root loop en gebruik kan word om 'n proses te monitor, so sodra monitering begin het, sal dit meerdere boodskappe per sekonde stuur.
Om die aanval uit te voer:
Begin 'n verbinding na die diens genaamd
smd
met behulp van die standaard XPC protokol.Vorm 'n sekondêre verbinding na
diagnosticd
. In teenstelling met die normale prosedure, eerder as om twee nuwe mach poorte te skep en te stuur, word die kliëntpoort stuurreg vervang met 'n duplikaat van die stuurreg geassosieer met diesmd
verbinding.As gevolg hiervan kan XPC boodskappe na
diagnosticd
gestuur word, maar antwoorde vandiagnosticd
word hergeroute nasmd
. Virsmd
lyk dit asof die boodskappe van beide die gebruiker endiagnosticd
van dieselfde verbinding afkomstig is.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsector7.computest.nl%2Fpost%2F2023-10-xpc-audit-token-spoofing%2Fexploit.png&width=768&dpr=4&quality=100&sign=3f6bbe07&sv=1)
Die volgende stap behels om
diagnosticd
te instrueer om monitering van 'n gekose proses (potensieel die gebruiker se eie) te begin. Gelyktydig word 'n vloed van roetine 1004 boodskappe nasmd
gestuur. Die bedoeling hier is om 'n gereedskap met verhoogde regte te installeer.Hierdie aksie aktiveer 'n race condition binne die
handle_bless
funksie. Die tydsberekening is krities: diexpc_connection_get_pid
funksie aanroep moet die PID van die gebruiker se proses teruggee (aangesien die bevoorregte gereedskap in die gebruiker se app bundel is). Maar diexpc_connection_get_audit_token
funksie, spesifiek binne dieconnection_is_authorized
subroutine, moet die audit token wat aandiagnosticd
behoort, verwys.
Variant 2: antwoord herleiding
In 'n XPC (Cross-Process Communication) omgewing, alhoewel gebeurtenis hanteerders nie gelyktydig uitvoer nie, het die hantering van antwoord boodskappe 'n unieke gedrag. Spesifiek bestaan daar twee verskillende metodes om boodskappe te stuur wat 'n antwoord verwag:
xpc_connection_send_message_with_reply
: Hier word die XPC boodskap ontvang en verwerk op 'n aangewese queue.xpc_connection_send_message_with_reply_sync
: Omgekeerd, in hierdie metode, word die XPC boodskap ontvang en verwerk op die huidige afleweringsqueue.
Hierdie onderskeid is belangrik omdat dit die moontlikheid toelaat van antwoord pakkette wat gelyktydig geparseer word met die uitvoering van 'n XPC gebeurtenis hanteerder. Opmerklik is dat terwyl _xpc_connection_set_creds
wel vergrendeling implementeer om teen die gedeeltelike oorgeskryf van die audit token te beskerm, strek dit nie hierdie beskerming na die hele verbinding objek nie. Gevolglik skep dit 'n kwesbaarheid waar die audit token vervang kan word gedurende die interval tussen die parsing van 'n pakket en die uitvoering van sy gebeurtenis hanteerder.
Om hierdie kwesbaarheid uit te buit, is die volgende opstelling nodig:
Twee mach dienste, genoem
A
enB
, wat albei 'n verbinding kan vestig.Diens
A
moet 'n outorisering kontrole insluit vir 'n spesifieke aksie wat slegsB
kan uitvoer (die gebruiker se toepassing kan nie).Diens
A
moet 'n boodskap stuur wat 'n antwoord verwag.Die gebruiker kan 'n boodskap na
B
stuur wat dit sal antwoord.
Die eksploitasie proses behels die volgende stappe:
Wag vir diens
A
om 'n boodskap te stuur wat 'n antwoord verwag.In plaas daarvan om direk aan
A
te antwoord, word die antwoordpoort gekaap en gebruik om 'n boodskap na diensB
te stuur.Vervolgens word 'n boodskap wat die verbode aksie behels, gestuur, met die verwagting dat dit gelyktydig verwerk sal word met die antwoord van
B
.
Hieronder is 'n visuele voorstelling van die beskryfde aanval scenario:
![https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/variant2.png](../../../../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png)
Ontdekking Probleme
Moeilikhede om Voorbeelde te Vind: Soek na voorbeelde van
xpc_connection_get_audit_token
gebruik was uitdagend, beide staties en dinamies.Metodologie: Frida is gebruik om die
xpc_connection_get_audit_token
funksie te haak, wat oproepe gefilter het wat nie van gebeurtenis hanteerders afkomstig was nie. Hierdie metode was egter beperk tot die gehaakte proses en het aktiewe gebruik vereis.Analise Gereedskap: Gereedskap soos IDA/Ghidra is gebruik om bereikbare mach dienste te ondersoek, maar die proses was tydrowend, bemoeilik deur oproepe wat die dyld gedeelde kas betrek.
Scripting Beperkings: Pogings om die analise te script vir oproepe na
xpc_connection_get_audit_token
vandispatch_async
blokke was belemmer deur kompleksiteite in die parsing van blokke en interaksies met die dyld gedeelde kas.
Die oplossing
Gerapporteerde Probleme: 'n Verslag is aan Apple ingedien wat die algemene en spesifieke probleme wat in
smd
gevind is, uiteengesit het.Apple se Antwoord: Apple het die probleem in
smd
aangespreek deurxpc_connection_get_audit_token
metxpc_dictionary_get_audit_token
te vervang.Natuur van die Oplossing: Die
xpc_dictionary_get_audit_token
funksie word beskou as veilig aangesien dit die audit token direk van die mach boodskap wat aan die ontvangde XPC boodskap gekoppel is, verkry. Dit is egter nie deel van die publieke API nie, soortgelyk aanxpc_connection_get_audit_token
.Afwesigheid van 'n Breër Oplossing: Dit bly onduidelik waarom Apple nie 'n meer omvattende oplossing geïmplementeer het nie, soos om boodskappe wat nie ooreenstem met die gespaarde audit token van die verbinding nie, te verwerp. Die moontlikheid van legitieme audit token veranderinge in sekere scenario's (bv.
setuid
gebruik) mag 'n faktor wees.Huidige Status: Die probleem bestaan voort in iOS 17 en macOS 14, wat 'n uitdaging vir diegene wat dit wil identifiseer en verstaan.
Last updated