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 https://mon-compte.redacted.fr. Lorsqu'une erreur survenait sur le site, une redirection était effectué vers l'url https://mon-compte.redacted.fr/#/error/page 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 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.
Risques
Fuites d'informations techniques des utilisateurs de l'application (IP, User-Agent) mais nécessité de phishing pour l'exploiter.
Récompenses
Last updated
