Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

21 KiB
Raw Blame History

OAuth to Account takeover

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

{% embed url="https://websec.nl/" %}

Informations de base

OAuth propose différentes versions, avec des informations de base accessibles sur OAuth 2.0 documentation. Cette discussion se concentre principalement sur le très utilisé OAuth 2.0 authorization code grant type, 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érons un site web hypothétique https://example.com, conçu pour présenter tous vos posts sur les réseaux sociaux, y compris ceux 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 autorisations demandées et le développeur faisant la demande. Après votre autorisation, https://example.com obtient la capacité de consulter vos posts en votre nom.

Il est essentiel de comprendre les composants suivants dans le cadre OAuth 2.0 :

  • resource owner : Vous, en tant qu'utilisateur/entité, autorisez l'accès à votre ressource, comme les posts de votre compte de réseau social.
  • resource server : Le serveur gérant les requêtes 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 cherchant l'autorisation du resource owner, telle que https://example.com.
  • authorization server : Le serveur qui émet des access tokens à l'application cliente après l'authentification réussie du resource owner et l'obtention 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 jeton demandé, comme code.
  • scope : Le niveau d'accès que l'application cliente 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 les 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 jeton à 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 jeton 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.

Flux

Le flux OAuth réel se déroule comme suit :

  1. Vous naviguez vers https://example.com et sélectionnez le bouton “Intégrer avec les réseaux sociaux”.
  2. Le site envoie alors une demande à 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 suit :
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Vous êtes ensuite présenté avec une page de consentement.
  2. Après votre approbation, Social Media envoie une réponse à l'redirect_uri avec les paramètres code et state :
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com utilise ce code, ainsi que son client_id et client_secret, pour faire une requête côté serveur afin d'obtenir un access_token en votre nom, permettant l'accès aux permissions 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"}
  1. 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é, il pourrait permettre aux attaquants de rediriger ces requêtes 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 de la correspondance stricte des chemins à l'acceptation de toute URL dans le domaine ou le sous-répertoire spécifié. Les méthodes d'exploitation courantes incluent les redirections ouvertes, la traversée 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 ciblant 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 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 il est possible que l'URL de redirection soit reflétée dans la réponse du serveur après l'authentification de l'utilisateur, étant vulnérable à XSS. Payload possible à tester :

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Mauvaise gestion du paramètre state

Dans les implémentations OAuth, la mauvaise utilisation ou l'omission du paramètre state peut augmenter considérablement le risque d'attaques par Cross-Site Request Forgery (CSRF). Cette vulnérabilité survient lorsque le paramètre state est soit non utilisé, utilisé comme une valeur statique, ou non correctement 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 de la victime, conduisant à 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, soulignant 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 paramètre state sont cruciales pour se protéger contre les CSRF et sécuriser le flux OAuth.

Prise de contrôle de compte préalable

  1. Sans vérification de l'email lors de la création de compte : Les attaquants peuvent créer un compte de manière préventive en utilisant l'email de la victime. Si la victime utilise plus tard un service tiers pour se connecter, l'application pourrait par inadvertance lier ce compte tiers au compte pré-créé par l'attaquant, conduisant à 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 avec leur service puis en changeant l'email du compte pour celui de la victime. Cette méthode présente un risque similaire d'accès non autorisé, semblable au premier scénario mais via 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 les access_tokens des utilisateurs et des informations privées.

Une vulnérabilité courante survient lorsque les applications gèrent par erreur l'échange du code d'autorisation pour 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 l'apparence de l'application. De plus, par ingénierie sociale, les attaquants pourraient escalader les privilèges en ajoutant des portées supplémentaires à l'autorisation OAuth, exploitant davantage le statut de confiance de l'application.

Bruteforce du Client Secret

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 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]

Referer Header leaking Code + State

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 c'est vulnérable.

Access Token Stored in Browser History

Allez dans l'historique du navigateur et vérifiez si le jeton d'accès y est enregistré.

Everlasting Authorization Code

Le code d'autorisation ne devrait vivre que pendant un certain temps pour limiter la fenêtre de temps où un attaquant peut le voler et l'utiliser.

Authorization/Refresh Token not bound to 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.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Consultez cet article

AWS Cognito

Dans ce rapport de bug bounty : 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, vous pourriez être capable de prendre le contrôle d'autres comptes.

# 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 manière d'abuser de 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, 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.

Cela 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 à 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 pourra prendre le contrôle du compte de la victime dans les applications qui 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, il était possible de faire ouvrir à une victime une page avec un returnUrl pointant vers l'hôte de l'attaquant. Cette information 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 de l'hôte de l'attaquant, mais le cookie serait défini pour celui-ci, donc le token sera envoyé à l'hôte de l'attaquant dans la redirection.

Contournement de l'interaction du prompt

Comme expliqué dans cette vidéo, certaines implémentations OAuth permettent d'indiquer le paramètre GET prompt 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, 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 dans un paramètre GET : ?code=2397rf3gu93f
  • response_mode=fragment -> Le code est fourni dans le paramètre fragment de l'URL #code=2397rf3gu93f
  • response_mode=form_post -> Le code est fourni dans 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 pour plus de détails sur cette technique.

L'enregistrement dynamique des clients dans OAuth sert de vecteur moins évident mais critique pour les vulnérabilités de sécurité, spécifiquement pour les attaques 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 des clients est souvent mappé à /register et accepte des détails comme client_name, client_secret, redirect_uris, et des URL pour les logos ou les ensembles de clés JSON Web (JWKs) via des requêtes POST.
  • Cette fonctionnalité adhère aux 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 une SSRF ou menant à une 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 à faire des requêtes sortantes vers un serveur contrôlé par l'attaquant.
  • sector_identifier_uri : Référence un tableau JSON de redirect_uris, que le serveur pourrait récupérer, créant une opportunité de SSRF.
  • request_uris : Liste les URIs de requête autorisées pour le client, qui peuvent être exploitées si le serveur récupère ces URIs au début du processus d'autorisation.

Stratégie d'exploitation :

  • La SSRF peut être déclenchée 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 une request_uri préenregistrée et contrôlée par l'attaquant peut faciliter la 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 conditions de course possibles.

Références

{% embed url="https://websec.nl/" %}

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :