Envoyer des e-mails au nom d'une entreprise ? Voici comment j'ai trouvé cette vulnérabilité dans plusieurs grandes entreprises me permettant de gagner facilement des primes.

Salut les chasseurs . Le but ici est de pouvoir envoyer des email(s) au nom d'une entreprise — depuis son adresse email — avec la possibilité de modifier/personnaliser le contenu et donc le template HTML .

Quel est l'impact d'une telle vulnérabilité ?

L'impact de cette vulnérabilité peut être important, un attaquant profiterait de la confiance des utilisateurs dans la plateforme pour les rediriger vers des sites frauduleux (phishing, etc.) voire les pousser à effectuer des actions indésirables depuis leurs comptes. Les programmes évaluent généralement la gravité de cette vulnérabilité entre faible et moyenne .

Comment ça marche?

L'injection HTML est une vulnérabilité dans laquelle une application accepte l'entrée de l'utilisateur, puis intègre l'entrée dans HTML. Un attaquant peut injecter du code HTML à partir de l'entrée de l'utilisateur afin que son code malveillant soit intégré dans le modèle global généré par l'application.

Cela est dû à une désinfection inadéquate des entrées de l'utilisateur. C'est très facile à corriger mais passe très souvent sous le radar — ce vecteur d'attaque en particulier — pour le plus grand plaisir des chasseurs de bugs.

La fameuse règle d'or des développeurs : ne jamais faire confiance aux commentaires des utilisateurs

Identification des différents vecteurs d'attaque & exploitation

La première chose à faire pour identifier cette vulnérabilité est de trouver une fonctionnalité sur l'application qui envoie des emails : la plupart des applications disposent d'une section « Contactez-nous », ou d'une section « Aide » pour envoyer des requêtes aux équipes de l'entreprise. Ces fonctionnalités sont les plus basiques, et la liste n'est pas exhaustive, différentes fonctionnalités d'envoi de mails peuvent être trouvées selon la nature de l'application.

Une fois ces fonctionnalités trouvées, il faut les tester et vérifier la présence de plusieurs critères :

Nous prendrons l'exemple d'un formulaire permettant d'adresser une requête (demande d'aide) au personnel technique de l'entreprise

[1] Lors de la soumission du formulaire, est-ce que je reçois un e-mail (à l'adresse e-mail indiquée dans le formulaire ou à l'adresse e-mail liée au compte à partir duquel la demande a été envoyée) ?

Si ce n'est pas le cas, assurez-vous que cela peut prendre un certain temps, vous n'avez pas à chercher plus loin. Avant d'espérer injecter du code dans un template, il faut encore que le template en question existe.

[2] Si je reçois un e-mail lors de la soumission du formulaire, est-il possible de spécifier une adresse e-mail dans le formulaire/la requête ?

Pour exploiter la vulnérabilité il faut pouvoir cibler d'autres personnes donc soit le formulaire en question me permet de préciser l'email de mon choix, soit il faut être connecté pour soumettre le formulaire et donc l'email sera automatiquement envoyé à l'adresse email est liée au compte connecté :

Auquel cas interceptez la requête dans votre proxy préféré, et vérifiez que votre adresse email ne se trouve pas dans la requête HTTP (POST en principe), et essayez de la changer pour l'adresse email de votre choix.

[3] Certaines des informations fournies dans le formulaire sont-elles reflétées dans l'e-mail reçu ?

Si ce n'est pas le cas, vérifiez si certaines de vos informations personnelles — dans le cas où vous êtes connecté à votre compte — sont répercutées dans l'e-mail comme le nom d'utilisateur, le nom ou le prénom par exemple.

Dans ce cas, modifiez la ou les informations reflétées et essayez d'y saisir votre charge utile. Même si l'information en question n'est pas interprétée sur l'application, elle peut être interprétée dans l'email , c'est ce qu'on appelle une injection de second ordre , l'injection n'est pas directement réalisée à partir des saisies utilisateur du formulaire, mais à partir d'informations enregistrées par ailleurs , sur le compte par exemple.

Sinon, nous ne pouvons pas essayer d'injecter du code, ni même de contourner un filtre.

[4] La dernière étape consiste à essayer d'injecter du code HTML qui sera interprété par le template en question

Comme mentionné précédemment, ce genre de vulnérabilité passe souvent inaperçu, et certaines applications n'ont ni filtres latéraux front-end ni back-end et une simple charge utile incluant du code HTML suffit :

vul<strong>ne</strong>rable

Parfois, les développeurs se sont concentrés sur les filtres frontaux, ce qui rend impossible la soumission de formulaires contenant des caractères spéciaux : ne vous arrêtez pas là , soumettez le formulaire avec des valeurs aléatoires, interceptez la requête dans votre proxy puis saisissez vos payloads directement depuis le proxy. Cela fera sauter toutes les protections du front, qui sont parfois le dernier bastion vers la prime. Si des protections existent aussi sur la face arrière, ne baissez pas les bras dans les premières minutes, essayez de contourner les filtres, la méthodologie ici est la même que pour les vulnérabilités XSS.

Vous rencontrez des difficultés pour contourner un filtre pour un personnage en particulier ? Jeter un coup d'œil à :https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md

C'était mon premier article, merci d'avoir lu. Si vous avez des questions, n'hésitez pas à me le faire savoir.

Mon compte Twitter :https://twitter.com/blank_cold