👋OAuth
Dernière mise à jour
Dernière mise à jour
se connecter tout en capturant le traffic dans le http history de burp
aller dans le POST /authenticate
changer l'email de la victime par le mail de l'attaquant
Dans le cas où le paramètre state (permettant de se protéger des attaques CSRF) serait absent, Un utilisateur malveillant pourrait tenter de détourner le compte d'un autre utilisateur en le manipulant dans le but de lier son compte à son réseau social.
Exemple:
Application permettant d'associer un compte de réseau social.
Se connecter
Associer un compte de réseau social
Vérifier le fonctionnement de la fonction "Se connecter avec [réseau social]"
Dans l'historique http de burp, analyser les requêtes
Vérifier que la redirection ne contient pas le paramètre "state"
Vérifier la présence du code d'autorisation dans la requête suivant la redirection
La deuxième étape vise à refaire le même procéder sans utiliser le code d'autorisation qui ne sera plus valide s'il est utilisé.
Capturer la requête "Associer un compte"
Forward la requête jusqu'au code d'autorisation
Copier l'url de la requête
Attention: il est important de drop la requête afin d'empêcher l'utilisation du code avant de l'avoir transmis à la victime.
A partir de ce moment, le fait que le paramètre state ne soit pas présent permet à l'attaquant de créer un exploit tel que celui ci-dessous qu'il pourrait envoyer à un autre utilisateur pour l'inciter à lier son compte au siens contre son gré:
Si le paramètre state est présent, essayer de le laisser vide pour vérifier si il est réellement vérifié.
Si le paramètre redirect_uri n'est pas correctement validé et permet à un attaquant de rediriger la requête OAuth sur un serveur lui appartenant, il pourrait alors prendre le contrôle du compte d'un autre utilisateur.
Etapes:
Se connecter
Associer un compte de réseau social
Vérifier le fonctionnement de la fonction "Se connecter avec [réseau social]"
Dans l'historique http de burp, analyser les requêtes
Tenter de remplacer le contenu du paramètre "redirect_uri" par une valeur arbitraire
Constater qu'il n'y a pas d'erreur
Vérifier la vulnérabilité en tentant une redirection sur un serveur nous appartenant (vérifier la présence du code d'autorisation dans les logs)
La deuxième étape consiste donc à envoyer comme précédemment un exploit à notre victime qui va permettre de voler son code d'autorisation et qui va ainsi nous permettre de nous connecter avec.
Une fois que la cible aura exécuté l'exploit, son code sera leaké dans les logs de notre serveur et nous n'auront donc plus qu'à nous déconnecter de notre session puis nous reconnecter en utilisant directement le code de notre victime.
Exemple:
https://target.com/oauth-callback?code=<STOLEN_CODE>
Afin d'éviter ce risque, les entreprises utilisent des whitelist leur permettant de n'autoriser que leurs urls dans le paramètre redirect_uri mais si celles-ci ne sont pas correctement implémentés, elle peuvent être contournées de différentes manières.
Certaines implémentations autorisent une plage de sous-répertoires en vérifiant uniquement que la chaîne commence par la séquence de caractères correcte, c'est-à-dire un domaine approuvé. Vous devriez essayer de supprimer ou d'ajouter des chemins arbitraires, des paramètres de requête et des fragments pour voir ce que vous pouvez modifier sans déclencher d'erreur.
Si vous pouvez ajouter des valeurs supplémentaires au paramètre redirect_uri par défaut, vous pourrez peut-être exploiter les écarts entre l'analyse de l'URI par les différents composants du service OAuth. Par exemple, vous pouvez essayer des techniques telles que:
https://target.com&@foo.evil.net#@bar.evil.net/
Vous pouvez occasionnellement rencontrer des vulnérabilités de pollution des paramètres côté serveur. Au cas où, vous devriez essayer de soumettre des paramètres redirect_uri en double comme suit :
Certains serveurs accordent également un traitement spécial aux URI localhostcar ils sont souvent utilisés pendant le développement. Dans certains cas, tout URI de redirection commençant par localhostpeut être accidentellement autorisé dans l'environnement de production. Cela pourrait vous permettre de contourner la validation en enregistrant un nom de domaine tel que localhost.evil.net.
Si il est impossible de nous rediriger vers notre serveur directement via le paramètre redirect_uri et qu'une autre page du site contient une redirection ouverte, on peut essayer d'utiliser du path traversal pour nous rendre sur cette page.
Exemple: https://target.com/oauth/callback/../exemple/path?redirect=http://evil.net
Essayez également de trouver toutes autres vulnérabilités qui vous permettraient d'extraire le code ou le jeton OAuth et de l'envoyer à un domaine externe.
XSS
HTML injection (<img src="evil.net">)
Essayer de brute force la page de login pour trouver des règles oauth cachées.
Exemple:
/login/facebook
/login/oauth/twitter
/login/oauth/v2/yahoo
Sign up avec Oauth de réseau social
REFUSER DE PARTAGER L'EMAIL
Redirection vers page de création de compte avec email normalement vide
Intercepter la requête de création de compte
Entrer un email déjà validé dans le champs d'email (celui de la cible)
Envoyer la requête
Si cela fonctionne, cela nous connecte alors sur le compte de la cible.
Étapes
Le premier objectif est de trouver un moyen de "casser" le flux de connexion OAuth afin de terminer avec une erreur faisant fuiter le code / token.
Pour cela, il existe plusieurs solutions:
Théorie:
L'attaquant démarre un flux de connexion OAuth sur le site Web en utilisant « Connectez-vous avec X ».
L'attaquant intercepte la valeur du paramètre state et construit un lien pour la victime pour se connecter avec le fournisseur OAuth mais avec le paramètre state de l’attaquant.
La victime est connectée avec le lien et redirigée vers le site web.
Le site Web valide l'état de la victime et arrête le traitement due flux de connexion car son paramètre state invalide. (Page d'erreur pour la victime)
L'attaquant trouve un moyen de divulguer le code de la page d'erreur. (Via une XSS par exemple)
L'attaquant peut désormais se connecter avec son propre paramètre state et le code a été divulgué par la victime.
Google:
Remplacer le paramètre response_type=code par response_type=code,id_token
Apple:
Remplacer le paramètre response_type=code par response_type=code+id_token et le paramètre response_mode=query par response_mode=fragment
Casse:
remplacer le paramètre redirect_uri=https://target.xyz/callback par redirect_uri=https://target.xyz/CalLbAcK
Chemin:
remplacer le paramètre redirect_uri=https://target.xyz/callback par redirect_uri=https://target.xyz/callbackxxx
Paramètre additionnel:
remplacer le paramètre redirect_uri=https://target.xyz/callback par redirect_uri=https://target.xyz/callback?code=xxx ou redirect_uri=https://target.xyz/callback?id_token=xxx
L'étape suivante consiste à trouver un moyen de faire fuite l'URL d'erreur contenant le code / token.
Voici quelques solutions possibles:
Si un Post-Message ne vérifie pas l'hôte source des messages, on peut imaginer un scénario tel que:
L'attaquant envoie à la victime un lien spécialement conçu pour aboutir à un "non-happy path" dans la danse OAuth.
La victime clique sur le lien. Un nouvel onglet s'ouvre avec un flux de connexion avec l'un des fournisseurs OAuth du site Web exploité.
Une erreur est déclenché sur le site Web exploité, le listener postMessage vulnérable est chargé sur la page sur laquelle la victime a atterri, toujours avec le code ou les jetons dans l'URL.
L'onglet d'origine envoyé par l'attaquant envoie un tas de postMessages au nouvel onglet avec le site Web pour que le listener postMessage divulgue l'URL actuelle.
L'onglet d'origine envoyé par l'attaquant écoute ensuite le message qui lui est envoyé.
Lorsque l'URL revient dans un message, le code et le jeton sont extraits et envoyés à l'attaquant.
L'attaquant se connecte au compte de la victime en utilisant le code ou le jeton exfiltré.
La spécification OpenID permet aux applications clientes de s'enregistrer auprès du fournisseur OpenID de manière standardisée. Si l'enregistrement dynamique du client est pris en charge, l'application client peut s'enregistrer elle-même en envoyant une requête POST à endpoint dédié tel que /registration par exemple. Le nom de cet endpoint est généralement fourni dans le fichier de configuration et la documentation.
Via cet endpoint, l'utilisateur va alors avoir la possibilité de s'enregistrer en renseignant des informations au format JSON demandant souvent une liste d'urls de redirection whitelistées.
De cette manière, si cette fonctionnalité est activée et mal restreinte, un attaquant à la possibilité d'enregistrer ses propres urls de redirection et ainsi de bénéficier d'une SSRF.
Exemple:
