# Bug Bounty Blog Blog personnel de Bug Bounty ## Introduction Bienvenue sur mon blog de bug bounty ! je m'appelle Mathis Pais De Sousa, je pentester junior et bug bounty hunter. 🖐 Dans ce blog, je partagerai mes expériences, mes astuces et mes connaissances en matière de bug bounty. Vous y découvrirez une application réélle des différentes méthodes d'attaques et vulnérabilités pouvant être trouvées sur le web. Le but de celui-ci est de montrer des cas réels aux vulnérabilités décrites et détaillés dans la partie "documentation" de ce Gitbook via mes découvertes en bug bounty. ressource: Que vous soyez débutant ou confirmé dans le domaine de la sécurité informatique, j'espère que mon blog vous aidera à avoir une meilleure compréhension des vulnérabilités web et à partager votre passion avec la communauté de la sécurité. Bonne lecture ! ## Sommaire {% content-ref url="/pages/l5p2KG2wCQnm5KLhw7hE" %} [HTML injection](/html-injection) {% endcontent-ref %} {% content-ref url="/pages/N13mvVnJ17NoHlG7cHEc" %} [XSS](/xss) {% endcontent-ref %} {% content-ref url="/pages/1JJnGDT9h74BGiQkQ7hh" %} [Rate Limit bypass](/rate-limit-bypass) {% endcontent-ref %} {% content-ref url="/pages/t67R78uWiGGC9kXH4FOg" %} [Open redirect](/open-redirect) {% endcontent-ref %} {% content-ref url="/pages/49LWPmRIcZgCZOOmiRYO" %} [SSRF](/ssrf) {% endcontent-ref %} {% content-ref url="/pages/cPGJxb4st1I2EQwomJ6L" %} [Race Condition](/race-condition) {% endcontent-ref %} {% content-ref url="/pages/uYAMDISAybJrvgss2wEU" %} [2FA/OTP bypass](/2fa-otp-bypass) {% endcontent-ref %} # HTML injection ## [HTML injection](https://blog.s1rn3tz.ovh/pentest-web/injections/htmli#basic) réfléchis dans des emails ### Description À de multiples reprises, j'ai eu l'occasion de rencontrer ce type de bug très commun. En effet les développeurs priorisent souvent la validation et le filtrage des entrées utilisateurs sur le site principale oubliant parfois de faire de même dans leurs templates d'email. Ce type d'injection HTML se produit lorsqu'un attaquant insère du code HTML malveillant dans un champ de saisie dont l'entrée est réfléchie dans un email. Lorsque la victime ouvre l'email, le code malveillant peut être exécuté dans son navigateur, ce qui peut dans la plupart des cas mener à des redirections vers des sites web dangereux. ### Points d'injection fréquents Les entrées modifiable par un utilisateur qui sont le plus souvent reflétés dans des emails sont: * Son nom d'utilisateur * Son prénom * Son nom de famille * Un message personnalisé {% hint style="info" %} En soit, a chaque fois qu'une entrée utilisateur peut être reflété dans un email, il y a un risque d'injection HTML {% endhint %} ### Charges utiles ```html test ... lire la suite ``` #### Exemple

### Risques Le risque ici est la redirection vers un site malveillant et potentiellement la fuites d'informations (IP, user agent) des victimes. ## Rewards

# XSS ## Self [XSS](https://blog.s1rn3tz.ovh/pentest-web/injections/xss) => Stored XSS via fonctionnalité de prévisualisation de mail ### 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 \ 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é ```html ``` * 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

