XSS
Description
L'application était une application Web à 3 niveaux de rÎles (administrateur, un utilisateur spécifique utilisé pour un usage spécifique et des utilisateurs normaux). Les utilisateurs spécifiques avaient la possibilité de générer des e-mails avec des entrées personnalisées dans certaines entrées (nom de l'organisation et signature). Une fonctionnalité permettait de voir un aperçu de l'email généré mais celle-ci était la seule à ne pas bien valider et filtrer l'entrée. Cela a conduit à avoir la possibilité de stocker du code javascript dans la page Web, mais à ce moment, il ne s'agissait que d'une Self XSS car les autres utilisateurs ne peuvent pas afficher l'aperçu de l'email généré.
Cependant, les utilisateurs administrateurs avaient la possibilité d'incarner des utilisateurs spécifiques et d'avoir accÚs à toutes leurs pages et fonctionnalités comme si ils étaient connecté sur leur compte, donc si un utilisateur spécifique entre dans une charge utile xss aveugle et encourage un administrateur à aller voir son aperçu, il peut exécuter du code javascript sur son navigateur.
Exploitation
Tout d'abord, j'ai créé un nouvel aperçu avec mon compte spécifique avec des entrées "classiques" et ai constaté que celles-ci étaient reflétés dans l'email.
J'ai alors dans un premier temps tenter d'entrer une charge utile basique telle que <script>alert(document.domain)</script> qui a été executé.
J'ai donc adapté mon payload afin d'avoir la possibilité d'exfiltrer le cookie de l'administrateur se rendant sur l'aperçu.
Payload utilisé
Je me suis ensuite connecté en tant qu'admin et ai incarné mon utilisateur spécifique pour me rendre sur l'aperçu contenant la charge utile.
Mon cookie administrateur a ainsi été envoyé à mon serveur "attacker.xyz" au chargement de la page.
Risques
Le risque ici est principalement un privesc en exfiltrant le cookie de session administrateur mais cela pourrait aussi permettre Ă un attaquant d'injecter un keylogger ou autre code javascript malveillant dans leur navigateur.
Stored XSS dans attribut href via panneau d'administration
Description
L'application Web utilisait Ruby on Rails avec active admin permettant aux utilisateurs administrateurs de modifier toutes les pages Web. Toutes les balises html était correctement encodés afin d'éviter toute injection, j'ai donc trouvé un autre point d'injection qui n'utilisait pas de balises html. Les entrées attendants des URL notamment n'était pas correctement vérifiés et filtrés, j'ai donc pu utiliser le schéma d'URL "javascript:" pour stocker des hyperliens malveillants sur les pages du site. Différents types de pages Web étaient vulnérables et l'une d'elles contenait une URL iframe permettant d'exécuter du code javascript sans interaction de l'utilisateur.
Exploitation
Je me suis connecté en tant qu'administrateur.
J'ai entré la charge utile "javascript:alert(document.domain);" dans toutes les entrées attendant une url.
J'ai sauvegardé les changements et me suis rendu sur la page modifié/crée.
Les urls malicieuses étaient correctement executés au chargement de la page et lorsque l'on cliquait sur les hyperliens.
Risques
Les utilisateurs administrateurs peuvent exécuter du code javascript sur tous les utilisateurs qui ouvrent une page ou cliquent sur un lien hypertexte menant au détournement de session, à l'injection d'un enregistreur de frappe ou à d'autres actions malveillantes.
Rewards
Last updated
