trufflesecurity/of-corsOutil 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 :
docker run -v $PWD/config.yml:/config.yml -it --rm trufflesecurity/of-cors
Le déploiement de of-CORS repose sur Terraform. Suivez les instructions pour installer Terraform ici. Une fois installé, le binaire terraform doit être disponible dans le PATH de votre système.
Le déploiement de of-CORS repose également sur Python3. Assurez-vous qu'il est installé et disponible dans le PATH de votre système.
Une fois l'authentification auprès de nos fournisseurs cloud effectuée et le fichier de configuration of-CORS prêt, nous pouvons passer au déploiement.
Tout d'abord, nous devons initialiser Terraform. Cette commande doit être exécutée depuis le répertoire racine du code source :
cd terraform && terraform init && cd ../
Supposons que notre fichier de configuration se trouve dans /tmp/of_cors_config.yml. Nous exécuterons alors les commandes suivantes pour mettre en place toute l'infrastructure of-CORS (notez que cela suppose que les commandes sont exécutées dans bash). L'exécution de cette commande peut prendre 5 à 10 minutes, veuillez donc patienter !
Notez également que pour les énumérations très volumineuses, Heroku manque souvent de ressources. C'est un problème connu, et nous aimerions que vous nous aidiez à le résoudre. Les correctifs futurs possibles incluent la possibilité de télécharger les énumérations vous-même, d'augmenter la taille du Dyno Heroku, ou de passer à Sublist3r ou un autre outil d'énumération.
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
CONFIG_FILE=/tmp/of_cors_config.yml make deploy_and_configure
À NOTER - Il existe une condition de concurrence qui peut se produire lorsque l'infrastructure Heroku est démarrée et qu'une console y est immédiatement accédée. Si l'exécution de cette dernière commande make deploy_and_configure échoue, veuillez attendre quelques minutes et réessayer.
Une fois la commande deploy_and_configure terminée, vous aurez...
of-CORS peuplé de domaines internes candidats à des mauvaises configurations CORSLa dernière chose à faire pour que le déploiement de of-CORS soit prêt à recevoir du trafic est de configurer les noms de domaine que vous avez achetés pour qu'ils utilisent Cloudflare comme serveurs DNS faisant autorité. Cloudflare propose un guide détaillé pour cela ici.
Suivez les étapes suivantes pour confirmer que votre logiciel fonctionne correctement. Pour les besoins de cette section, nous utiliserons une instance de of-CORS configurée sous le domaine hackersofhollywood.com.
Vérifions d'abord que les enregistrements SOA de notre domaine pointent vers Cloudflare :
dig soa <domain>
Comme indiqué ci-dessous, les enregistrements SOA de hackersofhollywood.com pointent correctement vers les serveurs de noms Cloudflare :
Ensuite, nous examinons le compte Cloudflare pour confirmer que les enregistrements DNS ont été configurés à la fois pour hackersofhollywood.com et *.hackersofhollywood.com avec des contenus CNAME pointant vers des domaines Heroku. Cela se fait via l'interface web Cloudflare dans la section DNS :
L'étape suivante consiste à confirmer que Heroku est configuré pour recevoir du trafic via ces deux enregistrements CNAME. Cela peut être fait via l'interface web Heroku sous Settings -> Domains :
Effectivement, nous voyons deux noms de domaine avec les cibles DNS appropriées configurées dans Heroku, et ces cibles sont correctement reflétées dans les enregistrements CNAME de Cloudflare.
Nous pouvons ensuite exécuter la commande suivante pour ouvrir une session de navigateur authentifiée vers la page de visualisation des résultats de of-CORS :
CONFIG_FILE=<chemin_vers_fichier_config> make open_heroku_console
Cela devrait afficher un tableau de bord vide dans votre navigateur :
Enfin, nous pouvons tester que les sondages de mauvaises configurations CORS sont lancés avec succès. Ouvrez un navigateur vers le domaine de base pour l'une de vos configurations (dans notre exemple, https://hackersofhollywood.com) et confirmez que la page redirige après quelques secondes :
Revenez maintenant à la page du tableau de bord, changez le filtre Success pour filtrer sur Unknown et cliquez sur le bouton Submit Query. Vous devriez maintenant voir un ensemble de résultats :
Votre piège est en place ! Il ne vous reste plus qu'à vous détendre et attendre que vos victimes tombent sur votre petit domaine appétissant.
La commande suivante peut être utilisée pour visualiser et interroger tous les résultats dans une session de navigateur authentifiée :
CONFIG_FILE=<chemin_vers_fichier_config> make open_heroku_console
Le fichier de configuration of-CORS est conçu pour permettre l'ajout et la suppression flexibles des domaines pour lesquels les attaques sont lancées. Il suffit de mettre à jour le contenu de la section hosts dans votre fichier de configuration et de réexécuter le script de provisionnement :
source venv/bin/activate
CONFIG_FILE=/tmp/of_cors_config.yml make deploy_and_configure