Exploitation des erreurs de configuration CORS pour les Bitcoins et les primes (2023)

Casser les analyseurs

La plupart des sites Web utilisent des opérations de chaîne de base pour vérifier l'en-tête Origin, mais certains l'analysent plutôt comme une URL. Trois ans après la publication initiale de cette recherche,Bitwis3partagé une technique pour exploiter les analyseurs qui tire parti de la tolérance de Safari pour les caractères inhabituels dans les noms de domaine. Dans Safari, il s'agit d'une URL valide - essayez de la copier-coller :

http://example.com%60.hackxor.net/static/cors.html

Et la requête CORS provenant de cette URL contient :

Origine : http://example.com`.hackxor.net/

Si un site choisit d'analyser cet en-tête, il pensera potentiellement que le nom d'hôte est example.com et le reflétera, nous permettant d'exploiter les utilisateurs de Safari même si le site utilise une liste blanche de noms d'hôte de confiance. Après avoir reçu ledénonciationde Bitwis3, j'ai personnellement essayé cette technique dans la nature et confirmé qu'elle fonctionne sur une gamme de systèmes réels.

Si vous trouvez que vous pouvez utiliser _ au lieu de `, vous pouvez également exploiter les personnes utilisant Firefox et Chrome - cette technique est documentée plus en détail dansTechniques avancées d'exploitation CORS.

Casser HTTPS

Au cours de cette recherche, j'ai trouvé deux autres défauts d'implémentation de liste blanche répandus, qui se produisent souvent en même temps. Le premier consiste à mettre aveuglément sur liste blanche tous les sous-domaines - même ceux qui n'existent pas. De nombreuses entreprises ont des sous-domaines pointant vers des applications hébergées par des tiers avec des pratiques de sécurité épouvantables. Croire que ceux-ci n'ont pas une seule vulnérabilité XSS et n'en auront jamais à l'avenir est une très mauvaise idée.

La deuxième erreur courante est de ne pas restreindre le protocole d'origine. Si un site Web est accessible via HTTPS mais acceptera volontiers les interactions CORS depuis http://où que ce soit, quelqu'un effectuant une attaque active de l'homme du milieu (MITM) peut à peu près contourner entièrement son utilisation de HTTPS. La sécurité stricte des transports et les cookies sécurisés ne feront pas grand-chose pour empêcher cette attaque. Découvrez l'enregistrement de la présentation lorsqu'il atterrit pour une démo de cette attaque.

Abus de CORS sans informations d'identification

Nous avons vu qu'avec les informations d'identification activées, CORS peut être très dangereux. Sans informations d'identification, de nombreuses attaques deviennent inutiles ; cela signifie que vous ne pouvez pas utiliser les cookies d'un utilisateur, il n'y a donc souvent rien à gagner en faisant en sorte que son navigateur émette la demande plutôt que de l'émettre vous-même. Même les attaques par fixation de jeton sont irréalisables, car tout nouveau cookie défini est ignoré par le navigateur.

Une exception notable est lorsque l'emplacement réseau de la victime fonctionne comme une sorte d'authentification. Vous pouvez utiliser le navigateur d'une victime comme proxy pour contourner l'authentification basée sur IP et accéder aux applications intranet. En termes d'impact, cela est similaire à la reliure DNS, mais beaucoup moins fastidieux à exploiter.

Varie : origine

Si vous jetez un coup d'œil à la section "Considérations sur la mise en œuvre" de la spécification CORS, vous remarquerez qu'elle demande aux développeurs de spécifier l'en-tête HTTP "Vary : Origin" chaque fois que les en-têtes Access-Control-Allow-Origin sont générés dynamiquement.

Cela peut sembler assez simple, mais un nombre immense de personnes oublient, y compris le W3C lui-même, ce qui conduit àcette citation fantastique:

Je dois dire que cela ne me rend pas très confiant que bientôt plus de sites prendront en charge CORS si même le W3C ne parvient pas à configurer correctement son serveur

- Réseau Gmür

Que se passe-t-il si nous ignorons ce conseil ? La plupart du temps, les choses se cassent. Cependant, dans les bonnes circonstances, cela peut permettre des attaques assez graves.

Empoisonnement du cache côté client

Vous avez peut-être parfois rencontré une page avecXSS réfléchidans un en-tête HTTP personnalisé. Supposons qu'une page Web reflète le contenu d'un en-tête personnalisé sans encodage :

OBTENIR /HTTP/1.1
Hébergeur : example.com
ID utilisateur X :

Sans CORS, cela est impossible à exploiter car il n'y a aucun moyen de faire en sorte que le navigateur de quelqu'un envoie l'en-tête X-User-id entre domaines. Avec CORS, nous pouvons leur faire envoyer cette demande. En soi, cela ne sert à rien puisque la réponse contenant notre JavaScript injecté ne sera pas rendue. Cependant, si Vary: Origin n'a pas été spécifié, la réponse peut être stockée dans le cache du navigateur et affichée directement lorsque le navigateur navigue vers l'URL associée. j'ai fait un violon àtentez cette attaque sur une URL de votre choix. Étant donné que cette attaque utilise la mise en cache côté client, elle est en fait assez fiable.

Empoisonnement du cache côté serveur

Si les étoiles sont alignées, nous pourrons peut-être utiliser l'empoisonnement du cache côté serveur via l'injection d'en-tête HTTP pour créer une vulnérabilité XSS stockée.

Si une application reflète l'en-tête Origin sans même vérifier qu'il ne contient pas de caractères illégaux comme \r, nous avons effectivement une vulnérabilité d'injection d'en-tête HTTP contre les utilisateurs IE/Edge car Internet Explorer et Edge voient \r (0x0d) comme un terminateur d'en-tête HTTP valide :

OBTENIR / HTTP/1.1
Origine : z[0x0d]Type de contenu : text/html ; jeu de caractères=UTF-7

Internet Explorer voit la réponse comme suit :

HTTP/1.1 200 OK
Accès-Contrôle-Autoriser-Origine : z
Type de contenu : text/html ; jeu de caractères=UTF-7

Ce n'est pas directement exploitable car il n'y a aucun moyen pour un attaquant de faire en sorte que le navigateur Web de quelqu'un envoie un en-tête aussi malformé, mais je peux créer manuellement cette demande dans Burp Suite et un cache côté serveur peut enregistrer la réponse et la servir à d'autres personnes . La charge utile que j'ai utilisée changera le jeu de caractères de la page en UTF-7, ce qui est notoirement utile pour créer des vulnérabilités XSS.

Bonnes intentions et mauvais résultats

J'ai d'abord été surpris par le nombre de sites qui génèrent dynamiquement des en-têtes Access-Control-Allow-Origin. La cause principale de ce comportement peut être deux limitations clés de CORS - les origines multiples dans un même en-tête ne sont pas prises en charge, et les sous-domaines génériques non plus. Cela ne laisse à de nombreux développeurs d'autre choix que de générer des en-têtes dynamiques, risquant ainsi tous les défauts d'implémentation évoqués ci-dessus. Je pense que si les auteurs de la spécification et les navigateurs décidaient d'autoriser les listes d'origine et les caractères génériques partiels, la génération d'en-tête dynamique et les vulnérabilités associées chuteraient.

Une autre amélioration potentielle pour les navigateurs consiste à appliquer l'exception wildcard+credentials à l'origine nulle. À l'heure actuelle, l'origine nulle est nettement plus dangereuse que l'origine générique, ce que j'imagine que beaucoup de gens trouvent surprenant.

Une autre chose que les navigateurs pourraient essayer est de bloquer ce que j'ai appelé "contenu mixte inversé" - les sites HTTP utilisant CORS pour voler des données à partir de sites HTTPS. Cependant, je n'ai aucune idée de l'ampleur de la casse que cela entraînerait.

La simplicité et la sécurité peuvent aller de pair, mais en négligeant de prendre en charge plusieurs déclarations d'origine, les navigateurs Web ont simplement poussé la complexité sur les développeurs avec des résultats néfastes. Je pense que la principale conclusion à retenir est que la conception et la mise en œuvre de spécifications sécurisées sont extrêmement difficiles.

Conclusion

CORS est une technologie puissante qu'il vaut mieux utiliser avec précaution, et les exploits graves ne nécessitent pas toujours des compétences spécialisées et des chaînes d'exploitation alambiquées - souvent une compréhension de base d'une spécification et un peu d'attention suffisent. Au cas où vous manqueriez de café, à partir d'aujourd'hui, le scanner de Burp Suite identifiera et signalera tous les défauts discutés ici.

Mise à jour : Nous avons maintenant publié une collection d'ateliers interactifs gratuits afin que vous puissiez vous entraîner à exploiter ces vulnérabilités sur des systèmes en direct :

Laboratoires de mauvaise configuration CORS