# Rate Limit bypass ## Contournement de captcha basé sur IP ### Description J'ai repéré la vulnérabilité en chassant sur une application web en full blackbox. Après quelques tests, j'ai été bloqué par un captcha à cause du nombre de requêtes envoyées. L'équipe de sécurité de l'entreprise avait pour projet d'implémenter un WAF sur l'application qui devrait utilise des en-têtes spécifiques pour fonctionner. Ils ont donc décidé de les activer en prévision de cette nouvelle solution. L'un des en-têtes utilisés était l'en-tête "True-Client-IP :" utilisé pour donner une adresse IP spécifique au client envoyant la requête. Grâce à cet en-tête, j'ai pu spoofer mon IP et ainsi contourner la limitation de débit du captcha. ### Exploitation * J'ai envoyé un grand nombre de requêtes amenant l'application à bloquer mon IP via un mécanisme de captcha. * J'ai donc utilisé l'extension "Param Miner" de Burp Suite afin de trouver de potentielles en-têtes pouvants me permettre de contourner cette protection. * Param Miner après quelques minutes m'a renvoyé plusieurs réponses dont l'en-tête True-Client-IP que j'ai pu utiliser afin de modifier mon IP aux yeux de l'application. * Cela m'a permis de réinitialiser le rate limit de l'application. ### Risques * Bruteforce * DDoS * Autres attaques automatisées ## Rewards ![](/files/9c6uVshCixScwrz2E7xL) # Open redirect ## [Open redirect](https://blog.s1rn3tz.ovh/pentest-web/open-redirect) via un paramètre GET dans le stockage d'une image de profile ### Description L'application Web permettait à tous les utilisateurs de télécharger des images d'avatar. Après avoir essayé de trouver sans succès des vulnérabilités de la fonctionnalité de téléchargement, j'ai essayé de suivre mon image d'avatar dans une nouvelle fenêtre et j'ai vu que l'application utilisait un paramètre appelé "u" pour rediriger vers l'un des sous-domaines de l'entreprise utilisant une api pour la stocker. Ce paramètre en trompant la regex de vérification de domaine était vulnérable aux redirections ouvertes. ### Exploitation * J'ai fait un clic droit sur mon image de profile et l'ai ouvert dans un nouvel onglet. * L'url était * J'ai d'abord essayé de simplement changer le domaine original par mon propre domaine me renvoyant une erreur Golang.

* J'ai donc d'abord essayé de me renseigner sur de potentielles vulnérabilités sur golang en me basant sur cette erreur sans succès. * Puis je me suis reconcentré sur les open redirect par la suite, j'ai alors tenter de manipuler la regex utilisée pour vérifier le domaine d'origine en ajoutant simplement ".attacker.xyz" puis "@attacker.xyz" mais cela n'a pas fonctionné. * J'ai finalement réussi à contourner la validation à l'aide du caractère URL encodé "%ff" donnant l'url finale suivante.

### Risques Les attaquants peuvent exploiter cette vulnérabilité afin d'inciter les utilisateurs à visiter un site Web malveillant qui peut voler leurs informations sensibles, installer des logiciels malveillants sur leur appareil ou effectuer d'autres actions malveillantes. Les vulnérabilités de redirection ouverte sont un vecteur d'attaque courant pour les campagnes de phishing, car les attaquants peuvent créer un lien d'apparence convaincante vers un site légitime, mais qui redirige en fait l'utilisateur vers une fausse page de connexion conçue pour voler ses informations d'identification. ## Open redirect via paramètre callback sans vérification ### Description L'application web contenait une fonctionnalité permettant d'envoyer un lien par SMS ou email à un client lui demandant de lier son compte bancaire à l'application afin de récupérer son historique de transactions. Celle-ci fournissait la documentation de ses API donc celle se chargeant de cette liaison. La requête permettant d'envoyer le lien en question contenait un paramètre caché nommé "callbackUrl" qui n'était donc pas utilisée par défaut par les utilisateurs mais probablement par les développeurs le callback étant par défaut fait vers un endpoint statique.

### Exploitation * J'ai intercepté la requête de génération de lien.

* J'ai ajouté le paramètre caché "callbackUrl" pointant vers mon burp collaborator.

