hacktricks/pentesting-web/account-takeover.md

9 KiB

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 :

Problème d'autorisation

L'e-mail d'un compte doit être tenté d'être modifié, et le processus de confirmation doit être examiné. S'il est jugé faible, l'e-mail doit être changé pour celui de la victime prévue, puis confirmé.

Problème de normalisation Unicode

  1. Le compte de la victime prévue victim@gmail.com
  2. Un compte devrait être créé en utilisant Unicode
    par exemple : vićtim@gmail.com

Comme expliqué dans cette présentation, l'attaque précédente pourrait également être réalisée en abusant des fournisseurs d'identité tiers :

  • Créer un compte dans le fournisseur d'identité tiers avec un e-mail similaire à celui de la victime en utilisant un caractère Unicode (vićtim@company.com).
  • Le fournisseur d'identité tiers ne devrait pas vérifier l'e-mail
  • Si le fournisseur d'identité vérifie l'e-mail, peut-être pouvez-vous attaquer la partie domaine comme : victim@ćompany.com et enregistrer ce domaine en espérant que le fournisseur d'identité génère la version ASCII du domaine tandis que la plateforme de la victime normalise le nom de domaine.
  • Connectez-vous via ce fournisseur d'identité sur la plateforme de la victime qui devrait normaliser le caractère Unicode et vous permettre d'accéder au compte de la victime.

Pour plus de détails, consultez le document sur la normalisation Unicode :

{% content-ref url="unicode-injection/unicode-normalization.md" %} unicode-normalization.md {% endcontent-ref %}

Réutilisation du jeton de réinitialisation

Si le système cible permet le réutilisation du lien de réinitialisation, des efforts doivent être déployés pour trouver plus de liens de réinitialisation en utilisant des outils tels que gau, wayback, ou scan.io.

Préparation à la prise de contrôle de compte

  1. L'e-mail de la victime devrait être utilisé pour s'inscrire sur la plateforme, et un mot de passe devrait être défini (une tentative de confirmation devrait être faite, bien que le manque d'accès aux e-mails de la victime puisse rendre cela impossible).
  2. Il faut attendre que la victime s'inscrive en utilisant OAuth et confirme le compte.
  3. On espère que l'inscription régulière sera confirmée, permettant l'accès au compte de la victime.

Mauvaise configuration CORS pour la prise de contrôle de compte

Si la page contient des mauvaises configurations CORS, vous pourriez être en mesure de voler des informations sensibles à l'utilisateur pour prendre le contrôle de son compte ou le faire changer d'informations d'authentification à cette fin :

{% content-ref url="cors-bypass.md" %} cors-bypass.md {% endcontent-ref %}

CSRF pour la prise de contrôle de compte

Si la page est vulnérable au CSRF, vous pourriez être en mesure de faire modifier son mot de passe à l'utilisateur, son e-mail ou son authentification pour ensuite y accéder :

{% content-ref url="csrf-cross-site-request-forgery.md" %} csrf-cross-site-request-forgery.md {% endcontent-ref %}

XSS pour la prise de contrôle de compte

Si vous trouvez un XSS dans l'application, vous pourriez être en mesure de voler des cookies, du stockage local, ou des informations de la page web qui pourraient vous permettre de prendre le contrôle du compte :

{% content-ref url="xss-cross-site-scripting/" %} xss-cross-site-scripting {% endcontent-ref %}

Même origine + Cookies

Si vous trouvez un XSS limité ou une prise de contrôle de sous-domaine, vous pourriez jouer avec les cookies (les fixer par exemple) pour essayer de compromettre le compte de la victime :

{% content-ref url="hacking-with-cookies/" %} hacking-with-cookies {% endcontent-ref %}

Attaque du mécanisme de réinitialisation de mot de passe

{% content-ref url="reset-password.md" %} reset-password.md {% endcontent-ref %}

Manipulation de la réponse

Si la réponse d'authentification peut être réduite à un simple booléen, essayez de changer false en true et voyez si vous obtenez un accès.

OAuth pour la prise de contrôle de compte

{% content-ref url="oauth-to-account-takeover.md" %} oauth-to-account-takeover.md {% endcontent-ref %}

Injection d'en-tête Host

  1. L'en-tête Host est modifié lors de l'initiation d'une demande de réinitialisation de mot de passe.
  2. L'en-tête proxy X-Forwarded-For est modifié en attacker.com.
  3. Les en-têtes Host, Referrer et Origin sont simultanément changés en attacker.com.
  4. Après avoir initié une réinitialisation de mot de passe et ensuite opté pour renvoyer le courrier, les trois méthodes susmentionnées sont employées.

Manipulation de la réponse

  1. Manipulation du code : Le code d'état est modifié en 200 OK.
  2. Manipulation du code et du corps :
  • Le code d'état est changé en 200 OK.
  • Le corps de la réponse est modifié en {"success":true} ou un objet vide {}.

Ces techniques de manipulation sont efficaces dans les scénarios où JSON est utilisé pour la transmission et la réception des données.

Changer l'e-mail de la session actuelle

D'après ce rapport :

  • L'attaquant demande à changer son e-mail avec un nouveau
  • L'attaquant reçoit un lien pour confirmer le changement de l'e-mail
  • L'attaquant envoie le lien à la victime pour qu'elle clique dessus
  • L'e-mail de la victime est changé pour celui indiqué par l'attaquant
  • L'attaquant peut récupérer le mot de passe et prendre le contrôle du compte

Cela s'est également produit dans ce rapport.

Anciens cookies

Comme expliqué dans ce post, il était possible de se connecter à un compte, enregistrer les cookies en tant qu'utilisateur authentifié, se déconnecter, puis se reconnecter.
Avec la nouvelle connexion, bien que différents cookies puissent être générés, les anciens ont recommencé à fonctionner.

Références

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

Autres façons de soutenir HackTricks :