Account Takeover

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

Authorization Issue

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

Unicode Normalization Issue

  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

As explained in this talk, the previous attack could also be done abusing third party identity providers:

  • Créer un compte chez le 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 doit pas vérifier l’email
  • Si le fournisseur d’identité vérifie l’email, vous pouvez peut-être viser 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.
  • Se connecter 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, référez-vous au document sur Unicode Normalization:

Unicode Normalization

Reusing Reset Token

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

Pre Account Takeover

  1. L’email de la victime doit être utilisé pour s’inscrire sur la plateforme, et un mot de passe doit être défini (une tentative de confirmation doit être faite, 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 ainsi l’accès au compte de la victime.

CORS Misconfiguration to Account Takeover

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 pousser à modifier ses informations d’authentification dans ce but :

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

Si la page est vulnérable à CSRF, vous pourriez amener l’utilisateur à modifier son mot de passe, son email ou ses informations d’authentification afin d’y accéder ensuite :

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

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

XSS (Cross Site Scripting)

Same Origin + Cookies

Si vous trouvez une XSS limitée ou un subdomain takeover, vous pouvez manipuler les cookies (les fixer par exemple) pour tenter de compromettre le compte de la victime :

Cookies Hacking

Attacking Password Reset Mechanism

Reset/Forgotten Password Bypass

Security-question resets that trust client-supplied usernames

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

  1. Se connecter avec un utilisateur jetable et capturer le cookie de session.
  2. Soumettre le username de la victime ainsi que les nouvelles réponses via le formulaire de réinitialisation.
  3. S’authentifier immédiatement via le endpoint de connexion par question de sécurité en utilisant les réponses que vous venez d’injecter pour hériter des privilèges de la victime.
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

Tout ce qui est protégé par le contexte de la victime $_SESSION (admin dashboards, fonctionnalités dangereuses de stream-wrapper, etc.) est désormais exposé sans toucher aux véritables réponses.

Les noms d’utilisateur énumérés peuvent ensuite être ciblés via la technique d’overwrite ci-dessus ou réutilisés contre des services annexes (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. Le Host header est modifié suite à 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 headers Host, Referrer et Origin sont simultanément changés en attacker.com.
  4. Après avoir initié une réinitialisation de mot de passe puis choisi de renvoyer le mail, les trois méthodes ci‑dessus sont utilisées.

Response Manipulation

  1. Code Manipulation : le code de statut est modifié en 200 OK.
  2. Code and Body Manipulation :
  • Le code de statut 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ù JSON est utilisé pour l’envoi et la réception des données.

Change email of current session

From this report:

  • L’attaquant demande à changer son email pour un nouveau
  • L’attaquant reçoit un lien pour confirmer le changement d’email
  • L’attaquant envoie le lien à la victime pour qu’elle clique dessus
  • L’email de la victime est changé pour celui indiqué par l’attaquant
  • L’attaque permet de récupérer le mot de passe et de 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’email lors de l’inscription.
  • L’attaquant change l’email vérifié en victim@test.com (pas de vérification secondaire lors du changement d’email)
  • Désormais le site permet à victim@test.com de se connecter et nous avons contourné la vérification d’email de l’utilisateur victime.

Old Cookies

As explained in this post, il était possible de se connecter à un compte, sauvegarder les cookies en tant qu’utilisateur authentifié, se déconnecter, puis se reconnecter.
Avec la nouvelle connexion, bien que des cookies différents puissent être générés, les anciens ont de nouveau fonctionné.

References

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