* J'ai suivi le lien généré et complété la connexion avec ma banque pui ai été redirigé vers le burp collaborator après avoir validé la demande sur mon application mobile (à la fin du processus lors normalement de la redirection vers le domaine de l'entreprise).

Redirection from bank to the domain given in callback param

### Risques Le risque principal ici serait un scénario dans lequel un acteur malveillant abuse du contexte de la fonctionnalité pour ce faire passer pour une banque et hameçonner le client afin de voler ses idantifiants bancaires.

## Open redirect vers une application du play store arbitraire ### Description L'entreprise vulnérable propose des applications mobiles dont les deeplinks sont gérées via un sous-domaine . Lorsque l'application est installé sur l'appareil, un deeplink permet de rediriger l'utilisateur sur l'application. Cependant, si celle-ci n'est pas installé, alors l'utilisateur est redirigé vers la page associée sur le playstore. ### Exploitation * Pour trouvé l'endpoint vulnérable, j'ai combiné deux de mes outils (WebHackUrls et ParamFirstCheck) afin de filtrer les urls de l'entreprise ayants été archivés.

* J'ai ainsi trouvé une url sur utilisant un paramètre "link" redirigeant vers une url du domaine principal de l'entreprise qui lui même faisait une deuxième redirection. * J'ai alors essayé des open redirect conventionnels et des contournement pour la whitelist en place mais ceci sans succès. * Je n'ai alors pas eu d'autre choix que te tenter d'effectuer des actions malveillantes en passant par les domaines whitelistés dont faisait donc partie d'après certaines fonctionnalités du sous-domaine.

* J'ai alors ensuite tout simplement abusé de la confiance envers le play store de Google afin de faire pointer le paramètre link de l'url vers une application arbitraire n'étant pas du tout celui de l'entreprise. ![](/files/86vp8A5GDkko9moE20kf)![](/files/w09ZCGw2N2R86ifgEreK) ### Risques En utilisant cette vulnérabilité, un attaquant est capable de manipuler un potentiel client intéréssé par l'application de l'entreprise afin de lui faire télécharger un "clone" malicieux de l'application ou encore l'application d'un concurrent. ## Rewards ![](/files/PPkb1BLaMGOjW1QIS5wL) # SSRF ## SSRF stockée dans l'url de source des images de profiles menant à la fuites d'informations des utilisateurs ### Description L'application était une plate-forme d'apprentissage en ligne qui permettait à tous les utilisateurs de s'inscrire à des cours en ligne sur différents sujets. Tous les utilisateurs avaient la possibilité de télécharger leur propre image de profile qui était ensuite chargée à partir d'un domaine de stockage hébergé en externe. Lors de la modification du profil, l'URL complète où l'image est stockée est envoyée dans un paramètre nommé "user\_profile\[user]". Après avoir testé sans succès les vulnérabilités liées à la fonctionnalité de téléchargement, j'ai décidé de me concentrer sur cette URL. ### Exploitation * J'ai d'abord essayé de remplacer le domaine d'origine avec mon propre domaine mais les changements n'étaient pas pris en compte lorsque je validais la requête. * J'ai alors ensuite essayé de contourner la regex de validation d'url utilisée en ajoutant un ".attacker.xyz" puis un "@attacker.xyz" à la suite du domaine d'origine ce qui à ma grande surprise a fonctionné me permettant ainsi de remplacer la source de l'image à charger par une source provenant de mon propre serveur.

* Cela me permettant de faire en sorte que les utilisateurs de l'application charge l'image de mon serveur à chaque fois que mon image de profile était chargé dans la page qu'ils ouvraient.

