WWW2Exec - .dtors & .fini_array
.dtors
Leo ni kawaida sana kupata binary na sehemu ya .dtors!
Waharibifu ni kazi ambazo hutekelezwa kabla ya programu kukamilika (baada ya kazi ya main
kurejea).
Anwani za kazi hizi zimehifadhiwa ndani ya sehemu ya .dtors
ya binary na kwa hivyo, ikiwa utaweza kuandika anwani ya shellcode katika __DTOR_END__
, hiyo itatekelezwa kabla ya programu kukamilika.
Pata anwani ya sehemu hii na:
Kawaida utapata alama za DTOR kati ya thamani ffffffff
na 00000000
. Kwa hivyo ikiwa unaona thamani hizo tu, inamaanisha kwamba hakuna kazi iliyosajiliwa. Kwa hivyo badilisha 00000000
na anwani ya shellcode ili kuitekeleza.
Kwa hakika, kwanza unahitaji kupata mahali pa kuhifadhi shellcode ili baadaye uweze kuita.
.fini_array
Kimsingi hii ni muundo na kazi ambazo zitaitwa kabla ya programu kukamilika, kama .dtors
. Hii ni ya kuvutia ikiwa unaweza kuita shellcode yako kwa kuruka kwenye anwani, au katika hali ambapo unahitaji kurudi kwa main
tena ili kutumia udhaifu mara ya pili.
Tafadhali kumbuka kwamba wakati kazi kutoka kwa .fini_array
inatekelezwa inahamia kwa ile inayofuata, hivyo haitatekelezwa mara kadhaa (kuzuia mizunguko ya milele), lakini pia itakupa tu utekelezaji wa kazi moja iliyowekwa hapa.
Tafadhali kumbuka kuwa vipengele katika .fini_array
huitwa kwa mpangilio wa nyuma, hivyo labda unataka kuanza kuandika kutoka kwa ya mwisho.
Mzunguko wa Milele
Ili kutumia .fini_array
kupata mzunguko wa milele unaweza angalia kilichofanywa hapa: Ikiwa una angalau vipengele 2 katika .fini_array
, unaweza:
Tumia andika yako ya kwanza kuita kazi ya andika ya kupindukia isiyo na kinga tena
Kisha, hesabu anwani ya kurudi kwenye rundo iliyohifadhiwa na
__libc_csu_fini
(kazi inayoitwa na.fini_array
zote) na weka huko anwani ya__libc_csu_fini
Hii itafanya
__libc_csu_fini
kuita yenyewe tena ikitekeleza tena kazi za.fini_array
ambazo zitaita kazi ya WWW isiyokuwa na kinga mara 2: moja kwa andika ya kupindukia na nyingine kwa kubadilisha tena anwani ya kurudi ya__libc_csu_fini
kwenye rundo ili kuita yenyewe tena.
Tafadhali kumbuka kwamba na Full RELRO, sehemu ya .fini_array
inafanywa kuwa soma-tu.
link_map
Kama ilivyoelezwa katika chapisho hili, Ikiwa programu inaisha kwa kutumia return
au exit()
itatekeleza __run_exit_handlers()
ambayo itaita wabomoleaji waliosajiliwa.
Ikiwa programu inaishia kupitia _exit()
function, itaita exit
syscall na wabomoleaji wa kumaliza hawatatekelezwa. Kwa hivyo, kuthibitisha kuwa __run_exit_handlers()
inatekelezwa unaweza kuweka kizuizi cha muda kwenye hiyo.
Msimbo muhimu ni (chanzo):
Tazama jinsi map -> l_addr + fini_array -> d_un.d_ptr
inavyotumiwa kukadiria nafasi ya array ya kazi za kupiga.
Kuna chaguo kadhaa:
Badilisha thamani ya
map->l_addr
ili iweze kuashiriafini_array
bandia yenye maagizo ya kutekeleza msimbo wa kupigaBadilisha kuingia za
l_info[DT_FINI_ARRAY]
nal_info[DT_FINI_ARRAYSZ]
(ambazo ziko karibu kwenye kumbukumbu), ili ziweze kuashiria muundo waElf64_Dyn
uliobuniwa ambao utafanya tenaarray
iashirie eneo la kumbukumbu linalodhibitiwa na mshambuliaji.Hii andishi inabadilisha
l_info[DT_FINI_ARRAY]
na anwani ya kumbukumbu inayodhibitiwa katika.bss
inayohifadhifini_array
bandia. Array hii bandia ina kwanza anwani ya gadget moja ambayo itatekelezwa na kisha tofauti kati ya anwani ya array bandia na thamani yamap->l_addr
ili*array
iashirie array bandia.Kulingana na chapisho kuu la mbinu hii na hii andishi ld.so huacha kidude kwenye stakishi kinachoashiria
link_map
ya binary katika ld.so. Kwa kuandika kwa hiari inawezekana kuibadilisha na kuifanya iashiriefini_array
bandia inayodhibitiwa na mshambuliaji na anwani ya gadget moja kwa mfano.
Ukiendelea na msimbo uliopita unaweza kupata sehemu nyingine ya kuvutia na msimbo:
Katika kesi hii ingewezekana kubadilisha thamani ya map->l_info[DT_FINI]
ikielekeza kwa muundo wa ElfW(Dyn)
ulioundwa. Pata maelezo zaidi hapa.
Kubadilisha TLS-Storage dtor_list katika __run_exit_handlers
__run_exit_handlers
Kama inavyoelezwa hapa, ikiwa programu inaishia kupitia return
au exit()
, itaendesha __run_exit_handlers()
ambayo itaita kazi yoyote ya mabomoleaji iliyosajiliwa.
Msimbo kutoka _run_exit_handlers()
:
Msimbo kutoka __call_tls_dtors()
:
Kwa kila kazi iliyosajiliwa katika tls_dtor_list
, itatengeneza upya pointer kutoka kwa cur->func
na kuipiga simu na hoja cur->obj
.
Kwa kutumia kazi ya tls
kutoka kwa hii fork ya GEF, ni rahisi kuona kwamba dtor_list
iko karibu sana na stack canary na PTR_MANGLE cookie. Hivyo, kwa kujaza kwa wingi, ingewezekana kubadilisha cookie na stack canary.
Kwa kubadilisha PTR_MANGLE cookie, ingewezekana kupita kwenye kazi ya PTR_DEMANLE
kwa kuweka kuwa 0x00, maana yake xor
iliyotumika kupata anwani halisi ni tu anwani iliyowekwa. Kisha, kuandika kwenye dtor_list
inawezekana kuunganisha kazi kadhaa na kazi ya anwani na hoja yake.
Hatimaye, kumbuka kwamba pointer iliyohifadhiwa haitakuwa tu ikifanyiwa xor na cookie bali pia inazungushwa biti 17:
Kwa hivyo unahitaji kuzingatia hili kabla ya kuongeza anwani mpya.
Pata mfano katika chapisho la asili.
Pointi zingine zilizopotoshwa katika __run_exit_handlers
__run_exit_handlers
Mbinu hii inaeleza hapa na inategemea tena programu kutoka kwa wito wa return
au exit()
hivyo __run_exit_handlers()
inaitwa.
Hebu angalia zaidi ya nambari ya kazi hii:
Variable f
inaelekeza kwa muundo wa initial
na kulingana na thamani ya f->flavor
kazi tofauti zitaitwa.
Kulingana na thamani, anwani ya kazi ya kuita itakuwa mahali tofauti, lakini itakuwa demangled daima.
Zaidi, katika chaguo za ef_on
na ef_cxa
pia niwezekano wa kudhibiti argument.
Inawezekana kuangalia muundo wa initial
katika kikao cha kutatua matatizo na GEF ikikimbia gef> p initial
.
Kutumia hii unahitaji kuvuja au kufuta PTR_MANGLE
cookie na kisha kubadilisha kuingia cha cxa
katika initial na system('/bin/sh')
.
Unaweza kupata mfano wa hii katika chapisho la blogu la awali kuhusu mbinu.
Last updated