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

20 KiB
Raw Blame History

OAuth vers la prise de contrôle de compte

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Informations de base

OAuth propose différentes versions, avec des informations fondamentales accessibles sur la documentation OAuth 2.0. Cette discussion se concentre principalement sur le largement utilisé type de subvention de code d'autorisation OAuth 2.0, fournissant un cadre d'autorisation permettant à 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 messages sur les réseaux sociaux, y compris les privés. Pour ce faire, OAuth 2.0 est utilisé. https://example.com demandera votre autorisation pour accéder à vos messages sur les réseaux sociaux. Par conséquent, un écran de consentement apparaîtra sur https://socialmedia.com, détaillant les autorisations demandées et le développeur faisant la demande. Après votre autorisation, https://example.com acquiert la capacité d'accéder à vos messages en votre nom.

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

  • propriétaire de la ressource : Vous, en tant qu'utilisateur/entité, autorisez l'accès à votre ressource, comme vos messages de compte sur les réseaux sociaux.
  • serveur de ressources : Le serveur gérant les demandes authentifiées après que l'application a obtenu un jeton d'accès au nom du propriétaire de la ressource, par exemple, https://socialmedia.com.
  • application cliente : L'application demandant l'autorisation du propriétaire de la ressource, comme https://example.com.
  • serveur d'autorisation : Le serveur qui délivre des jetons d'accès à l'application cliente après l'authentification réussie du propriétaire de la ressource 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 jetons d'accès.
  • response_type : Une valeur spécifiant le type de jeton demandé, comme code.
  • scope : Le niveau d'accès demandé par l'application cliente au propriétaire de la ressource.
  • redirect_uri : L'URL vers laquelle l'utilisateur est redirigé après autorisation. Cela doit généralement correspondre à l'URL de redirection préalablement 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. Sa singularité 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 à renvoyer.
  • code : Le code d'autorisation du serveur d'autorisation, utilisé conjointement avec client_id et client_secret par l'application cliente pour acquérir un jeton d'accès.
  • access_token : Le jeton que l'application cliente utilise pour les requêtes API au nom du propriétaire de la ressource.
  • refresh_token : Permet à l'application d'obtenir un nouveau jeton d'accès sans redemander à l'utilisateur.

Flux

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

  1. Vous accédez à 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 vous demandant l'autorisation de permettre à l'application de https://example.com d'accéder à vos messages. 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. Ensuite, vous êtes présenté avec une page de consentement.

  2. Après votre approbation, les médias sociaux envoient 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 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"}
  1. Enfin, le processus se termine lorsque https://example.com utilise votre access_token pour effectuer un appel API vers les médias sociaux afin d'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 indique 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, facilitant 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 n'importe quelle 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.

Outre redirect_uri, d'autres paramètres OAuth et OpenID comme client_uri, policy_uri, tos_uri et initiate_login_uri sont également susceptibles d'être attaqués par redirection. Ces paramètres sont facultatifs et leur prise en charge 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 de registre et d'autres spécificités de configuration du serveur.

XSS dans l'implémentation de redirection

Comme mentionné dans ce rapport de prime au bogue 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 aux XSS. Charge utile possible à tester:

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

CSRF - Gestion incorrecte du paramètre d'état

Dans les implémentations OAuth, l'utilisation incorrecte ou l'omission du paramètre state peut augmenter considérablement le risque d'attaques de falsification de requête intersite (CSRF). Cette vulnérabilité survient lorsque le paramètre state n'est pas 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 d'une victime, entraînant 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 piratage, mettant en évidence ses implications pratiques. Le problème s'étend également aux intégrations avec des services tiers tels que Slack, Stripe et PayPal, où les attaquants peuvent rediriger des notifications ou des paiements vers leurs comptes.

La gestion et la validation appropriées du paramètre state sont cruciales pour se protéger contre les 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 ultérieurement 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 de la vérification d'email laxiste d'OAuth : Les attaquants peuvent exploiter les 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 comporte également des risques d'accès non autorisé au compte, similaire au premier scénario mais à travers un vecteur d'attaque différent.

Divulgation de secrets

Identifier et protéger les paramètres secrets OAuth est crucial. Alors que le client_id peut être divulgué en toute sécurité, révéler le client_secret pose des risques importants. 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 incorrectement 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, via l'ingénierie sociale, les attaquants pourraient augmenter les privilèges en ajoutant des étendues 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 de tenter de voler des comptes.
La requête de 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 divulguant Code + State

Une fois que le client a le code et l'état, s'il est reflété 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 est enregistré là-dedans.

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 & Post Messages pour divulguer les valeurs du code & de l'état

Consultez ce post

AWS Cognito

Dans ce rapport de prime de bug : 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 utilisateur. Par conséquent, si vous pouvez changer l'e-mail de l'utilisateur pour un e-mail d'utilisateur différent, vous pourriez être en mesure 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 d'AWS Cognito, consultez :

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

Abuser des jetons d'autres applications

Comme mentionné dans cet article, les flux OAuth qui s'attendent à recevoir le jeton (et non un code) pourraient être vulnérables s'ils ne vérifient pas que le jeton appartient à l'application.

Cela est dû au fait qu'un attaquant pourrait créer une application prenant en charge 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 jeton OAuth de l'utilisateur donné à son application, et l'utiliser pour se connecter à l'application OAuth de la victime en utilisant le jeton de l'utilisateur de la victime.

{% hint style="danger" %} Par conséquent, si l'attaquant parvient à obtenir l'accès de l'utilisateur à sa propre application OAuth, il pourra prendre le contrôle du compte de la victime dans les applications qui attendent un jeton et ne vérifient pas si le jeton a été accordé à leur ID d'application. {% endhint %}

Deux liens et cookie

Selon cet article, il était possible de faire en sorte qu'une victime ouvre une page avec un returnUrl pointant vers l'hôte de l'attaquant. Ces informations seraient stockées dans un cookie (RU) et à une étape ultérieure, le prompt demandera à l'utilisateur s'il souhaite donner accès à cet hôte d'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 l'affichage du prompt, et d'ouvrir un nouvel onglet sans cette valeur. Ensuite, le prompt ne mentionnera pas l'hôte de l'attaquant, mais le cookie sera défini sur celui-ci, de sorte que le jeton sera envoyé à l'hôte de l'attaquant dans la redirection.

Paramètres SSRF

Consultez cette recherche pour plus de détails sur cette technique.

L'enregistrement dynamique du client dans OAuth sert de vecteur moins évident mais critique pour les vulnérabilités de sécurité, en particulier pour les attaques de falsification de requête côté serveur (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 du client est souvent associé à /register et accepte des détails tels que client_name, client_secret, redirect_uris, et des URLs 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 exposer involontairement 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é par le serveur, déclenchant un SSRF ou conduisant à une XSS si l'URL est mal gérée.
  • jwks_uri : Une URL vers le document JWK du client, qui s'il est malveillamment conçu, peut amener le serveur à effectuer des requêtes sortantes vers un serveur contrôlé par l'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 : Liste les URI de requête autorisés pour le client, qui peuvent être exploités si le serveur récupère ces URIs au début du processus d'autorisation.

Stratégie d'exploitation :

  • Le SSRF peut être déclenché en enregistrant un nouveau client avec des URLs malveillantes dans des paramètres tels que 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 l'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 d'éventuelles conditions de course.

Références

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

D'autres façons de soutenir HackTricks :