### Risques Fuites d'informations techniques des utilisateurs de l'application (IP, User-Agent) ## SSRF dans une page d'erreur menant à des fuites d'informations techniques des appareils et navigateurs des victimes ### Description Le site web vulnérable proposait un espace personnel sur son sous domaine . Lorsqu'une erreur survenait sur le site, une redirection était effectué vers l'url avec comme paramètres GET "message", "url" et "label". Le paramètre "message" était reflété dans la page en tant que message d'erreur. Après avoir tenté d'exploiter ce vecteur en cherchant à executer des injections HTML/XSS/SSTI sans succès, ce suis passé au paramètre suivant. Le paramètre label avait pour seule utilité de contenir le type d'erreur rencontré, cependant le paramètre url contenait une url compléte vers une image svg présente sur le domaine principal de l'organisation. (https:%2F%2Fwww\.redacted.fr%2Fdesign%2F3.9.0%2Fneva%2Fassets%2F) Dans le code source de la page, cette url était reflété avec à la suite le path vers l'image en accord avec l'erreur (/img/unavailable.svg) ### Exploitation * J'ai d'abord tenté de simplement remplacer le domaine [www.redacted.fr](http://www.redacted.fr) par mon domaine attaquant mais celui-ci fût remplacé par le domaine d'origine dans la réponse. * J'ai alors ensuite simplement tenté de garder le domaine d'origine en y ajoutant un simple "@" suivi de mon propore domaine et le serveur a accepté l'url en l'état (https:%2F%<2Fwww.redacted.fr@attacker.xyz>%2Fdesign%2F3.9.0%2Fneva%2Fassets%2F) * Et lors du chargement de l'image dans le code source, celle-ci à bien été cherché à l'endroit voulu comme le montre les logs.

Fuites d'informations techniques sur les victimes

### Risques Fuites d'informations techniques des utilisateurs de l'application (IP, User-Agent) mais nécessité de phishing pour l'exploiter. ## Récompenses ![](/files/C2jxBAU6MioMuDl0gyY6) # Race Condition ## [Race condition](https://blog.s1rn3tz.ovh/pentest-web/race-conditions) dans une fonctionnalité de génération de magic links menant à la prise de contrôle de comptes utilisateurs ### Description L'application était une application Web avec 3 niveaux de rôles (administrateur, un utilisateur spécifique utilisé pour un usage spécifique et des utilisateurs normaux). L'authentification pour les utilisateurs normaux était sans mot de passe. Pour s'authentifier, un lien magique était envoyé par e-mail et générait un jeton spécifique et unique pour une courte période de temps. Cette fonction était vulnérable à une vulnérabilité de condition de concurrence conduisant à générer exactement le même jeton pour différents utilisateurs lors de l'envoi de la requête en simultané. ### Exploitation * J'ai capturé la requête de demande de magik link via burp\* * J'ai fait un click droit sur la requête puis "copy as curl command" * Sur un terminal j'ai collé la requête pour mon utilisateur puis ajouté un "&" afin de lancer la commande en arrière plan puis collé une nouvelle fois la requête en changeant le nom d'utilisateur pour la seconde requête. * J'ai lancé les commandes puis me suis rendu sur mes boîtes de reception afin de vérifier les token généré. * Les token étaient identiques pour les deux utilisateurs. ### Risques Générer exactement le même jeton de connexion pour de nombreux utilisateurs peut entraîner une prise de contrôle de compte en masse. # Violation of secure design principles ## SMS Hijacking via fonctionnalité non sécurisée et manque de vérification des entrées utilisateur ## Description L'application possédait une fonctionnalité permettant d'envoyer un SMS à un numéro de téléphone donné redirigeant vers un lien spécifique n'étant normalement pas géré par l'utilisateur. Cependant, cette fonctionnalité souffrait d'un défaut de conception permettant à un utilisateur d'intercepter et modifier le contenu du message envoyé via le paramètre json "message". ### Exploitation * J'ai intercepté la requête d'envoie du SMS.

* J'ai modifié le paramètre "message".

* J'ai ennvoyé la requête et constaté que je pouvais envoyer n'importe quel message à n'importe quel numéro de téléphone. ![](/files/wjXskJ9T4vwzfkK396dk) **Bonus**: Le tableau json utilisé dans la requête permettait d'envoyer le message à une multitude de numéros de téléphone en une seule requête.

