
Outil automatisé de découverte de mauvaise configuration CORS utilisant des domaines de typosquatting et des service workers de navigateur pour sonder les réseaux internes des cibles de bug bounty.
of-CORS est la suite d'outils de Truffle Security pour identifier et exploiter les mauvaises configurations CORS sur les réseaux internes de cibles de bug bounty en utilisant le typosquatting.
Vous pouvez en lire plus ici https://trufflesecurity.com/blog/of-CORS
of-CORS est une application web Python3 construite sur Django et Django Rest Framework. Une fois configurée et déployée, of-CORS enregistre automatiquement des service workers dans les navigateurs des victimes qui visitent l'application. Ces service workers envoient des requêtes HTTP vers une liste de domaines internes préconfigurés dans le but de découvrir des mauvaises configurations CORS sur les réseaux internes. Les résultats de ces requêtes (qu'elles soient réussies ou non) sont ensuite soumis via l'API à l'instance of-CORS.
Une fois qu'un service worker a été enregistré dans le navigateur d'une victime, une charge utile JavaScript redirige le navigateur vers la page que of-CORS pense que la victime essayait d'atteindre à l'origine.
Les résultats collectés peuvent ensuite être consultés dans un tableau de bord minimaliste disponible sur l'application of-CORS.
Les étapes suivantes permettent de mettre en place of-CORS dans votre propre déploiement.
En raison de la complexité de la mise en place de of-CORS (notamment les complications liées à SSL/TLS, DNS et la nécessité d'autoriser les requêtes wildcard pour les deux), nous utilisons deux fournisseurs cloud (Heroku et Cloudflare) dans la pile applicative et Terraform pour automatiser leur configuration.
Commencez par acheter un domaine sur lequel un employé interne de l'entreprise cible est susceptible d'atterrir. Nous recommandons d'acheter un typo-squat d'un domaine interne. Nous avons constaté que les erreurs de copier-coller sont un bon point de départ.
Ainsi, par exemple, si l'entreprise que vous testez utilise uberinternal.com pour ses domaines internes, vous pouvez acheter berinternal.com pour commencer à recevoir du trafic de navigateur de la part des employés internes.
of-CORS utilise Cloudflare pour recevoir et router les requêtes DNS wildcard ainsi que pour terminer les connexions SSL/TLS.
Vous aurez besoin d'un compte Cloudflare actif pour que le DNS fonctionne correctement avec of-CORS. Une fois que vous avez un compte Cloudflare, vous voudrez créer une clé API (cela peut être fait depuis le tableau de bord ici).
La clé API doit disposer de privilèges suffisants pour ajouter, supprimer et configurer des zones ainsi que des enregistrements DNS. Cela peut être réalisé en sélectionnant les autorisations suivantes sur la page de création du jeton API :

Une fois que vous avez créé un jeton API avec les bonnes autorisations, vous pouvez passer à l'étape suivante.
of-CORS utilise Heroku pour un déploiement et un hébergement faciles de l'application.
Vous aurez besoin d'un compte Heroku actif pour que la pile applicative of-CORS soit opérationnelle. Une fois que vous avez un compte, installez l'outil en ligne de commande (CLI) Heroku. Avec le CLI installé, vous pouvez démarrer une session CLI authentifiée avec la commande suivante :
heroku login
Vous pouvez ensuite confirmer que votre CLI est bien authentifié en exécutant la commande suivante :
heroku whoami
Une documentation supplémentaire sur l'autorisation du CLI Heroku pour une utilisation avec Terraform est disponible ici.
Maintenant que les clés API nécessaires à notre infrastructure sont prêtes, nous pouvons passer à la configuration de of-CORS pour le déploiement. Examinez le contenu de l'exemple de fichier de configuration YAML ci-dessous qui se trouve dans le dépôt :
terraform:
# Vous devez changer cette chaîne en une chaîne unique qui est un nom d'application Heroku valide
heroku_app_name: best-of-cors
# Remplissez ce champ avec votre jeton API Cloudflare
cloudflare_api_token: this-is-my-api-token
hosts:
# Ceci peut être une chaîne arbitraire, mais doit être unique en tant qu'enfant direct de hosts
testing:
host_domain: 127.0.0.1:8080
redirect_domain: google.com
targets:
- enable-cors.org
- example.com
Vous devrez créer un nouveau fichier de configuration YAML de ce format pour le déploiement.
Dans la section terraform, définissez heroku_app_name sur un nom d'application compatible Heroku unique pour votre compte. Ajoutez également votre clé API Cloudflare générée dans la section précédente sous la directive cloudflare_api_token.
La section hosts définit les domaines sur lesquels nous attendons que of-CORS reçoive du trafic et ce qu'il faut faire lorsque des visiteurs web arrivent. Supposons que nous ciblons une entreprise et que nous savons qu'elle a deux domaines internes (myinternalcorp1.com et myinternalcorp2.com). Nous avons acheté le domaine yinternalcorp1.com en espérant que des employés le visitent accidentellement. Dans ce cas, nous configurerions hosts comme suit :
hosts:
testing_1:
host_domain: yinternalcorp1.com
redirect_domain: myinternalcorp1.com
targets:
- myinternalcorp1.com
- myinternalcorp2.com
host_domain est le domaine où vous attendez du trafic (c'est-à-dire le domaine acheté). redirect_domain définit le domaine vers lequel les victimes seront redirigées une fois la charge utile lancée. targets spécifie les domaines contre lesquels les charges utiles doivent être lancées lorsqu'une victime visite of-CORS.
Supposons que nous ayons également acheté yinternalcorp2.com et que nous voulions configurer of-CORS pour lancer des attaques lorsqu'il est visité. La section hosts pourrait alors être mise à jour comme suit :
hosts:
testing_1:
host_domain: yinternalcorp1.com
redirect_domain: myinternalcorp1.com
targets:
- myinternalcorp1.com
- myinternalcorp2.com
testing_2:
host_domain: yinternalcorp2.com
redirect_domain: myinternalcorp2.com
targets:
- myinternalcorp1.com
- myinternalcorp2.com
Désormais, si une victime visite accidentellement yinternalcorp1.com ou yinternalcorp2.com, les charges utiles d'énumération des mauvaises configurations CORS sur myinternalcorp1.com et myinternalcorp2.com seront lancées, et le navigateur de la victime sera ensuite redirigé vers le domaine correct.
Vous n'aurez pas besoin d'installer Terraform, Heroku, Python avec l'option Docker. Exécutez simplement cette commande avec le bon chemin pour votre fichier yaml :