Open redirect
Last updated
Last updated
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.
J'ai fait un clic droit sur mon image de profile et l'ai ouvert dans un nouvel onglet.
J'ai d'abord essayé de simplement changer le domaine original par mon propre domaine me renvoyant une erreur Golang.
https://img.exemple.xyz/?u=https%3a%2f%2fattacker.xyz%2f
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.
https://img.exemple.xyz/?u=https%3a%2f%2fattacker.xyz%ffxyz-api.exemple.xyz
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.
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.
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).
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.
L'entreprise vulnérable propose des applications mobiles dont les deeplinks sont gérées via un sous-domaine https://app.redacted.com. 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.
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 https://app.redacted.com 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 https://play.google.com 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.
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.