### Risques Les risques dans ce contexte sont: * L'utilisation de l'application comme outil de smishing (phishing par SMS) par un acteur malveillant. (avec possibilité de faire des campagnes en masse via le tableau json) * La perte financière liée à l'envoie de SMS en masse. * L'impact business lié à un potentiel blacklistage des numéros de téléphone de l'entreprise. # CSRF Cross Site Resquest Forgery ## [CSRF](https://blog.s1rn3tz.ovh/pentest-web/csrf)dans formulaire d'informations permet de personnaliser les information personnelles d'un utilisateur ### Description La vulnérabilité a été découverte dans un site appartenant à une entreprise Française leader de son domaine. Le site vulnérable permettait à un client d'acheter des machines industrielles pour son entreprise. Pour cela, l'utilisateur devait donc obligatoirement avoir un compte sur le site et entrer ses informations personnelles notamment pour les informations de facturation etc. La vulnérabilité se situait donc au niveau du formulaire permettant d'éditer ses informations. Alors que les informations sensibles pouvant permettre de prendre le contrôle du compte vérifiait correctement le code généré de manière aléatoire afin de garantir l'intégrité de la demande de changement, le deuxième formulaire permettant de changer les informations personnelles tels que le nom, prénom, nom de société, numéro de téléphone, adresse physique ne vérifiait pas la présence du code aléatoire qui était généré. ### Exploitation * J'ai d'abord créé un premier utilisateur. (user1) * J'ai changé les informations personnelles de ce compte puis intercepté la requête. * J'ai généré un PoC CSRF via la requête intercepté (via burp suite ou )

* Je me suis ensuite connecté avec un deuxième compte. (user 2) * Puis j'ai utilisé le code PoC qui permet donc de faire une requête de modification des données personnelles à l'insu de l'utilisateur. * Cela m'a effectivement redirigé vers la page en question sur laquelle les informations on effectivement été remplacés par les informations souhaitées.

### Risques Il est alors possible dans le cas où on parvient à faire se rendre un utilisateur connecté sur une page contenant le code du PoC CSRF de modifier ses informations personnelles par des informations arbitraires. Cela entraînant: * **Usurpation d'identité**: une attaque CSRF réussie pourrait entraîner des modifications non autorisées des informations personnelles d'un utilisateur, qui pourraient ensuite être exploitées à des fins d'usurpation d'identité par l'attaquant. * **Invasion de la vie privée**: la modification de données personnelles telles que le numéro de téléphone et l'adresse sans consentement pourrait empiéter sur la vie privée de la victime, l'exposant potentiellement à des communications indésirables ou à des risques physiques. * **Interception des communications**: si un attaquant modifie les coordonnées d'un utilisateur, il pourrait intercepter des notifications, des messages ou des mises à jour importants destinés à l'utilisateur légitime, entraînant ainsi des informations manquées ou une confusion. * **Dommage à la réputation**: des informations personnelles modifiées, si elles ne sont pas rapidement corrigées, pourraient prêter à confusion et nuire à la réputation de l'utilisateur concerné. Ceci est particulièrement préoccupant si l’utilisateur est associé à un contexte professionnel ou à une communauté en ligne. * **Hameçonnage**: les attaquants peuvent exploiter les informations personnelles modifiées pour élaborer des tentatives de phishing convaincantes, ce qui rend les utilisateurs plus susceptibles de tomber dans le piège des escroqueries en raison de la nature personnalisée des messages. * **Inexactitudes dans les profils**: les attaques CSRF pourraient entraîner des informations personnelles incorrectes ou incohérentes dans les profils en ligne, créant ainsi de la confusion et compromettant la présence en ligne de l'utilisateur. * **Non conformité aux réglementations en matière de confidentialité**: des modifications non autorisées des informations personnelles pourraient entraîner le non-respect des réglementations en matière de confidentialité et des lois sur la protection des données, entraînant potentiellement des conséquences juridiques pour l'organisation concernée. * **Surmenage du support client**: les victimes d'attaques CSRF ciblant des informations personnelles peuvent avoir besoin de demander l'aide du support client pour rectifier les changements, ce qui accroît la pression sur les ressources de support de l'organisation. ### Récompense

