macOS xpc_connection_get_audit_token Attack
Kwa habari zaidi angalia chapisho la asili: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Hii ni muhtasari:
Taarifa Msingi za Ujumbe wa Mach
Ikiwa haujui ni nini Ujumbe wa Mach anza kwa kuangalia ukurasa huu:
pagemacOS IPC - Inter Process CommunicationKwa sasa kumbuka kwamba (ufafanuzi kutoka hapa): Ujumbe wa Mach hutumwa juu ya mach port, ambayo ni njia ya mawasiliano ya mpokeaji mmoja, wapelekaji wengi iliyojengwa ndani ya kernel ya mach. Michakato mingi inaweza kutuma ujumbe kwa mach port, lakini wakati wowote mchakato mmoja tu unaweza kusoma kutoka kwake. Kama vile vitambulisho vya faili na soketi, mach ports hupewa na kusimamiwa na kernel na michakato huona nambari tu, ambayo wanaweza kutumia kuashiria kernel ni mach ports yao wanayotaka kutumia.
Uunganisho wa XPC
Ikiwa haujui jinsi uhusiano wa XPC unavyoundwa angalia:
pagemacOS XPCMuhtasari wa Upungufu
Jambo linalovutia kujua ni kwamba kuhakikisha ya XPC ni uhusiano wa moja kwa moja, lakini inategemea teknolojia ambayo inaweza kuwa na wapelekaji wengi, hivyo:
Mach ports ni mpokeaji mmoja, wapelekaji wengi.
Audit token ya uhusiano wa XPC ni token ya ukaguzi wa iliyochukuliwa kutoka ujumbe uliopokelewa hivi karibuni zaidi.
Kupata audit token ya uhusiano wa XPC ni muhimu kwa uchunguzi wa usalama mengi.
Ingawa hali iliyopita inaonekana kuahidi kuna hali ambapo hii haitasababisha matatizo (kutoka hapa):
Tokeni za ukaguzi mara nyingi hutumiwa kwa ukaguzi wa idhini kuamua ikiwa kukubali uhusiano. Kwa kuwa hii hufanyika kwa kutumia ujumbe kwa bandari ya huduma, hakuna uhusiano ulioanzishwa bado. Ujumbe zaidi kwenye bandari hii utashughulikiwa kama maombi ya uhusiano ya ziada. Kwa hivyo uchunguzi kabla ya kukubali uhusiano sio hatarini (hii pia inamaanisha kuwa ndani ya
-listener:shouldAcceptNewConnection:
tokeni ya ukaguzi ni salama). Kwa hivyo tunatafuta uhusiano wa XPC ambao huthibitisha hatua maalum.Wachambuzi wa matukio ya XPC hushughulikiwa kwa usawazishaji. Hii inamaanisha kuwa mchambuzi wa tukio kwa ujumbe mmoja lazima ukamilike kabla ya kuita kwa ujumbe ufuatao, hata kwenye foleni za kutuma wakati mmoja. Kwa hivyo ndani ya mchambuzi wa tukio la XPC tokeni ya ukaguzi haiwezi kubadilishwa na ujumbe wa kawaida (si-jibu!) mwingine.
Kuna njia mbili tofauti ambazo hii inaweza kutumika:
Variant1:
Shambulio linajiunga na huduma A na huduma B
Huduma B inaweza kuita kazi ya kipekee katika huduma A ambayo mtumiaji hawezi
Huduma A inaita
xpc_connection_get_audit_token
wakati si ndani ya mchambuzi wa tukio kwa uhusiano katikadispatch_async
.Kwa hivyo ujumbe tofauti unaweza kubadilisha Audit Token kwa sababu unatuma kwa njia ya asinkronasi nje ya mchambuzi wa tukio.
Shambulio linapitisha huduma B haki ya KUTUMA kwa huduma A.
Kwa hivyo svc B itakuwa kutuma ujumbe kwa huduma A.
Shambulio jaribu kuita hatua ya kipekee. Katika RC svc A huthibitisha idhini ya hatua hii wakati svc B ilibadilisha Tokeni ya Ukaguzi (ikimpa shambulio upatikanaji wa kuita hatua ya kipekee).
Variant 2:
Huduma B inaweza kuita kazi ya kipekee katika huduma A ambayo mtumiaji hawezi
Shambulio linajiunga na huduma A ambayo inatuma shambulio ujumbe ukitarajia jibu katika bandari ya majibu maalum.
Shambulio inatuma huduma B ujumbe ukipitisha ile bandari ya majibu.
Wakati huduma B inajibu, inatuma ujumbe kwa huduma A, wakati shambulio inatuma ujumbe tofauti kwa huduma A kujaribu kufikia kazi ya kipekee na kutarajia kwamba jibu kutoka kwa huduma B litabadilisha Tokeni ya Ukaguzi katika wakati kamili (Hali ya Mashindano).
Variant 1: kuita xpc_connection_get_audit_token nje ya mchambuzi wa tukio
Skena:
Huduma mbili za mach
A
naB
ambazo tunaweza kujiunga nazo (kulingana na wasifu wa sanduku la mchanga na ukaguzi kabla ya kukubali uhusiano).A lazima awe na ukaguzi wa idhini kwa hatua maalum ambayo
B
inaweza kupitisha (lakini programu yetu haiwezi).Kwa mfano, ikiwa B ana haki za kibali au inaendeshwa kama root, inaweza kumruhusu kuuliza A kutekeleza hatua ya kipekee.
Kwa ukaguzi huu wa idhini,
A
inapata tokeni ya ukaguzi kwa njia ya asinkronasi, kwa mfano kwa kuitaxpc_connection_get_audit_token
kutokadispatch_async
.
Katika kesi hii, muhusika anaweza kusababisha Hali ya Mashindano kufanya shambulio ambalo linaiomba A kutekeleza hatua mara kadhaa wakati B inatuma ujumbe kwa A
. Wakati RC inafanikiwa, tokeni ya ukaguzi ya B itachapishwa kumbukumbu wakati ombi la shambulio letu linashughulikiwa na A, ikimpa upatikanaji wa hatua ya kipekee ambayo B pekee angeweza kuomba.
Hii ilitokea na A
kama smd
na B
kama diagnosticd
. Kazi SMJobBless
kutoka smb inaweza kutumika kufunga zana mpya ya msaidizi yenye mamlaka (kama root). Ikiwa mchakato unaoendeshwa kama root unawasiliana na smd, hakuna ukaguzi mwingine utafanywa.
Kwa hivyo, huduma B ni diagnosticd
kwa sababu inaendeshwa kama root na inaweza kutumika kufuatilia mchakato, kwa hivyo mara tu ufuatiliaji umeanza, itaanza kutuma ujumbe mara nyingi kwa sekunde.
Kufanya shambulio:
Anzisha uhusiano kwa huduma iliyoitwa
smd
kwa kutumia itifaki ya XPC ya kawaida.Unda uhusiano wa pili kwa
diagnosticd
. Tofauti na utaratibu wa kawaida, badala ya kuunda na kutuma mach ports mbili mpya, haki ya kutuma ya bandari ya mteja inabadilishwa na nakala ya haki ya kutuma inayohusishwa na uhusiano wasmd
.Kama matokeo, ujumbe wa XPC unaweza kutumwa kwa
diagnosticd
, lakini majibu kutokadiagnosticd
yanaelekezwa tena kwasmd
. Kwasmd
, inaonekana kana kwamba ujumbe kutoka kwa mtumiaji nadiagnosticd
unatoka kwa uhusiano mmoja.
Hatua inayofuata ni kuagiza
diagnosticd
kuanzisha ufuatiliaji wa mchakato uliochaguliwa (labda wa mtumiaji mwenyewe). Kwa wakati huo huo, mafuriko ya ujumbe wa kawaida wa 1004 hutumwa kwasmd
. Lengo hapa ni kufunga zana yenye mamlaka.Hatua hii inachochea hali ya mashindano ndani ya kazi ya
handle_bless
. Wakati ni muhimu: wito wa kazi yaxpc_connection_get_pid
lazima irudishe PID ya mchakato wa mtumiaji (kwa kuwa zana yenye mamlaka iko kwenye mfuko wa programu ya mtumiaji). Walakini, wito wa kazi yaxpc_connection_get_audit_token
, hasa ndani ya subroutine yaconnection_is_authorized
, lazima itaje alama ya ukaguzi inayomilikiwa nadiagnosticd
.
Tofauti 2: kusonga majibu
Katika mazingira ya XPC (Mawasiliano kati ya Mchakato), ingawa wakusanyaji wa matukio hawatekelezi kwa wakati mmoja, kushughulikia ujumbe wa majibu kuna tabia ya kipekee. Kwa kusudi hili, kuna njia mbili tofauti za kutuma ujumbe unaotarajia majibu:
xpc_connection_send_message_with_reply
: Hapa, ujumbe wa XPC unapokelewa na kusindika kwenye foleni iliyoteuliwa.xpc_connection_send_message_with_reply_sync
: Kinyume chake, kwenye njia hii, ujumbe wa XPC unapokelewa na kusindika kwenye foleni ya kutolewa ya sasa.
Tofauti hii ni muhimu kwa sababu inaruhusu uwezekano wa pakiti za majibu kuchambuliwa kwa wakati mmoja na utekelezaji wa kusindika wa tukio la XPC. Hasa, wakati _xpc_connection_set_creds
inatekeleza kufunga ili kulinda dhidi ya kubadilisha sehemu ya alama ya ukaguzi, haitoi ulinzi huu kwa kitu cha uhusiano mzima. Kwa hivyo, hii inaunda udhaifu ambapo alama ya ukaguzi inaweza kubadilishwa wakati wa kipindi kati ya kuchambua kwa pakiti na utekelezaji wa kusindika tukio lake.
Kutumia udhaifu huu, usanidi ufuatao unahitajika:
Huduma mbili za mach, zinazojulikana kama
A
naB
, zote ambazo zinaweza kuanzisha uhusiano.Huduma
A
inapaswa kujumuisha ukaguzi wa idhini kwa hatua maalum ambayo tuB
inaweza kutekeleza (programu ya mtumiaji haiwezi).Huduma
A
inapaswa kutuma ujumbe unaotarajia majibu.Mtumiaji anaweza kutuma ujumbe kwa
B
ambao itajibu.
Mchakato wa kutumia udhaifu huu unajumuisha hatua zifuatazo:
Subiri huduma
A
itume ujumbe unaotarajia majibu.Badala ya kujibu moja kwa moja
A
, bandari ya majibu inatekwa na kutumika kutuma ujumbe kwa hudumaB
.Kisha, ujumbe unaojumuisha hatua iliyozuiliwa unatuma, ukitarajia kwamba utasindika kwa wakati mmoja na jibu kutoka
B
.
Hapa chini ni uwakilishi wa picha wa mazingira ya shambulio yaliyoelezwa:
![https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/variant2.png](../../../../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png)
Matatizo ya Ugunduzi
Vikwazo katika Kutambua Mifano: Kutafuta mifano ya matumizi ya
xpc_connection_get_audit_token
ilikuwa changamoto, kwa njia za kistatiki na kidinamiki.Mbinu: Frida ilitumika kufunga kazi ya
xpc_connection_get_audit_token
, ikichuja wito usiotoka kwa wakusanyaji wa matukio. Walakini, njia hii ilikuwa imezuiliwa kwa mchakato uliofungwa na ilihitaji matumizi ya moja kwa moja.Zana za Uchambuzi: Zana kama IDA/Ghidra zilitumika kuchunguza huduma za mach zinazopatikana, lakini mchakato ulichukua muda mrefu, uliogumuza na wito unaohusisha akiba ya pamoja ya dyld.
Vikwazo vya Uandishi wa Script: Jaribio la kuandika skripti ya uchambuzi kwa wito wa
xpc_connection_get_audit_token
kutoka kwa vitengo vyadispatch_async
lilizuiliwa na ugumu katika kuchambua vitengo na mwingiliano na akiba ya pamoja ya dyld.
Marekebisho
Masuala Yaliyoripotiwa: Ripoti ilitumwa kwa Apple ikielezea masuala ya jumla na maalum yaliyopatikana ndani ya
smd
.Jibu la Apple: Apple ilishughulikia suala katika
smd
kwa kubadilishaxpc_connection_get_audit_token
naxpc_dictionary_get_audit_token
.Asili ya Marekebisho: Kazi ya
xpc_dictionary_get_audit_token
inachukuliwa kuwa salama kwani inapata alama ya ukaguzi moja kwa moja kutoka kwa ujumbe wa mach unaoambatana na ujumbe wa XPC uliopokelewa. Walakini, sio sehemu ya API ya umma, kamaxpc_connection_get_audit_token
.Ukosefu wa Marekebisho Kamili: Bado haijulikani kwa nini Apple haikutekeleza marekebisho kamili zaidi, kama kutupa ujumbe usioendana na alama ya ukaguzi iliyohifadhiwa ya uhusiano. Uwezekano wa mabadiliko halali ya alama ya ukaguzi katika hali fulani (k.m., matumizi ya
setuid
) inaweza kuwa sababu.Hali ya Sasa: Suala hili linaendelea kuwepo katika iOS 17 na macOS 14, likiwa changamoto kwa wale wanaotafuta kugundua na kuelewa.
Last updated