# OAuth to Account takeover {% hint style="success" %} Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Check the [**subscription plans**](https://github.com/sponsors/carlospolop)! * **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
{% embed url="https://websec.nl/" %} ## Basic Information OAuth propose plusieurs versions, avec des informations fondamentales accessibles dans la [documentation OAuth 2.0](https://oauth.net/2/). Cette discussion se concentre principalement sur le [type de subvention de code d'autorisation OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fournissant un **cadre d'autorisation qui permet à une application d'accéder ou d'effectuer des actions sur le compte d'un utilisateur dans une autre application** (le serveur d'autorisation). Considérez un site web hypothétique _**https://example.com**_, conçu pour **afficher tous vos posts sur les réseaux sociaux**, y compris les privés. Pour ce faire, OAuth 2.0 est utilisé. _https://example.com_ demandera votre permission pour **accéder à vos posts sur les réseaux sociaux**. Par conséquent, un écran de consentement apparaîtra sur _https://socialmedia.com_, décrivant les **permissions demandées et le développeur faisant la demande**. Après votre autorisation, _https://example.com_ obtient la capacité d'**accéder à vos posts en votre nom**. Il est essentiel de comprendre les composants suivants dans le cadre OAuth 2.0 : * **resource owner** : Vous, en tant que **utilisateur/entité**, autorisez l'accès à votre ressource, comme vos posts sur les réseaux sociaux. * **resource server** : Le **serveur gérant les demandes authentifiées** après que l'application a sécurisé un `access token` au nom du `resource owner`, par exemple, **https://socialmedia.com**. * **client application** : L'**application demandant l'autorisation** du `resource owner`, comme **https://example.com**. * **authorization server** : Le **serveur qui émet des `access tokens`** à l'`client application` après l'authentification réussie du `resource owner` et la sécurisation de l'autorisation, par exemple, **https://socialmedia.com**. * **client\_id** : Un identifiant public et unique pour l'application. * **client\_secret:** Une clé confidentielle, connue uniquement de l'application et du serveur d'autorisation, utilisée pour générer des `access_tokens`. * **response\_type** : Une valeur spécifiant **le type de token demandé**, comme `code`. * **scope** : Le **niveau d'accès** que l'`client application` demande au `resource owner`. * **redirect\_uri** : L'**URL vers laquelle l'utilisateur est redirigé après l'autorisation**. Cela doit généralement correspondre à l'URL de redirection préenregistrée. * **state** : Un paramètre pour **maintenir des données lors de la redirection de l'utilisateur vers et depuis le serveur d'autorisation**. Son unicité est cruciale pour servir de **mécanisme de protection CSRF**. * **grant\_type** : Un paramètre indiquant **le type de subvention et le type de token à retourner**. * **code** : Le code d'autorisation du `authorization server`, utilisé en tandem avec `client_id` et `client_secret` par l'application cliente pour acquérir un `access_token`. * **access\_token** : Le **token que l'application cliente utilise pour les requêtes API** au nom du `resource owner`. * **refresh\_token** : Permet à l'application de **obtenir un nouveau `access_token` sans redemander à l'utilisateur**. ### Flow Le **flux OAuth réel** se déroule comme suit : 1. Vous naviguez vers [https://example.com](https://example.com) et sélectionnez le bouton “Intégrer avec les réseaux sociaux”. 2. Le site envoie ensuite une demande à [https://socialmedia.com](https://socialmedia.com) demandant votre autorisation pour permettre à l'application de https://example.com d'accéder à vos posts. La demande est structurée comme : ``` https://socialmedia.com/auth ?response_type=code &client_id=example_clientId &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback &scope=readPosts &state=randomString123 ``` 3. Vous êtes ensuite présenté avec une page de consentement. 4. Suite à votre approbation, les réseaux sociaux envoient une réponse à l'`redirect_uri` avec les paramètres `code` et `state` : ``` https://example.com?code=uniqueCode123&state=randomString123 ``` 5. https://example.com utilise ce `code`, avec son `client_id` et `client_secret`, pour effectuer une requête côté serveur afin d'obtenir un `access_token` en votre nom, permettant l'accès aux autorisations auxquelles vous avez consenti : ``` POST /oauth/access_token Host: socialmedia.com ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"} ``` 6. Enfin, le processus se termine lorsque https://example.com utilise votre `access_token` pour effectuer un appel API à Social Media pour accéder ## Vulnérabilités ### Open redirect\_uri Le `redirect_uri` est crucial pour la sécurité dans les implémentations OAuth et OpenID, car il dirige où les données sensibles, comme les codes d'autorisation, sont envoyées après l'autorisation. S'il est mal configuré, cela pourrait permettre aux attaquants de rediriger ces demandes vers des serveurs malveillants, permettant ainsi la prise de contrôle de compte. Les techniques d'exploitation varient en fonction de la logique de validation du serveur d'autorisation. Elles peuvent aller d'une correspondance stricte des chemins à l'acceptation de n'importe quelle URL dans le domaine ou le sous-répertoire spécifié. Les méthodes d'exploitation courantes incluent les redirections ouvertes, le parcours de chemin, l'exploitation de regex faibles et l'injection HTML pour le vol de jetons. En plus de `redirect_uri`, d'autres paramètres OAuth et OpenID comme `client_uri`, `policy_uri`, `tos_uri` et `initiate_login_uri` sont également susceptibles aux attaques de redirection. Ces paramètres sont optionnels et leur support varie selon les serveurs. Pour ceux qui ciblent un serveur OpenID, le point de découverte (`**.well-known/openid-configuration**`) liste souvent des détails de configuration précieux comme `registration_endpoint`, `request_uri_parameter_supported`, et "`require_request_uri_registration`. Ces détails peuvent aider à identifier le point de terminaison d'enregistrement et d'autres spécificités de configuration du serveur. ### XSS dans l'implémentation de redirection Comme mentionné dans ce rapport de bug bounty [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), il pourrait être possible que l'**URL de redirection soit reflétée dans la réponse** du serveur après que l'utilisateur s'authentifie, étant **vulnérable à XSS**. Charge utile possible à tester : ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### CSRF - Mauvaise gestion du paramètre d'état Dans les implémentations OAuth, l'utilisation abusive ou l'omission du **`state` parameter** peut considérablement augmenter le risque d'attaques de **Cross-Site Request Forgery (CSRF)**. Cette vulnérabilité survient lorsque le paramètre `state` est soit **non utilisé, utilisé comme une valeur statique, ou mal validé**, permettant aux attaquants de contourner les protections CSRF. Les attaquants peuvent exploiter cela en interceptant le processus d'autorisation pour lier leur compte à celui d'une victime, ce qui peut entraîner des **prises de contrôle de compte** potentielles. Cela est particulièrement critique dans les applications où OAuth est utilisé à des fins **d'authentification**. Des exemples concrets de cette vulnérabilité ont été documentés dans divers **défis CTF** et **plateformes de hacking**, mettant en évidence ses implications pratiques. Le problème s'étend également aux intégrations avec des services tiers comme **Slack**, **Stripe**, et **PayPal**, où les attaquants peuvent rediriger des notifications ou des paiements vers leurs comptes. Une gestion et une validation appropriées du **`state` parameter** sont cruciales pour se protéger contre le CSRF et sécuriser le flux OAuth. ### Pré Prise de Contrôle de Compte 1. **Sans Vérification d'Email lors de la Création de Compte** : Les attaquants peuvent créer préventivement un compte en utilisant l'email de la victime. Si la victime utilise ensuite un service tiers pour se connecter, l'application pourrait involontairement lier ce compte tiers au compte pré-créé de l'attaquant, entraînant un accès non autorisé. 2. **Exploitation d'une Vérification d'Email OAuth Laxiste** : Les attaquants peuvent exploiter des services OAuth qui ne vérifient pas les emails en s'inscrivant à leur service puis en changeant l'email du compte pour celui de la victime. Cette méthode présente également un risque d'accès non autorisé au compte, semblable au premier scénario mais par un vecteur d'attaque différent. ### Divulgation de Secrets Identifier et protéger les paramètres secrets OAuth est crucial. Bien que le **`client_id`** puisse être divulgué en toute sécurité, révéler le **`client_secret`** pose des risques significatifs. Si le `client_secret` est compromis, les attaquants peuvent exploiter l'identité et la confiance de l'application pour **voler des `access_tokens` d'utilisateur** et des informations privées. Une vulnérabilité courante survient lorsque les applications gèrent par erreur l'échange du `code` d'autorisation contre un `access_token` côté client plutôt que côté serveur. Cette erreur conduit à l'exposition du `client_secret`, permettant aux attaquants de générer des `access_tokens` sous le couvert de l'application. De plus, par le biais d'ingénierie sociale, les attaquants pourraient élever leurs privilèges en ajoutant des scopes supplémentaires à l'autorisation OAuth, exploitant davantage le statut de confiance de l'application. ### Bruteforce du Secret Client Vous pouvez essayer de **bruteforcer le client\_secret** d'un fournisseur de services avec le fournisseur d'identité afin d'essayer de voler des comptes.\ La requête pour le BF peut ressembler à : ``` POST /token HTTP/1.1 content-type: application/x-www-form-urlencoded host: 10.10.10.10:3000 content-length: 135 Connection: close code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce] ``` ### En-tête Referer fuyant le Code + État Une fois que le client a le **code et l'état**, s'ils sont **réfléchis dans l'en-tête Referer** lorsqu'il navigue vers une autre page, alors il est vulnérable. ### Jeton d'Accès Stocké dans l'Historique du Navigateur Allez dans **l'historique du navigateur et vérifiez si le jeton d'accès y est enregistré**. ### Code d'Autorisation Éternel Le **code d'autorisation ne devrait vivre que pendant un certain temps pour limiter la fenêtre temporelle où un attaquant peut le voler et l'utiliser**. ### Jeton d'Autorisation/Rafraîchissement non lié au client Si vous pouvez obtenir le **code d'autorisation et l'utiliser avec un client différent, alors vous pouvez prendre le contrôle d'autres comptes**. ### Chemins Heureux, XSS, Iframes & Messages Post pour fuir les valeurs de code & d'état [**Vérifiez ce post**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url) ### AWS Cognito Dans ce rapport de bug bounty : [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) vous pouvez voir que le **jeton** que **AWS Cognito** renvoie à l'utilisateur pourrait avoir **suffisamment de permissions pour écraser les données de l'utilisateur**. Par conséquent, si vous pouvez **changer l'email de l'utilisateur pour un autre email d'utilisateur**, vous pourriez être en mesure de **prendre le contrôle** d'autres comptes. ```bash # Read info of the user aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...] # Change email address aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com { "CodeDeliveryDetailsList": [ { "Destination": "i***@f***.com", "DeliveryMedium": "EMAIL", "AttributeName": "email" } ] } ``` Pour plus d'informations détaillées sur la façon d'abuser d'AWS cognito, consultez : {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %} ### Abuser des tokens d'autres applications Comme [**mentionné dans cet article**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), les flux OAuth qui s'attendent à recevoir le **token** (et non un code) pourraient être vulnérables s'ils ne vérifient pas que le token appartient à l'application. Ceci est dû au fait qu'un **attaquant** pourrait créer une **application supportant OAuth et se connecter avec Facebook** (par exemple) dans sa propre application. Ensuite, une fois qu'une victime se connecte avec Facebook dans l'**application de l'attaquant**, l'attaquant pourrait obtenir le **token OAuth de l'utilisateur donné à son application, et l'utiliser pour se connecter dans l'application OAuth de la victime en utilisant le token utilisateur de la victime**. {% hint style="danger" %} Par conséquent, si l'attaquant parvient à faire accéder l'utilisateur à sa propre application OAuth, il sera en mesure de prendre le contrôle du compte de la victime dans les applications qui s'attendent à un token et ne vérifient pas si le token a été accordé à leur ID d'application. {% endhint %} ### Deux liens & cookie Selon [**cet article**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), il était possible de faire ouvrir à une victime une page avec un **returnUrl** pointant vers l'hôte de l'attaquant. Cette info serait **stockée dans un cookie (RU)** et à une **étape ultérieure**, le **prompt** demandera à l'**utilisateur** s'il souhaite donner accès à cet hôte de l'attaquant. Pour contourner ce prompt, il était possible d'ouvrir un onglet pour initier le **flux Oauth** qui définirait ce cookie RU en utilisant le **returnUrl**, de fermer l'onglet avant que le prompt ne soit affiché, et d'ouvrir un nouvel onglet sans cette valeur. Ensuite, le **prompt n'informera pas sur l'hôte de l'attaquant**, mais le cookie serait défini pour cela, donc le **token sera envoyé à l'hôte de l'attaquant** lors de la redirection. ### Contournement de l'interaction du prompt Comme expliqué dans [**cette vidéo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), certaines implémentations OAuth permettent d'indiquer le paramètre **`prompt`** GET comme None (**`&prompt=none`**) pour **empêcher les utilisateurs d'être invités à confirmer** l'accès donné dans un prompt sur le web s'ils sont déjà connectés à la plateforme. ### response\_mode Comme [**expliqué dans cette vidéo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), il pourrait être possible d'indiquer le paramètre **`response_mode`** pour indiquer où vous souhaitez que le code soit fourni dans l'URL finale : * `response_mode=query` -> Le code est fourni à l'intérieur d'un paramètre GET : `?code=2397rf3gu93f` * `response_mode=fragment` -> Le code est fourni à l'intérieur du paramètre de fragment d'URL `#code=2397rf3gu93f` * `response_mode=form_post` -> Le code est fourni à l'intérieur d'un formulaire POST avec un input appelé `code` et la valeur * `response_mode=web_message` -> Le code est envoyé dans un message post : `window.opener.postMessage({"code": "asdasdasd...` ### Paramètres SSRFs [**Consultez cette recherche**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Pour plus de détails sur cette technique.** L'enregistrement dynamique de clients dans OAuth sert de vecteur moins évident mais critique pour les vulnérabilités de sécurité, spécifiquement pour les attaques de **Server-Side Request Forgery (SSRF)**. Ce point de terminaison permet aux serveurs OAuth de recevoir des détails sur les applications clientes, y compris des URL sensibles qui pourraient être exploitées. **Points clés :** * **L'enregistrement dynamique de clients** est souvent mappé à `/register` et accepte des détails comme `client_name`, `client_secret`, `redirect_uris`, et des URL pour des logos ou des ensembles de clés JSON Web (JWKs) via des requêtes POST. * Cette fonctionnalité respecte les spécifications énoncées dans **RFC7591** et **OpenID Connect Registration 1.0**, qui incluent des paramètres potentiellement vulnérables aux SSRF. * Le processus d'enregistrement peut involontairement exposer les serveurs aux SSRF de plusieurs manières : * **`logo_uri`** : Une URL pour le logo de l'application cliente qui pourrait être récupérée par le serveur, déclenchant un SSRF ou menant à un XSS si l'URL est mal gérée. * **`jwks_uri`** : Une URL vers le document JWK du client, qui si elle est malicieusement conçue, peut amener le serveur à effectuer des requêtes sortantes vers un serveur contrôlé par un attaquant. * **`sector_identifier_uri`** : Fait référence à un tableau JSON de `redirect_uris`, que le serveur pourrait récupérer, créant une opportunité de SSRF. * **`request_uris`** : Énumère les URI de requête autorisées pour le client, qui peuvent être exploitées si le serveur récupère ces URI au début du processus d'autorisation. **Stratégie d'exploitation :** * Le SSRF peut être déclenché en enregistrant un nouveau client avec des URL malveillantes dans des paramètres comme `logo_uri`, `jwks_uri`, ou `sector_identifier_uri`. * Bien que l'exploitation directe via `request_uris` puisse être atténuée par des contrôles de liste blanche, fournir un `request_uri` préenregistré et contrôlé par un attaquant peut faciliter le SSRF pendant la phase d'autorisation. ## Conditions de course des fournisseurs OAuth Si la plateforme que vous testez est un fournisseur OAuth [**lisez ceci pour tester les éventuelles conditions de course**](race-condition.md). ## Références * [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) * [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
{% embed url="https://websec.nl/" %} {% hint style="success" %} Apprenez et pratiquez le hacking AWS :[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Apprenez et pratiquez le hacking GCP : [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Soutenir HackTricks * Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) ! * **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
{% endhint %}