# 2FA/OTP bypass ## Contournement OTP via manipulation de réponse HTTP ### Description La vulnérabilité a été découverte chez un fournisseur de télécommunication Philippen sur un interface web dédié à la vente de forfaits et téléphones. Le site en question demandait un OTP par SMS pour démarrer une transaction. Cependant, la condition pour passer à l'étape suivante était validée côté frontend et utilisait la réponse HTTP pour déterminer si oui ou non le code OTP était valide. De cette manière, il était possible de rensigner un faux numéro de téléphone ainsi qu'un faux code OTP puis de remplacer le contenu de la réponse HTTP d'échec par un message de succès. ### Exploitation * J'ai d'abord envoyé un code OTP vers un numéro valide afin d'analyser le comportement normal de l'application lors d'une validation réussie. * J'ai ensuite envoyé un code OTP à un numéro arbitraire puis entré un code invalide (000000) tout en interceptant la réponse HTTP.

* Remarquant que le site attendait la réponse pour afficher le message d'erreur j'ai compris que la validation était probablement effectué en se basant sur la réponse HTTP. * J'ai dont remplacé les données JSON d'échec par celles d'un succès.

* Une cela fait j'ai tout simplement désactivé l'interception et la vérification OTP a été contourné avec succès.

### Risques Les risques ici étaient limités à un risque d'usurpation d'identité principalement avec la possibilité d'effectuer des transactions avec le numéro de téléphone d'un autre individu. En effet, il n'existait pas de comptes sur le site, il n'était donc pas possible de prendre le contrôle du compte de quelqu'un d'autre par ce procédé. # Business Logic Errors ## Manque de validation lors du changement d'email ### Description La vulnérabilité a été découverte sur l'application web d'un fournisseur de technologies liées au contrôle d'identité par IA. Cette application permettait de créer des comptes utilisateurs à partir d'emails professionnels, une fois connecté, l'utilisateur avait accès à un dashboard avec plusieurs fonctionnalités permettant notamment la création de templates de validation d'identité etc. Dans ce dashboard, l'utilisateur a la possibilité d'inviter des personnes en leur envoyant un lien par email et par le même biais de changer les emails de ces utilisateurs dont celui du propriétaire de l'application (donc soi-même). La fonctionnalité permettant cela souffrait alors d'un manque de vérification permettant de remplacer son email par n'importe quel email arbitraire sans aucune validation et aucune possibilité de réfuter ce changement depuis l'email reçu par la victime. ### Exploitation * Dans un premier temps j'ai essayé de créer un compte avec un email privé via l'endpoint d'enregistrement. * Cependant la politique en place m'en empêchait.

Politique d'emails professionnels uniquement

* J'ai alors créé un compte avec un email professionnel comme demandé par la politique. * Je me suis rendu sur la page de gestion des utilisateurs du dashboard. * Puis j'ai simplement modifié mon email par un email arbitraire hors de mon contrôle.

* Une fois cela fait, il m'était alors possible de me connecter avec ce nouvel email et mon mot de passe sans aucune validation de la part du serveur et l'ancien mail professionnel n'était plus actif malgrés qu'i était encore affiché sur le dashbard.

### Risques Permettre aux utilisateurs de changer leur e-mail enregistré d’un e-mail professionnel à un e-mail privé après l’inscription peut introduire des risques de sécurité et de business. Voici quelques impacts potentiels : #### Usurpation d’identité et ingénierie sociale : Un utilisateur malveillant peut s’inscrire avec une adresse e-mail professionnelle, accéder à certains privilèges ou informations, puis modifier le courrier électronique en un courrier privé. Cela pourrait leur permettre d’usurper l’identité d’un utilisateur légitime et de mener des activités malveillantes. #### Contournement des mesures de sécurité : Si l’entreprise s’appuie sur la vérification des adresses e-mail professionnelles pour assurer un certain niveau de confiance ou de sécurité, permettre aux utilisateurs de passer à des e-mails privés pourrait compromettre ces mesures. #### Intégrité des processus opérationnels : Si la logique métier suppose un certain niveau de confiance ou de validation associé aux adresses e-mail professionnelles, permettre aux utilisateurs de passer à des e-mails privés pourrait perturber les processus métier prévus et compromettre l’intégrité de ces processus. #### Conformité réglementaire : Selon l’industrie, il peut y avoir des règlements ou des normes en place qui exigent certaines pratiques de sécurité. Permettre aux utilisateurs de passer librement des courriels professionnels aux courriels privés peut enfreindre ces règlements. #### Fuite de données : Si le courrier électronique professionnel a été utilisé pour des communications commerciales ou l’accès à des informations sensibles, le fait de le remplacer par un courrier électronique privé peut entraîner une fuite involontaire de données commerciales sensibles vers des comptes de messagerie personnels. #### Activités frauduleuses : Les utilisateurs peuvent s’inscrire avec des e-mails professionnels pour obtenir certains avantages ou accès, puis passer à des e-mails privés pour échapper au suivi ou à la détection. Cela pourrait être exploité pour des activités frauduleuses. # Information Disclosure ## Account Takeover via fonctionnalité de tracing ASP.net active La vulnérabilité a été découverte sur un sous-domaine d'un spécialiste du recrutement européen. Suite à un peut de fuzzing, j'ai tout simplement découvert que l'option de tracing ASP.net était activé sur le site. ### Description Le traçage ASP.NET est une fonctionnalité de débogage conçue pour être utilisée pendant le développement afin de faciliter la résolution des problèmes. Il divulgue des informations sensibles aux utilisateurs et, s'il est activé dans des contextes de production, il peut présenter une menace sérieuse pour la sécurité. Le traçage au niveau de l'application permet à tout utilisateur de récupérer tous les détails sur les demandes récentes adressées à l'application, y compris celles des autres utilisateurs. Ces informations incluent généralement des jetons de session et des paramètres de requête (en texte clair), qui peuvent permettre à un attaquant de compromettre d'autres utilisateurs et même de prendre le contrôle de l'ensemble de l'application. Le traçage au niveau de la page renvoie les mêmes informations, mais relatives uniquement à la requête en cours. Celui-ci peut toujours contenir des données sensibles dans les variables de session et de serveur qui pourraient être utiles à un attaquant. **Endpoint**: /trace.axd ### Exploitation L'application utilse un formulaire de connexion (/logon.aspx). Il est donc possible de récupérer les identifiants des utilisateurs qui s'y connectent via cette fonctionnalité qui log les paramètres HTTP envoyés en clair.

### Risques * ATO * Surveillance non autorisée des utilisateurs * Fuites d'informations sensibles * Compromission du serveur # Insecure root detection implementation ## Root detection bypass via deeplink triggering (most likely not recognized as a bug) ### Description The vulnerability were found in a Brazilian insurance Android app. This one were using a splash activity enforced to prevent rooted devices to go further in the app bypassed without high technical knowledges by following an invalid deeplink that triggered an Activity after the splash screen. In fact the app only verified the device status at the app launch. ### Exploitation To check this behavior, I tried to launch the app with a rooted / "non compliant" device which fetched me this splash activity.

Previously, during static analysis of the app, I found that the app were using several deeplinks to access different part of the app. And by triggering one of them, I were able to access the main activity of the app and bypass the splash screen. ADB Command: *`$ adb shell am start -a "android.intent.action.VIEW" -c "android.intent.category.BROWSABLE" -d "scheme://host?parameter=value"`* Hyperlink from an external app:

### Risks Root detection is a mecanism used to prevent rooted devices to dynamically analyze the apps. If this detection is bypassed, it allow malicious users to analyze every storage actions, system calls, HTTP requests etc that are used by the app during runtime. # Insecure deeplink handling ## Open Redirect via insecure deeplink url handling ### Description The vulnerability were found in a Brazilian insurance Android app in a black box approach (without user account). This one were using a deeplink looking like `target://open_browser?url=https://sub.target.br/`something and I found that the "url" parameter used by the deeplink did not verify that the given URL were trusted allowing to redirect users to arbitrary domains. ### Exploitation First I analyzed the AndroidManifest.xml file of the APK to find the deeplinks that were used by the app. I found that the app were using deeplinks like: `https://target.br, https://target.test-app.link and target://*` So after listing the application deeplinks, I started to statically analyze de code to check how these deeplinks were found. Unfortunately, the app were well obfuscated and it was hard to statically analyze it. As I didn't have any account on the application, I also didn't found any information about it by using dynamic analysis. So I kept digging and found that one of the firebase database used by the application was publicly readable (but without write rights). In this database, I found an interesting information. Indeed, I found a deeplink like `target://open_browser?url=https://sub.target.br/`.

Immediately, I did what every hunter would do. I tried to trigger the deeplink with an arbitrary URL and it worked. 3 solutions: * via adb: `adb shell am start -a "android.intent.action.VIEW" -c "android.intent.category.BROWSABLE" -d "target://open_browser?url=https://attacker.xyz/"` * via a qrcode * via an other app hyperlink The app opened my arbitrary url in my default browser app. Unfortunately, as the URL were not opened in a webview directly in-app, I was not able to escalate the vulnerability or chain it with an other one. ### Risks The risks are mainly the same that on an open redirect on a website but on such context it is harder to chain the vulnerability with other vulnerabilities like XSS injection or Oauth ATO while the url were open in an other app (browser app) so it goes out of the application's context. Anyway, attackers could still exploit this vulnerability for phishing purposes. ### Reward

# Insecure storage of business credentials ## Description The vulnerability were found in a public car managing app from an international car manufacturer. The app allows car owners of this company to read and manage some information about their car like digital keys, central lock, battery level and others. The app did expose Azure AD Service Principal credentials in an insecure Firebase Remote Config allowing any external app/user with an access to the app to extract them. These credentials allowed successful authentication against Microsoft Azure AD using the OAuth 2.0 client\_credentials flow, resulting in a valid access to a private API that were used to manage actions related to the cars charging. ## Exploitation 1\) The app were a public app accessible from the Play Store. 2\) Once installed, I simply used the app **Rcspy** by **Tushar Ghighe** () that automate the Firebase Remote Config detection and reading for every installed app on the device. {% hint style="info" %} **Note**: Firebase Remote Config is a widely used solution to configure **non-sensitive** components of an app without having to release updates. For example if the app need maintenance, the app owners could just use a config like "IsMaintenance" and switch the parameter from "false" to "true" to trigger a specific activity at launch. Anyway, some developers doesn't know that they are publically accessible because always on client-side. As a result it can sometime happen that developpers put some sensitive information like private API keys, private tokens or credentials in Firebase Remote Config. {% endhint %} 3\) I just analysed the remote configs and found Azure AD Service Pincipal client\_id and client\_secret stored in cleartext.

4\) Credentials validity check

5\) Post-exploitation (out of scope) ## Risks The risks depends on the rights of the service principal user, as post-exploitation were out of scope, it's hard to imagine the real risk associated with this leak but if the user isn't well hardened, well... you can imagine that it could lead to a critical cloud environment takeover in the worst scenario or in a very low impact if the principle of least privileges is respected. ## Reward No reward (Duplicate)